重走Flutter状态管理之路—Riverpod入门篇

Posted eclipse_xu

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了重走Flutter状态管理之路—Riverpod入门篇相关的知识,希望对你有一定的参考价值。

点击上方蓝字关注我,知识会给你力量

熟悉我的朋友应该都知道,我好几年前写过一个「Flutter状态管理之路」系列,那个时候介绍的是Provider,这也是官方推荐的状态管理工具,但当时没有写完,因为写着写着,觉得有很多地方不尽人意,用着很别扭,所以在写了7篇文章之后,就暂时搁置了。

一晃时间过了这么久,Flutter内部依然没有一个能够碾压一切的状态管理框架,GetX可能是,但是我觉得不是,InheritedWidget系的状态管理,才应该是正统的状态管理。

最近在留意Provider的后续进展时,意外发现了一个新的库——Riverpod,号称是新一代的状态管理工具,仔细一看,嘿,居然还是Provider的作者,好家伙,这是搬起石头砸自己的脚啊。

就像作者所说,Riverpod就是对Provider的重写,可不是吗,字母都没变,就换了个顺序,这名字也是取的博大精深。

其实Provider在使用上已经非常不错了,只不过随着Flutter的更加深入,大家对它的需求也就越来越高,特别是对Provider中因为InheritedWidget层次问题导致的异常和BuildContext的使用这些问题诟病很多,而Riverpod,正是在Provider的基础上,探索出了一条心的状态管理之路。

大家可以先把官方文档看一看 https://riverpod.dev ,看完之后发现还是一脸懵逼,那就对了,Riverpod和Provider一样,有很多类型的Provider,分别用于不同的场景,所以,理清这些Provider的不同作用和使用场景,对于我们用好Riverpod是非常有帮助的。

官网的文档,虽然是作者精心编写的,但它的教程,站在的是一个创作者的角度,所以很多入门的初学者看上去会有点摸不清方向,所以,这才有了这个系列的文章。

我将在这个系列中,带领大家对文档进行一次精读,进行一次赏析,本文不全是对文档的翻译,而且讲解的顺序也不一样,所以,如果你想入门Riverpod进行状态管理,那么本文一定是你的最佳选择。

Provider第一眼

首先,我们为什么要进行状态管理,状态管理是解决申明式UI开发,关于数据状态的一个处理操作,例如Widget A依赖于同级的Widget B的数据,那么这个时候,就只能把数据状态上提到它们的父类,但是这样比较麻烦,Riverpod和Provider这样的状态管理框架,就是为了解决类似的问题而产生的。

将一个state包裹在一个Provider中可以有下面一些好处。

  • 允许在多个位置轻松访问该状态。Provider可以完全替代Singletons、Service Locators、依赖注入或InheritedWidgets等模式

  • 简化了这个状态与其他状态的结合,你有没有为,如何把多个对象合并成一个而苦恼过?这种场景可以直接在Provider内部实现

  • 实现了性能优化。无论是过滤Widget的重建,还是缓存昂贵的状态计算;Provider确保只有受状态变化影响的部分才被重新计算

  • 增加了你的应用程序的可测试性。使用Provider,你不需要复杂的setUp/tearDown步骤。此外,任何Provider都可以被重写,以便在测试期间有不同的行为,这可以轻松地测试一个非常具体的行为

  • 允许与高级功能轻松集成,如logging或pull-to-refresh

首先,我们通过一个简单的例子,来感受下,Riverpod是怎么进行状态管理的。

Provider是Riverpod应用程序中最重要的部分。Provider是一个对象,它封装了一个state并允许监听该state。Provider有很多变体形式,但它们的工作方式都是一样的。

最常见的用法是将它们声明为全局常量,例如下面这样。

final myProvider = Provider((ref) 
  return MyValue();
);

不要被Provider的全局变量所吓倒。Provider是完全final的。声明一个Provider与声明一个函数没有什么不同,而且Provider是可测试和可维护的。

这段代码由三个部分组成。

  • final myProvider,一个变量的声明。这个变量是我们将来用来读取我们Provider的状态的。Provider应该始终是final的

  • Provider,我们决定使用的Provider类型。Provider是所有Provider类型中最基本的。它暴露了一个永不改变的对象。我们可以用其他Provider如StreamProvider或StateNotifierProvider来替换Provider,以改变值的交互方式

  • 一个创建共享状态的函数。该函数将始终接收一个名为ref的对象作为参数。这个对象允许我们读取其他Provider,在我们Provider的状态将被销毁时执行一些操作,以及其它一些事情

传递给Provider的函数返回的对象的类型,取决于所使用的Provider。例如,一个Provider的函数可以创建任何对象。另一方面,StreamProvider的回调将被期望返回一个Stream。

你可以不受限制地声明你想要的多个Provider。与使用package:provider不同的是,Riverpod允许创建多个暴露相同 "类型 "的状态的provider。

final cityProvider = Provider((ref) => 'London');
final countryProvider = Provider((ref) => 'England');

两个Provider都创建了一个字符串,但这并没有任何问题。

为了使Provider发挥作用,您必须在Flutter应用程序的根部添加ProviderScope。

void main() 
  runApp(ProviderScope(child: MyApp()));

以上就是Riverpod最简单的使用,我们看下完整的示例代码。

import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';

// We create a "provider", which will store a value (here "Hello world").
// By using a provider, this allows us to mock/override the value exposed.
final helloWorldProvider = Provider((_) => 'Hello world');

void main() 
  runApp(
    // For widgets to be able to read providers, we need to wrap the entire
    // application in a "ProviderScope" widget.
    // This is where the state of our providers will be stored.
    ProviderScope(
      child: MyApp(),
    ),
  );


// Extend ConsumerWidget instead of StatelessWidget, which is exposed by Riverpod
class MyApp extends ConsumerWidget 
  @override
  Widget build(BuildContext context, WidgetRef ref) 
    final String value = ref.watch(helloWorldProvider);

    return MaterialApp(
      home: Scaffold(
        appBar: AppBar(title: const Text('Example')),
        body: Center(
          child: Text(value),
        ),
      ),
    );
  

可以发现,Riverpod的使用比package:Provider还要简单,申明一个全局变量来管理状态数据,然后就可以在任意地方获取数据了。

如何读取Provider的状态值

在有了一个简单的了解后,我们先来了解下关于状态中的「读」。

在Riverpod中,我们不像package:Provider那样需要依赖BuildContext,取而代之的是一个「ref」变量。这个东西,就是联系存取双方的纽带,这个对象允许我们与Provider互动,不管是来自一个Widget还是另一个Provider。

从Provider中获取ref

所有Provider都有一个 "ref "作为参数。

final provider = Provider((ref) 
  // use ref to obtain other providers
  final repository = ref.watch(repositoryProvider);

  return SomeValue(repository);
)

这个参数可以安全地传递给其它Provider或者类,来获取所需要的值。

例如,一个常见的用例是将Provider的 "ref "传递给一个StateNotifier。

final counterProvider = StateNotifierProvider<Counter, int>((ref) 
  return Counter(ref);
);

class Counter extends StateNotifier<int> 
  Counter(this.ref): super(0);

  final Ref ref;

  void increment() 
    // Counter can use the "ref" to read other providers
    final repository = ref.read(repositoryProvider);
    repository.post('...');
  

这样做,可以使我们的Counter类能够读取Provider。

这种方式是联系组件和Provider的一个重要方式。

从Widget中获取ref

Widgets自然没有一个ref参数。但是Riverpod提供了多种解决方案来从widget中获得这个参数。

扩展ConsumerWidget

在widget树中获得一个ref的最常见的方法是用ConsumerWidget代替StatelessWidget。

ConsumerWidget在使用上与StatelessWidget相同,唯一的区别是它的构建方法上有一个额外的参数:"ref "对象。

一个典型的ConsumerWidget看起来像这样。

class HomeView extends ConsumerWidget 
  const HomeView(Key? key): super(key: key);

  @override
  Widget build(BuildContext context, WidgetRef ref) 
    // use ref to listen to a provider
    final counter = ref.watch(counterProvider);
    return Text('$counter');
  
扩展ConsumerStatefulWidget

与ConsumerWidget类似,ConsumerStatefulWidget和ConsumerState相当于一个带有状态的StatefulWidget,不同的是,state有一个 "ref "对象。

这一次,"ref "不是作为构建方法的参数传递,而是作为ConsumerState对象的一个属性。

class HomeView extends ConsumerStatefulWidget 
  const HomeView(Key? key): super(key: key);

  @override
  HomeViewState createState() => HomeViewState();


class HomeViewState extends ConsumerState<HomeView> 
  @override
  void initState() 
    super.initState();
    // "ref" can be used in all life-cycles of a StatefulWidget.
    ref.read(counterProvider);
  

  @override
  Widget build(BuildContext context) 
    // We can also use "ref" to listen to a provider inside the build method
    final counter = ref.watch(counterProvider);
    return Text('$counter');
  

通过ref来获取状态

现在我们有了一个 "ref",我们可以开始使用它。

ref "有三个主要用途。

  • 获得一个Provider的值并监听变化,这样,当这个值发生变化时,这将重建订阅该值的Widget或Provider。这是通过ref.watch完成的

  • 在一个Provider上添加一个监听器,以执行一个action,如导航到一个新的页面或在该Provider发生变化时执行一些操作。这是通过 ref.listen 完成的

  • 获取一个Provider的值,同时忽略它的变化。当我们在一个事件中需要一个Provider的值时,这很有用,比如 "点击操作"。这是通过ref.read完成的

只要有可能,最好使用 ref.watch 而不是 ref.read 或 ref.listen 来实现一个功能。通过依赖ref.watch,你的应用程序变得既是反应式的又是声明式的,这使得它更容易维护。

通过ref.watch观察Provider的状态

ref.watch在Widget的构建方法中使用,或者在Provider的主体中使用,以使得Widget/Provider可以监听另一个Provider。

例如,Provider可以使用 ref.watch 来将多个Provider合并成一个新的值。

一个例子是过滤一个todo-list,我们需要两个Provider。

  • filterTypeProvider,一个暴露当前过滤器类型的Provider(None,表示只显示已完成的任务)

  • todosProvider,一个暴露整个任务列表的Provider

通过使用ref.watch,我们可以制作第三个Provider,结合这两个Provider来创建一个过滤后的任务列表。

final filterTypeProvider = StateProvider<FilterType>((ref) => FilterType.none);
final todosProvider = StateNotifierProvider<TodoList, List<Todo>>((ref) => TodoList());

final filteredTodoListProvider = Provider((ref) 
  // obtains both the filter and the list of todos
  final FilterType filter = ref.watch(filterTypeProvider);
  final List<Todo> todos = ref.watch(todosProvider);

  switch (filter) 
    case FilterType.completed:
      // return the completed list of todos
      return todos.where((todo) => todo.isCompleted).toList();
    case FilterType.none:
      // returns the unfiltered list of todos
      return todos;
  
);

有了这段代码,filteredTodoListProvider现在就可以管理过滤后的任务列表。

如果过滤器或任务列表发生变化,过滤后的列表也会自动更新。同时,如果过滤器和任务列表都没有改变,过滤后的列表将不会被重新计算。

类似地,一个Widget可以使用ref.watch来显示来自Provider的内容,并在该内容发生变化时更新用户界面。

final counterProvider = StateProvider((ref) => 0);

class HomeView extends ConsumerWidget 
  const HomeView(Key? key): super(key: key);

  @override
  Widget build(BuildContext context, WidgetRef ref) 
    // use ref to listen to a provider
    final counter = ref.watch(counterProvider);

    return Text('$counter');
  

这段代码显示了一个Widget,它监听了一个存储计数的Provider。如果该计数发生变化,该Widget将重建,用户界面将更新以显示新的值。

ref.watch方法不应该被异步调用,比如在ElevatedButton的onPressed中。也不应该在initState和其他State的生命周期内使用它。在这些情况下,考虑使用 ref.read 来代替。

通过ref.listen监听Provider的变化

与ref.watch类似,可以使用ref.listen来观察一个Provider。

它们之间的主要区别是,如果被监听的Provider发生变化,使用ref.listen不会重建widget/provider,而是会调用一个自定义函数。

这对于在某个变化发生时执行某些操作是很有用的,比如在发生错误时显示一个snackbar。

ref.listen方法需要2个参数,第一个是Provider,第二个是当状态改变时我们要执行的回调函数。回调函数在被调用时将被传递2个值,即先前状态的值和新状态的值。

ref.listen方法也可以在Provider的体内使用。

final counterProvider = StateNotifierProvider<Counter, int>((ref) => Counter(ref));

final anotherProvider = Provider((ref) 
  ref.listen<int>(counterProvider, (int? previousCount, int newCount) 
    print('The counter changed $newCount');
  );
  // ...
);

或在一个Widget的Build方法中使用。

final counterProvider = StateNotifierProvider<Counter, int>((ref) => Counter(ref));

class HomeView extends ConsumerWidget 
  const HomeView(Key? key): super(key: key);

  @override
  Widget build(BuildContext context, WidgetRef ref) 
    ref.listen<int>(counterProvider, (int? previousCount, int newCount) 
      print('The counter changed $newCount');
    );
    
    return Container();
  

ref.listen也不应该被异步调用,比如在ElevatedButton的onPressed中。也不应该在initState和其他State的生命周期内使用它。

通过ref.read来读取Provider的状态

ref.read方法是一种在不监听的情况下获取Provider的状态的方法。

它通常用于由用户交互触发的函数中。例如,当用户点击一个按钮时,我们可以使用ref.read来增加一个计数器的值。

final counterProvider = StateNotifierProvider<Counter, int>((ref) => Counter(ref));

class HomeView extends ConsumerWidget 
  const HomeView(Key? key): super(key: key);

  @override
  Widget build(BuildContext context, WidgetRef ref) 
    return Scaffold(
      floatingActionButton: FloatingActionButton(
        onPressed: () 
          // Call `increment()` on the `Counter` class
          ref.read(counterProvider.notifier).increment();
        ,
      ),
    );
  

应该尽可能地避免使用ref.read,因为它不是响应式的。

它存在于使用watch或listen会导致问题的情况下。如果可以的话,使用watch/listen几乎总是更好的,尤其是watch。

关于ref.read到底什么时候用

首先,永远不要在Widget的build函数中直接使用ref.read。

你可能很想使用ref.read来优化一个Widget的性能,例如通过下面的代码来实现。

final counterProvider = StateProvider((ref) => 0);

Widget build(BuildContext context, WidgetRef ref) 
  // use "read" to ignore updates on a provider
  final counter = ref.read(counterProvider.notifier);
  return ElevatedButton(
    onPressed: () => counter.state++,
    child: const Text('button'),
  );

但这是一种非常糟糕的做法,会导致难以追踪的错误。

以这种方式使用 ref.read 通常与这样的想法有关:"Provider所暴露的值永远不会改变,所以使用'ref.read'是安全的"。这个假设的问题是,虽然今天该Provider可能确实从未更新过它的值,但不能保证明天也是如此。

软件往往变化很大,而且很可能在未来,一个以前从未改变的值需要改变。

如果你使用ref.read,当这个值需要改变时,你必须翻阅整个代码库,将ref.read改为ref.watch--这很容易出错,而且你很可能会忘记一些情况。

如果你一开始就使用ref.watch,你在重构时就会减少问题。

但是如果我想用ref.read来减少我的widget重构的次数呢?

虽然这个目标值得称赞,但需要注意的是,你可以用ref.watch代替来达到完全相同的效果(减少构建的次数)。

Provider提供了各种方法来获得一个值,同时减少重建的次数,你可以用这些方法来代替。

例如下面的代码(bad)。

final counterProvider = StateProvider((ref) => 0);

Widget build(BuildContext context, WidgetRef ref) 
  StateController<int> counter = ref.read(counterProvider.notifier);
  return ElevatedButton(
    onPressed: () => counter.state++,
    child: const Text('button'),
  );

我们可以这样改。

final counterProvider = StateProvider((ref) => 0);

Widget build(BuildContext context, WidgetRef ref) 
  StateController<int> counter = ref.watch(counterProvider.notifier);
  return ElevatedButton(
    onPressed: () => counter.state++,
    child: const Text('button'),
  );

这两个片段代码都达到了同样的效果:当计数器增加时,我们的按钮将不会重建。

另一方面,第二种方法支持计数器被重置的情况。例如,应用程序的另一部分可以调用。

ref.refresh(counterProvider);

这将重新创建StateController对象。

如果我们在这里使用ref.read,我们的按钮仍然会使用之前的StateController实例,而这个实例已经被弃置,不应该再被使用。

而使用ref.watch则可以正确地重建按钮,使用新的StateController。

关于ref.read可以读哪些值

根据你想监听的Provider,你可能有多个可能的值可以监听。

作为一个例子,考虑下面的StreamProvider。

final userProvider = StreamProvider<User>(...);

当读取这个userProvider时,你可以像下面这样。

  • 通过监听userProvider本身同步读取当前状态。

Widget build(BuildContext context, WidgetRef ref) 
  AsyncValue<User> user = ref.watch(userProvider);

  return user.when(
    loading: () => const CircularProgressIndicator(),
    error: (error, stack) => const Text('Oops'),
    data: (user) => Text(user.name),
  );
  • 通过监听userProvider.stream来获得相关的Stream。

Widget build(BuildContext context, WidgetRef ref) 
  Stream<User> user = ref.watch(userProvider.stream);
  • 通过监听userProvider.future获得一个Future,该Future以最新发出的值进行解析。

Widget build(BuildContext context, WidgetRef ref) 
  Future<User> user = ref.watch(userProvider.future);

其他Provider可能提供不同的替代值。

欲了解更多信息,请查阅API参考资料,参考每个Provider的API文档。

通过select来控制精确的读范围

最后要提到的一个与读取Provider有关的功能是,能够减少Widget/Provider从ref.watch重建的次数,或者ref.listen执行函数的频率的功能。

这一点很重要,因为默认情况下,监听一个Provider会监听整个对象的状态。但有时,一个Widget/Provider可能只关心一些属性的变化,而不是整个对象。

例如,一个Provider可能暴露了一个User对象。

abstract class User 
  String get name;
  int get age;

但一个Widget可能只使用用户名。

Widget build(BuildContext context, WidgetRef ref) 
  User user = ref.watch(userProvider);
  return Text(user.name);

如果我们简单地使用ref.watch,当用户的年龄发生变化时,这将重建widget。

解决方案是使用select来明确地告诉Riverpod我们只想监听用户的名字属性。

更新后的代码将是这样。

Widget build(BuildContext context, WidgetRef ref) 
  String name = ref.watch(userProvider.select((user) => user.name));
  return Text(name);

通过使用select,我们能够指定一个函数来返回我们关心的属性。

每当用户改变时,Riverpod将调用这个函数并比较之前和新的结果。如果它们是不同的(例如当名字改变时),Riverpod将重建Widget。然而,如果它们是相等的(例如当年龄改变时),Riverpod将不会重建Widget。

这个场景也可以使用select和ref.listen。

ref.listen<String>(
      userProvider.select((user) => user.name),
          (String? previousName, String newName) 
         print('The user name changed $newName');
      
  );

这样做也将只在名称改变时调用listener。

另外,你不一定要返回对象的一个属性。任何覆盖==的值都可以使用。例如,你可以这样做。

final label = ref.watch(userProvider.select((user) => 'Mr $user.name'));

读取状态,是一个非常重要的部分,什么时候用什么样的方式来读,都会有不同的效果。

ProviderObserver

ProviderObserver可以监听一个ProviderContainer的变化。

要使用它,你可以扩展ProviderObserver类并覆盖你想使用的方法。ProviderObserver有三个方法。

  • didAddProvider:在每次初始化一个Provider时被调用

  • didDisposeProvider:在每次销毁Provider的时候被调用

  • didUpdateProvider:每次在Provider更新时都会被调用

ProviderObserver的一个简单用例是通过覆盖didUpdateProvider方法来记录Provider的变化。

// A Counter example implemented with riverpod with Logger

class Logger extends ProviderObserver 
  @override
  void didUpdateProvider(
    ProviderBase provider,
    Object? previousValue,
    Object? newValue,
    ProviderContainer container,
  ) 
    print('''

  "provider": "$provider.name ?? provider.runtimeType",
  "newValue": "$newValue"
''');
  


void main() 
  runApp(
    // Adding ProviderScope enables Riverpod for the entire project
    // Adding our Logger to the list of observers
    ProviderScope(observers: [Logger()], child: const MyApp()),
  );


class MyApp extends StatelessWidget 
  const MyApp(Key? key) : super(key: key);

  @override
  Widget build(BuildContext context) 
    return MaterialApp(home: Home());
  


final counterProvider = StateProvider((ref) => 0, name: 'counter');

class Home extends ConsumerWidget 
  @override
  Widget build(BuildContext context, WidgetRef ref) 
    final count = ref.watch(counterProvider);

    return Scaffold(
      appBar: AppBar(title: const Text('Counter example')),
      body: Center(
        child: Text('$count'),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: () => ref.read(counterProvider.notifier).state++,
        child: const Icon(Icons.add),
      ),
    );
  

现在,每当我们的Provider的值被更新时,logger将记录它。

I/flutter (16783): 
I/flutter (16783):   "provider": "counter",
I/flutter (16783):   "newValue": "1"
I/flutter (16783): 

对于诸如StateController(StateProvider.state的状态)和ChangeNotifier等可改变的状态,previousValue和newValue将是相同的。因为它们引用的是同一个StateController / ChangeNotifier。

这些是对Riverpod的最基本了解,但是却是很重要的部分,特别是如何对状态值进行读取,这是我们用好Riverpod的核心。

向大家推荐下我的网站 https://xuyisheng.top/  点击原文一键直达

专注 android-Kotlin-Flutter 欢迎大家访问

往期推荐

本文原创公众号:群英传,授权转载请联系微信(Tomcat_xu),授权后,请在原创发表24小时后转载。

< END >

作者:徐宜生

更文不易,点个“三连”支持一下👇

以上是关于重走Flutter状态管理之路—Riverpod入门篇的主要内容,如果未能解决你的问题,请参考以下文章

重走Flutter状态管理之路—Riverpod最终篇

重走Flutter状态管理之路—Riverpod最终篇

重走Flutter状态管理之路—Riverpod进阶篇

重走Flutter状态管理之路—Riverpod进阶篇

Flutter状态管理之Riverpod

Flutter状态管理之Riverpod 2.0