Flutterの状態管理ライブラリ/フレームワークの概要
最近のMobile開発で特に重要なのが状態管理である。それはNativeのSwiftUIやJetpack Composeにおいても同様である。ただNativeの場合、選択肢は多くない。またできるだけ本家提供の状態管理方法に準拠する方がいい。
残念なことにFlutterにはGoogle提供の状態管理ライブラリがないので、下記のいくつかから選ぶことになってしまう。以下にクリーンアーキテクチャを採用したという観点を含め、長所短所をまとめた。
1. Bloc (Business Logic Component)
- コアコンセプト: Blocはビジネスロジックをプレゼンテーション層から分離することを助ける。StreamsとEventsを使用して状態変化を管理する。
- アーキテクチャ:
- Events: ユーザーのアクションや他のトリガーを表す。
- Bloc: イベントを入力として受け取り、新しい状態を出力する。
- States: UIの状態を表す。
- 利点:
- よく構造化されており、スケーラブル。
- ビジネスロジックの明確な分離。
- 強力なコミュニティと良好なドキュメント。
- 欠点:
- 冗長でボイラープレートが多いことがある。
- 初学者には学習曲線が急である。
2. Provider
- コアコンセプト: Providerは、InheritedWidgetに基づいたシンプルで直感的な状態管理と依存性注入の解決策である。
-
アーキテクチャ:
- ChangeNotifier: notifyListeners()を使用して状態を管理する簡単な方法。
- Provider: ウィジェットツリーに状態を公開する。
- 利点:
- 使いやすく、Flutterのビルドシステムとよく統合されている。
- ボイラープレートが少ない。
- 小規模から中規模のアプリケーションに最適。
- 欠点:
- Blocと比べると複雑な状態管理には不向き。
- アプリが大きくなるにつれて保守性が低下することがある。
3. Riverpod
- コアコンセプト: RiverpodはProviderの上に構築され、その制限を解決する。より堅牢で柔軟な方法で状態と依存関係を管理する。
-
アーキテクチャ:
- Providers: 状態を公開する主要なビルディングブロック。
- Consumers: 状態変化をリッスンするウィジェット。
- 利点:
- コンパイル時の安全性とパフォーマンスの向上。
- 複数のプロバイダーをサポートし、テストが容易。
- Providerの一般的な問題を回避（例えば、コンテキストの誤使用）。
- 欠点:
- ProviderやBlocよりも新しく、成熟度が低い。
- 特有のコンセプトと構文を理解する必要がある。
4. GetX
- コアコンセプト: GetXは軽量で強力な状態管理ソリューションで、依存性注入とルート管理を内蔵している。
-
アーキテクチャ:
- Controllers: 状態とビジネスロジックを管理する。
- Observers: 状態の変化をリッスンする。
- 利点:
- ボイラープレートが少なく、非常にシンプルに使える。
- 高性能なリアクティブプログラミング。
- ルーティングと依存性管理のためのビルトインユーティリティ。
- 欠点:
- Blocと比べて構造が少ない。
- 乱雑なコーディング習慣を助長する可能性がある。
5. MobX
- コアコンセプト: MobXは観察可能とリアクションを使用して状態を管理するリアクティブプログラミングスタイルを採用している。
-
アーキテクチャ:
- Observables: リアクティブな状態を表す。
- Actions: 観察可能を変更する関数。
- Reactions: 観察可能の変化に反応してUIを更新する。
- 利点:
- 高度にリアクティブで、リアクティブプログラミングに慣れている人にとって直感的。
- ボイラープレートが少ない。
- 既存のプロジェクトに簡単に統合できる。
- 欠点:
- リアクティブプログラミングの概念をよく理解している必要がある。
- 大規模なアプリケーションでは複雑になる可能性がある。
6. Redux
- コアコンセプト: ReduxはDartアプリケーションのための予測可能な状態コンテナで、JavaScriptのReduxライブラリに触発されている。
-
アーキテクチャ:
- Store: アプリケーションの状態を保持する。
- Actions: アプリケーションからReduxストアにデータを送る情報のペイロードを表す。
- Reducers: 現在の状態とアクションを受け取り、新しい状態を返す純粋関数。
- 利点:
- 予測可能な状態管理で一元化された真実のソース。
- スケーラブルで大規模なアプリケーションに適している。
- 強力なエコシステムとコミュニティサポート。
- 欠点:
- ボイラープレートが多く、冗長になりがち。
- 学習曲線が急で、特に他のフレームワークでReduxに慣れていない場合。
各状態管理ソリューションにはそれぞれの強みがあり、アプリケーションの種類や開発者の好みに応じて適したものを選ぶことができる。
Clean Architectureの実装に適したもの
Clean Architectureは関心の分離、テスト性、メンテナンス性を重視するソフトウェア設計哲学である。通常、アプリケーションを以下のような層に分ける:
- プレゼンテーション: UIコンポーネント。
- ドメイン: ビジネスロジックとドメインエンティティ。
- データ: データアクセスとリポジトリ層。
これらの原則を考慮すると、Clean Architectureの実装に特に適した状態管理ソリューションは以下の通りである:
1. Bloc (Business Logic Component)
適性:
- Blocはビジネスロジックをプレゼンテーション層から明確に分離できるため、Clean Architectureに非常に適している。
- イベントと状態の使用は、Clean Architectureの異なる層間の相互作用とよく一致する。
- Blocは一方向のデータフローを促進し、管理とデバッグを容易にする。
適している理由:
- 関心の分離: BlocはビジネスロジックをBlocに隔離し、UIの関心事をプレゼンテーション層に保持できる。
- テスト性: Blocは純粋なDartクラスであるため、ユニットテストが容易である。
- スケーラビリティ: Blocの構造は大規模で複雑なアプリケーションにも適している。
2. Provider
適性:
- ProviderもClean Architectureと一緒に使用でき、特に小規模から中規模のアプリケーションに適している。
- 最小限のボイラープレートで依存性注入と状態管理を提供する。
適している理由:
- 関心の分離: Blocほど構造化されていないが、ChangeNotifierやValueNotifierを使用することでUIとビジネスロジックを明確に分離できる。
- 柔軟性: Providerは柔軟で、Clean Architectureでよく使用されるMVVM（Model-View-ViewModel）パターンと一緒に使用できる。
- 使いやすさ: Blocと比べてセットアップと使用が簡単であり、小規模なプロジェクトやチームに有利である。
3. Riverpod
適性:
- RiverpodはProviderの制限を解決し、より堅牢で柔軟な方法で状態と依存関係を管理する。
- 高性能で安全なコンパイル時の保証を提供する。
適している理由:
- コンパイル時の安全性: Riverpodはコンパイル時の安全性を提供し、Providerの一般的な問題を回避する。
- スケーラビリティ: 柔軟性と強力な機能により、大規模なアプリケーションに適している。
- テスト性: Riverpodの設計はテストが容易であり、Clean Architectureの重要な側面である。
4. Redux
適性:
- Reduxも強い一方向のデータフローと集中管理された状態管理を重視しており、Clean Architectureに適している。
- 状態の予測性と一貫性が重要なアプリケーションに有利である。
適している理由:
- 一元化された真実のソース: Reduxのシングルストアは、状態管理を予測可能でデバッグが容易にする。
- 明確な分離: Actions、Reducers、Middlewareは、関心の分離を明確にする。
- テスト性: Reduxの純粋関数（Reducers）はテストが容易である。
5. GetX
適性:
- GetXは強力で使いやすいが、BlocやReduxほど関心の分離を促進しない場合がある。
- 関心の分離を厳密に守ることで、Clean Architectureに適用することができる。
適している理由:
- ボイラープレートが少ない: GetXはボイラープレートが少なく、開発スピードを向上させる。
- 高性能: リアクティブプログラミングを使用することで、非常に応答性の高いUIを実現できる。
- 柔軟性: GetXは依存性注入とルーティングのビルトインソリューションを提供する。
推奨
Clean Architectureを実装する場合、BlocとRiverpodが最も推奨される。これらは関心の分離、テスト性、スケーラビリティの原則と強く一致するためである。Reduxも、状態の予測性と一貫性が求められるアプリケーションには強力な候補となる。
Blocは、ビジネスロジックを明確に分離した高度に構造化されたスケーラブルなソリューションを求める場合に特に適している。Riverpodは、柔軟性とモダンな機能を提供し、パフォーマンスと安全性を向上させることで、クリーンで保守しやすいコードベースを維持するのに最適である。