flutter-state-management

Flutter の状態管理

まず所有権とライフタイムを確認してから、仕組みを選びます。

調査

状態が一時的な UI 状態、機能の状態、アプリケーション共有状態、キャッシュされたサーバーデータ、永続化データのどれに該当するかを特定します。誰が状態を作成、変更、監視、破棄するのかを確認します。

ルール

• 利用側が許容する範囲で、状態をできるだけ局所化します。
• 信頼できる唯一の情報源を維持し、値のコピーを同期するのではなく、二次的な値を導出します。
• 状態遷移を明示し、副作用をウィジェットの build メソッドの外に置きます。
• 既存のパッケージが適切に機能している場合は、そのパッケージと慣例を維持します。
• 新規プロジェクトでは、人気だけでなく、複雑さ、チームの習熟度、テスト容易性、コード生成への許容度、ライフサイクルの要件に基づいて選びます。
• 不変の状態、または可変コレクションの読み取り専用ビューを公開します。
• UI で区別が必要な場合は、読み込み中、空、成功、失敗の状態を意図的にモデル化します。
• 関係のないサブツリーまで再ビルドする広範なサブスクリプションは避けます。
• パッケージの監視用アクセサー（ref.watch、context.watch<T>()、BlocBuilder）は build または別の監視可能なメソッド内でのみ使用し、単発のアクセサー（ref.read、context.read<T>()、Bloc の add）はコールバックやイベントハンドラー内で使用します。ほとんどのパッケージでは、コールバックから監視用アクセサーを呼び出すと例外が発生するか、正しく動作しません。

所有権が不明確な問題を手早く解決するために、グローバルなサービスロケーターやパッケージレベルのシングルトンを導入しないでください。

検証

重要な状態遷移、障害からの復旧、破棄、イベントの繰り返しをテストします。処理頻度の高い箇所では再ビルドの範囲を確認し、状態から UI への反映をウィジェットテストで検証します。

境界

アーキテクチャ全体の依存関係の方向性は flutter-architecture に、永続化とリモートキャッシュはそれぞれのデータ専門分野に委ねます。

破棄の挙動やライフサイクルのリークが対象となる場合は、ライフサイクルと破棄のリファレンスに従ってください。非同期状態のモデル化とエラーからの復旧については、非同期状態パターンのリファレンスに従ってください。

ソース

• Flutter の状態管理の基礎