在Flutter中何时使用提供者< X>与消费< X>者

31moq8wy  于 2023-01-31  发布在  Flutter
关注(0)|答案(8)|浏览(141)

我仍然在思考flutter中的状态管理技术,对于何时以及为什么使用Provider.of<X>Consumer<X>有点困惑。(我认为)从documentation中可以看出,当我们想要访问数据时,在这两者之间进行选择时,您将使用Provider.of。但是你不需要改变UI,所以下面的代码(取自文档)可以访问数据,并在新事件发生时更新UI:

return HumongousWidget(
  // ...
  child: AnotherMonstrousWidget(// <- This widget will rebuild on new data events
    // ...
    child: Consumer<CartModel>(
      builder: (context, cart, child) {
        return Text('Total price: ${cart.totalPrice}');
      },
    ),
  ),
);

然而,如果我们只需要数据,而不想使用UI重建,我们将使用Provider.of<X>,并将listen参数设置为false,如下所示:

Provider.of<CartModel>(context, listen: false).add(item); \\Widget won't rebuild

但是,listen不是必需的,因此也将运行以下代码:

Provider.of<CartModel>(context).add(item); \\listener optional

这就引出了几个问题:
1.这是区分Provider.of<X>Consumer<X>的正确方法吗?前者不更新UI,后者更新UI?
1.如果listen没有设置为false,小工具会默认重建还是不重建?如果listen设置为true会怎样?
1.当我们有Consumer时,为什么Provider.of有重建UI的选项呢?

tvmytwxo

tvmytwxo1#

没关系,但为了快速解释:
Provider.of是获取和侦听对象的唯一方法。ConsumerSelector以及所有 *ProxyProvider调用Provider.of都可以正常工作。
Provider.ofConsumer是个人喜好的问题,但两者都有一些争论

供应商。属于

  • 可以在所有小部件生命周期中调用,包括单击处理程序和didChangeDependencies
  • 不会增加缩进

用户

  • 允许更细粒度的微件重建
  • 解决大多数BuildContext误用问题
cmssoen2

cmssoen22#

〈〉的供应商

应用提供程序,如果listen为真,则整个小部件将重建。

消费者〈〉

仅使用消费者特别允许的小部件将重建。

xqk2d5yq

xqk2d5yq3#

对于您的问题:
1.这是区分Provider.of<X>Consumer<X>的正确方法吗?前者不更新UI,后者更新UI?
Provider.of<X>依赖于listen的值来触发新的State.build到窗口小部件以及State.didChangeDependenciesStatefulWidget
Consumer<X>总是更新UI,因为它使用Provider.of<T>(context),其中listentrue。请参阅完整的源代码here
1.如果listen没有设置为false,小工具会默认重建还是不重建?如果listen设置为true会怎样?
默认值是true,意味着将触发一个新的State.build到小部件和State.didChangeDependenciesStatefulWidget
static T of<T>(BuildContext context, {bool listen = true}).
1.当我们有Consumer时,为什么Provider.of有重建UI的选项?
几乎被雷米·鲁塞莱的answer所覆盖。

qvtsj1bj

qvtsj1bj4#

使用它不应该有任何性能问题,而且,如果我们只想在屏幕上更改某个特定的小部件,我们应该使用消费者。这是我可以说的编码实践方面的最佳方法。

return Container(
    // ...
    child: Consumer<PersonModel>(
      builder: (context, person, child) {
        return Text('Name: ${person.name}');
      },
    ),
  );

就像上面的例子一样,我们只需要更新Single Text小部件的值,以便在那里添加消费者,而不是其他小部件也可以访问的Provider。

**注意:**消费者或提供者更新小部件正在使用的示例的唯一引用,如果一些小部件没有使用,则它不会重新绘制。

c9x0cxw0

c9x0cxw05#

小部件Consumer没有做任何花哨的工作。它只是在一个新的小部件中调用Provider.of,并将其构建实现委托给[builder]。这只是Provider.of的语法糖,但有趣的是,我认为Provider.of更容易使用。
查看本文了解更多间隙https://blog.codemagic.io/flutter-tutorial-provider/

v7pvogib

v7pvogib6#

我们有三件事要搞清楚。
当您将Provider Package 在一个小部件周围时,它会设置一个对小部件树的引用和一个您要引用其更改的变量。
使用Provider.of(context),你可以访问你想要监控的变量,并对它进行修改。
Provider.of(context)在有和没有listen的情况下都提供了对上面声明的Provider对象的引用和一个可以访问它的小部件树,但是正如其他人所说,当listen不为false时,它会重新构建它所在的整个小部件树。
最后,您可以使用consumer来监视通过上述步骤发生的任何更改
使用者的作用类似于更细粒度的侦听器,可以应用于固定的小部件,以帮助避免不必要的重建。

mwecs4sa

mwecs4sa7#

这只是个人喜好,取决于您如何理解和使用provider。因此,我对provider的看法是,它只是一个提供ChangeNotifier对象的对象,ChangeNotifier对象在小部件树中具有代码数据
因此,我使用:

用户

当我想监听数据中的更改并根据这些更改更新/重建UI时。

供应商。属于

当我只想调用Code.,并将listen参数设置为false时。

4smxwvx5

4smxwvx58#

如果你的问题是知道有什么不同,这里有一个轨道

消费者

重新加载仅限消费者的子小部件

提供程序(listen true)

从树中找到的最后一个构建上下文重新加载
实际上在一个简单的例子中
exemple1 provider.of
在示例1中,当我单击我容器时,它的大小增加(gesturedetector在h变量处发送新值,h变量位于provider中名为method的函数中)
在@override下面的第一个Buildcontext处使用“provider.of”flutter重新构建
这意味着树木的整体重建
exemple2 consumer
在示例2中,当我点击我容器时,它的大小增加(gesturedetector在h变量处发送新值,h变量在provider中的函数名为method中),但是对于consumer,仅重建选定的小部件
这意味着一个小部件正在重建,另一个小部件没有“移动”
我希望我能帮助你

相关问题