我仍然在思考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的选项呢?
8条答案
按热度按时间tvmytwxo1#
没关系,但为了快速解释:
Provider.of
是获取和侦听对象的唯一方法。Consumer
、Selector
以及所有 *ProxyProvider调用Provider.of
都可以正常工作。Provider.of
与Consumer
是个人喜好的问题,但两者都有一些争论供应商。属于
didChangeDependencies
用户
cmssoen22#
〈〉的供应商
应用提供程序,如果listen为真,则整个小部件将重建。
消费者〈〉
仅使用消费者特别允许的小部件将重建。
xqk2d5yq3#
对于您的问题:
1.这是区分
Provider.of<X>
和Consumer<X>
的正确方法吗?前者不更新UI,后者更新UI?Provider.of<X>
依赖于listen
的值来触发新的State.build
到窗口小部件以及State.didChangeDependencies
到StatefulWidget
。Consumer<X>
总是更新UI,因为它使用Provider.of<T>(context)
,其中listen
是true
。请参阅完整的源代码here。1.如果
listen
没有设置为false
,小工具会默认重建还是不重建?如果listen
设置为true
会怎样?默认值是
true
,意味着将触发一个新的State.build
到小部件和State.didChangeDependencies
的StatefulWidget
。static T of<T>(BuildContext context, {bool listen = true})
.1.当我们有
Consumer
时,为什么Provider.of
有重建UI的选项?几乎被雷米·鲁塞莱的answer所覆盖。
qvtsj1bj4#
使用它不应该有任何性能问题,而且,如果我们只想在屏幕上更改某个特定的小部件,我们应该使用消费者。这是我可以说的编码实践方面的最佳方法。
就像上面的例子一样,我们只需要更新Single Text小部件的值,以便在那里添加消费者,而不是其他小部件也可以访问的Provider。
**注意:**消费者或提供者更新小部件正在使用的示例的唯一引用,如果一些小部件没有使用,则它不会重新绘制。
c9x0cxw05#
小部件
Consumer
没有做任何花哨的工作。它只是在一个新的小部件中调用Provider.of
,并将其构建实现委托给[builder]。这只是Provider.of
的语法糖,但有趣的是,我认为Provider.of
更容易使用。查看本文了解更多间隙https://blog.codemagic.io/flutter-tutorial-provider/
v7pvogib6#
我们有三件事要搞清楚。
当您将Provider Package 在一个小部件周围时,它会设置一个对小部件树的引用和一个您要引用其更改的变量。
使用Provider.of(context),你可以访问你想要监控的变量,并对它进行修改。
Provider.of(context)在有和没有listen的情况下都提供了对上面声明的Provider对象的引用和一个可以访问它的小部件树,但是正如其他人所说,当listen不为false时,它会重新构建它所在的整个小部件树。
最后,您可以使用consumer来监视通过上述步骤发生的任何更改
使用者的作用类似于更细粒度的侦听器,可以应用于固定的小部件,以帮助避免不必要的重建。
mwecs4sa7#
这只是个人喜好,取决于您如何理解和使用provider。因此,我对provider的看法是,它只是一个提供ChangeNotifier对象的对象,ChangeNotifier对象在小部件树中具有代码和数据。
因此,我使用:
用户
当我想监听数据中的更改并根据这些更改更新/重建UI时。
供应商。属于
当我只想调用Code.,并将listen参数设置为false时。
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,仅重建选定的小部件
这意味着一个小部件正在重建,另一个小部件没有“移动”
我希望我能帮助你