Chapter 04無料公開

Riverpodとは

村松龍之介
村松龍之介
2021.05.08に更新

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」と呼称することとします。
「旧」が付いていない場合は、Riverpod内のProviderを示していると思ってください。

旧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の方が広く普及しているので、情報量では分がありそうです。

旧Providerで作っていプロダクトをRiverpodに移行するかどうかは、旧Providerに不満を感じているか、
リファクタリングのモチベーションを得られるかによりそうです。

僕も自分のアプリを旧ProviderからRiverpodに移行した経験がありますが、想定より大変さは感じませんでした。
(アプリ規模に依存するかと思います)


次章では、「Riverpodの選び方とインストール方法」を解説します。


参考リンク

Provider, but different | Riverpod

https://riverpod.dev/
脚注
  1. https://github.com/rrousselGit ↩︎
  2. https://pub.dev/packages/provider ↩︎
  3. https://pub.dev/packages/freezed ↩︎
  4. https://pub.dev/packages/flutter_hooks ↩︎
  5. 実行時にインスタンスが単一になるような設計のこと。どこからProviderにアクセスしても同一インスタンスを使うことになるため、パフォーマンスの向上や状態の共有などのメリットがある。 ↩︎

  6. 「Dependency Injection」日本語では「依存注入」や「依存性注入」と訳される。コンポーネント(クラス等)にて、利用したい具体的なコンポーネントを内部で指定せず、利用者側に委ねることで依存関係を薄くすることができ、テスト容易性も向上する。(依存の注入方法として、インターフェース注入・コンストラクタ注入等がある) ↩︎