Riverpodとは
RiverpodはDart, Flutterで使用できる「状態管理ライブラリ」です。
作者は「Remi Rousselet[1]」さん。
Riverpodの他にも「provider[2]」、「freezed[3]」、「flutter_hooks[4]」など、いくつもの有用Flutterライブラリを作成されています。
旧Provider（package:provider）とは
Riverpod内でも「Provider」という用語を使用するため、初見だと若干混乱するかもしれませんが、
前述の「provider」パッケージは「Riverpod」の前身となったライブラリです。
Flutter Favoriteであり、公式推奨パッケージの一つです。
Riverpodは、課題もあった「provider」を書き直し再構築されたライブラリで、
名前自体も 「provider」のアナグラムとなっています。 provider -> riverpod
旧Providerの課題を改善
旧Providerは、Flutterアプリの状態管理ライブラリとして多くの開発者に使われていましたが、いくつかの問題も抱えていました。
- 範囲外アクセスなどで、コンパイルエラーではなく実行時例外が発生する
- providerを購読したり結合する構文でネストが発生する
- 同じ型のproviderを複数同時に利用することができない
など。
Riverpodでは、その問題点が改善されており、まさに書き直された新しいProviderと言えます。
Riverpodで状態をラップすることによるメリット
- Widgetの再構築時に状態を失うことなく、状態を安全に作成・監視・破棄できる
- DevtoolのProviderScopeで状態を非入れ子構造で表示できる
- グローバル変数として定義するため、アクセスが保証されるのと同時にテスト容易性も担保
- 複数の場所から、簡単に状態へアクセス可能になる
シングルトン[5]、DI（依存注入）[6]、継承Widgetの代替になる - 「状態」を別の「状態」と組み合わせが簡単になる
- パフォーマンスの向上
状態の変化によって影響を受けるもののみが再計算されるのでWidgetの再構築（Rebuild）が最適化されます。 - テスト容易性の向上
複雑なsetUp/tearDownステップが手順が不要になり、Providerを上書きできるので特定の動作テストが簡単です。 - ロギングやPull-to-refresh（引っ張って更新）などの高度な機能と簡単に統合可能
Riverpod と 旧Providerどちらを選ぶか？
同作者が作り直したこともあり、全体的にRiverpodの方が優れており、作者も使用を推奨しています。
これから新規アプリを作成する場合はRiverpodを選ぶ利点が勝ると考えています。
以前は旧Providerの方が広く普及しており、Riverpodの情報量に不安がありましたが、2023年2月現在Riverpodの情報も随分と多くなりました。
旧Providerで作っていプロダクトをRiverpodに移行するかどうかは、旧Providerに不満を感じているか、リファクタリングのモチベーションを得られるかによりそうです。
僕も自分のアプリを旧ProviderからRiverpodに移行した経験がありますが、想定より大変さは感じませんでした。
（もちろん、アプリ規模に依存するかと思います）
次章では、「Riverpodの選び方とインストール方法」を解説します。
参考リンク
Provider, but different | Riverpod