【Flutter】Riverpodのv2対応の公式ドキュメントでの気づきをまとめてみた

はじめに

10月の中旬ごろにリニューアル中だったRiverpodの公式ドキュメントが完成したようです。
最新版を読み直して気づいたことなどをまとめていければと思います。

riverpod_lint

riverpod_listというRiverpod用のlintルールを適用できるパッケージがあるようです。

• Consumerでのラップオプションの追加
• ConsumerWidgetへの変換オプションの追加
• Riverpod関連のlint設定

ができるようなので、入れておくのが良いと思います。
riverpodの作者も導入を推奨しているようです。

Flutter Riverpod Snippets

VSCodeの拡張機能。
providerの記述が楽になるかもです。　　 riverpod_generatorを使っている場合はProviderを自ら記述する機会があまりないと思うので、導入するメリットが少なくなるかもです。
https://marketplace.visualstudio.com/items?itemName=robert-brunhage.flutter-riverpod-snippets

3つのAsyncNotifierのStateの更新方法

1. state = AsyncData(response) を使用する

メリット
APIからのレスポンスをそのままstateに入れることができるのであればシンプルに書ける。

デメリット

• APIからのレスポンスがない場合には話は変わってくる。
• GET系のAPI側で勝手にフィルタリングやソートを行ってくれている場合などは、フロントエンド側で処理を行わないといけなくなるので、やや複雑になる

例

Future<void> addTodo(Todo todo) async {
  // The POST request will return a List<Todo> matching the new application state
  final response = await http.post(
    Uri.https('your_api.com', '/todos'),
    headers: {'Content-Type': 'application/json'},
    body: jsonEncode(todo.toJson()),
  );

  // We decode the API response and convert it to a List<Todo>
  List<Todo> newTodos = (jsonDecode(response.body) as List)
      .cast<Map<String, Object?>>()
      .map(Todo.fromJson)
      .toList();

  // We update the local cache to match the new state.
  // This will notify all listeners.
  state = AsyncData(newTodos);
}

2. ref.invalidateSelf() を使用してproviderを再度初期化する

メリット

• GET APIのリクエストでフィルタリングやソートなどを行っている場合はこちらが良い

デメリット

• GET APIなどを再実行するのでパフォーマンスは悪くなるケースがある

例

Future<void> addTodo(Todo todo) async {
  // We don't care about the API response
  await http.post(
    Uri.https('your_api.com', '/todos'),
    headers: {'Content-Type': 'application/json'},
    body: jsonEncode(todo.toJson()),
  );

  // Once the post request is done, we can mark the local cache as dirty.
  // This will cause "build" on our notifier to asynchronously be called again,
  // and will notify listeners when doing so.
  ref.invalidateSelf();

  // (Optional) We can then wait for the new state to be computed.
  // This ensures "addTodo" does not complete until the new state is available.
  await future;
}

3. 手動でのStateの更新

メリット

• 余計なAPIコールがない

デメリット

• 基本的にDBの情報が正だが、それと異なるデータになってしまう可能性がある(別ユーザーがDBを書き換えていた場合など)

例

Future<void> addTodo(Todo todo) async {
  // We don't care about the API response
  await http.post(
    Uri.https('your_api.com', '/todos'),
    headers: {'Content-Type': 'application/json'},
    body: jsonEncode(todo.toJson()),
  );

  // We can then manually update the local cache. For this, we'll need to
  // obtain the previous state.
  // Caution: The previous state may still be loading or in error state.
  // A graceful way of handling this would be to read `this.future` instead
  // of `this.state`, which would enable awaiting the loading state, and
  // throw an error if the state is in error state.
  final previousState = await future;

  // We can then update the state, by creating a new state object.
  // This will notify all listeners.
  state = AsyncData([...previousState, todo]);
}

providerにfamilyをつける場合

autoDisposeをなるべくつけておいた方が良い。
引数毎にインスタンスが生成されるため、メモリリークの原因になりやすい。

注意

同じ引数かどうかの判定にあたり、引数の == オペレータを頼りに判別するため、引数に入れた変数が == オペレータをオーバーライドしていない場合は、同じ引数判定ができない。

具体例

ref.watch(activityProvider(['recreational', 'cooking']));

['recreational', 'cooking'] == ['recreational', 'cooking'] はfalseになるため、同じ引数判定ができない。
=> riverpod_listで警告が出るはず。

invalidateの挙動の違い

• 引数なしの場合: 全(label)providerがリフレッシュされる
• 引数ありの場合: 特定のproviderのみがリフレッシュされる

具体例

void onTap() {
  // Invalidate all possible parameter combinations of this provider.
  ref.invalidate(labelProvider);
  // Invalidate a specific combination only
  ref.invalidate(labelProvider('John'));
}

ProviderObserverについて

ProviderObserverを使えば以下の4つイベントが取得できる。

- `didAddProvider`, called when a provider is added to the tree
- `didUpdateProvider`, called when a provider is updated
- `didDisposeProvider`, called when a provider is disposed
- `providerDidFail`, when a synchronous provider throws an error

非同期の(asynchronous)providerの場合はAsyncErrorでなく、didAppProvider,didUpdateProvider側でエラーがキャッチするようになっている
⇒ riverpod3.0以降で修正予定のようです。

ref.refreshとref.invalidateの違い

ref.refresh = invalidate + read。invalidateした後に最新値を取得したい場合はrefreshを使うと良い。

T refresh<T>(provider) {
  invalidate(provider);
  return read(provider);
}

providerの初期化タイミングについて

Widget内のinitStateでなく、遷移処理の直前の方が良い。

Don't

class WidgetState extends State<MyWidget> {
  @override
  void initState() {
    super.initState();
    // Bad: the provider should initialize itself
    ref.read(provider).init();
  }
}

Do
遷移処理前に初期化しておく。

ElevatedButton(
  onPressed: () {
    ref.read(provider).init();
    Navigator.of(context).push(...);
  },
  child: Text('Navigate'),
)

providerはtop-levelのfinal変数にするべき

Don't

class Example {
  // Unsupported operation. Could cause memory leaks and unexpected behaviors.
  final provider = Provider<String>((ref) => 'Hello world');
}

Do

final provider = Provider<String>((ref) => 'Hello world');

Exampleクラスのインスタンスがプロジェクト内で1つではない場合に、providerがdisposeされずに永遠に残ってしまうとかかな?
シングルトンなどを使っていない場合は、同じインスタンスにアクセスしようと思ってもできなかったり?
ちょっと意図が微妙に掴めていないかも。

Widget内のローカルStateなどの管理にProviderを使うのは避ける

Widget内部のローカルの状態管理はflutter_hooksを使いましょうとのこと。
providerはtop-levelのfinal変数として扱われるべきだという話もあり、他の画面などからローカルのStateにアクセスできてしまうのは良くないという理由でしょう。
providerをプライベート変数にするなどで解決もできそうですが、公式ドキュメント通りに実装するということであれば、flutter_hooksを使う実装の方が良いのかもしれませんね。

ref.watchでselectを使う価値があまりないケース

stateのその他プロパティがほとんど更新されないケース。
selectを使用すると、個々の読み取り操作が若干遅くなり、コードの複雑さがほんの少し増すため、他のプロパティがほとんど変更されないのであれば、selectを使って購読するプロパティを限定する価値がないようです。

最後に

今回はriverpodのリニューアルしたドキュメントで学んだことを列挙してみました。
個人的に新たに学べた場所を列挙しただけであり、人によって学べる内容は違うので、一度じっくり読んでみることを推奨します。
読んでいただいた方に新しい発見があれば幸いです。

参考

https://riverpod.dev/