一般社団法人 全国個人事業主支援協会

COLUMN コラム

Flutterで状態管理といえば、providerriverpodを使った実装が主流になりつつあります。中でもProviderとそのバリエーションであるProvider.family(以下、単にfamily)の使い分けは、プロジェクトが複雑になるほど重要な選択となります。

今回は、Providerfamilyの違いと、それぞれをどう使い分けるべきかを実際のユースケースとともに整理してみます。


そもそもProviderfamilyの違いとは?

  • Provider
    単一のインスタンスを提供する、最も基本的なプロバイダ。アプリ内でその型の状態が1つだけ存在すれば十分、という場合に使います。

  • family
    引数付きで状態を生成できる拡張バージョン。例えば、「同じロジックだけど異なるIDごとのデータを扱いたい」といった場面で重宝します。



どっちを使うべき?判断のポイント

 単一の状態 or グローバルな設定 → Provider

  • ログインユーザー情報

  • アプリ全体の設定(テーマ・言語など)

  • サービスクラス(UseCaseやRepositoryなど)

final authServiceProvider = Provider((ref) => AuthService());

パラメータごとの状態が必要 → family

  • ユーザーIDごとのデータ取得

  • ページIDやカテゴリIDごとの状態

  • 動的に変わる依存関係があるとき

final productDetailProvider = FutureProvider.family<Product, int>((ref, productId) {
return productRepository.getProduct(productId);
});

実務でのTips

1. familyはキャッシュされる

一度作成したfamilyのインスタンスは同じ引数で再度呼び出すとキャッシュが使われます。つまり、同じIDであれば無駄なAPIコールなどは避けられる。

2. 複雑な初期化処理はUseCase + familyで解決

複数パラメータが絡む初期化処理や依存関係の注入が必要な場合、familyUseCaseを生成することで責務が明確になります。

dart
final fetchUserUseCaseProvider = Provider.family<FetchUserUseCase, String>((ref, userId) {
return FetchUserUseCase(ref.read(userRepositoryProvider), userId);
});

3. 可読性のために命名ルールを統一する

  • 通常:xxxProvider

  • family:xxxProvider.family または xxxFamilyProvider


まとめ:選択は「状態の単位」で決める

状況 選ぶべきProvider
アプリ内に1つだけ必要な状態 Provider
パラメータごとに状態が変わる Provider.family
Viewごとに依存関係が動的に変わる Provider.family + AutoDispose

状態がどの単位で切り替わるべきか、どこまで使い回すべきか。この見極めがProvider設計の核心です。

状態管理はチームの共通言語。設計の一貫性が保たれることで、可読性と保守性は確実に上がります。

もしチームで運用しているなら、「いつfamilyを使うか」をルールとして明文化しておくのもおすすめです。

The following two tabs change content below.

この記事をシェアする

  • Twitterでシェア
  • Facebookでシェア
  • LINEでシェア