Flutter 状态管理库 Riverpod

人肉翻译了下 Flutter状态管理库 Riverpod 的官方文档，这里作个汇总，便于整体浏览。译时版本： 2.4.9

钩子是一个强大的工具，但是不是对所有人。 如果是 Riverpod 的新人，很可能应该避免使用钩子。 虽然很有用，钩子对于 Riverpod 也不是必须的。 不应该是因为使用 Riverpod 而使

代码生成的想法是使用工具为我们生成代码。在 Dart 中，带来的副作用就是需要“编译”应用的附加步骤。该问题在不久的将来可能会被解决，因为 Dart 开发组已经在致力于该问题的潜在解决方案。

用至今为止前面看到的所有内容，已经可以构建一个完整的功能性应用了。 尽管如此，可能还是会有一些性能考量方面的问题。 本篇文章会提供一些提示和技巧来尽可能地改善代码。

因为应用会越来越复杂，所以同时有多个网络请求在执行是很常见的。 例如，一个用户可能在搜索框里输入时，每敲击一个按键就会触发一个新的请求。 如果用户输入地很快，应用就可能会同时发出去多个请求。

Riverpod 得益于其声明式的属性天生支持下拉刷新。 通常，下拉刷新都很复杂，因其需要解决多个问题： 第一次进入某个画面时，想要表示一个加载中的指示器。但是在刷新时，是想要表示刷新指示器。不应

要确保代码的优良维护性，这有一个使用 Rivderpod 时应该遵循的优秀实践列表。 该列表并不完整，并且还会继续修改。 如果有任何问题，可以直接开issue。 该列表的项目并无特定先后顺序。

这里有一些社区中常被问到的问题： ref.refresh 和 ref.invalidate 有什么区别？为什么在 Ref 和 WidgetRef 之间没有共享接口？为什么要继承 ConsumerWid

Riverpod原生提供了监听 provider 树中发生的所有事件的手段。 这可以用来记录所有事件的日志，或向远程服务报告错误。

Riverpod API 的一个核心部分是独立测试 provider 的能力。 对于一个合适的测试集，需要克服一些挑战： 测试不应共享状态。这意味着新的测试不应当受到前一个测试的影响。 测试应该赋

所有的 provider 默认都是初始化为懒汉式。这意味着 provider 只会在第一次被读取时初始化。这对于只在应用的特定部分使用的 provider 是有用的。

迄今为止，已经看到了如何创建/更新一些状态。但是还没有讨论状态清除时发生的处理。 Riverpod 提供了多种方式和状态清除进行交互。从延迟状态的清除到析构的响应。

迄今为止，只看到了相互独立请求的场景。但是一个常见的使用场景是需要基于另一个请求的结果触发某个请求。 可以使用 向请求传递参数 [中文]机制来实现，把一个 provider 的结果作为参数传递给另一

特别是，除了 `Future` ，provider 还可自由用于： - 同步式返回对象，比如创建 "Repository" 。 - 返回 `Stream` （流），比如监听 websocket

在前面的文章中，看到了如何定义 "provider" 创建简单的 GET HTTP 请求。 不过通常 HTTP 请求需要外部参数。 例如，前面使用了 Bored API 给用户一个随机 activi

至今为止，只看了如何获取数据（也称作执行 *GET* HTTP 请求）。 但是副作用怎么办？比如 *POST* 请求？ 应用通常会实现 CRUD（增、查、改、删）API。 对于这些常见的做法

网络请求是大部分应用的核心。但是创建网络请求有大量需要考虑的地方： - 创建请求时 UI 应该渲染加载中的状态 - 错误应该被优雅地处理 - 如果可能请求应该被缓存起来

本篇会回答以下问题： 既然 Provider 受到广泛欢迎，为什么需要迁移到 Riverpod ？ 能获得哪些具体的好处？ 如何迁移到 Riverpod ？ 能渐进式迁移吗？ 等

Provider vs Riverpod 该文章简要描述了 Provider 和 Riverpod 的差异点和相似点。

该部分是为了习惯使用 Provider 想要了解 Riverpod 的目标人群而设计。在开始之前先读一下开始使用Riverpod并尝试一个 sandbox 小例子来测试下 Riverpod