我错了吗,或者如果我们只是想向下传递一个值Widget
,Provider
只是InheritedWidget
一个dispose
方法?
3 回答
是的。Provider 确实主要是基于 Inheritedwidgets 的特性。
如果你想自己做,那很好。但是您很快就会意识到,如果没有提供者,您将有数百条无用的重复行。
Provider 基本上采用了 InheritedWidgets 的逻辑,但将样板代码降到了最低限度。
Provider
不是必须的,但应该。
首先,它是由 Flutter Team 推广的,并且足够灵活,可以处理几乎所有的状态管理解决方案。
说因为InheritedWidget
有太多不同的用例并继承了一些优化可能你在其他任何地方都找不到,这可能是不公平的。dispose
Provider
如果您InheritedWidget
在大型应用程序中使用,build
方法总是重建整个构建方法。但是有了Provider
你的Consumer
小部件,它可以非常具体地控制特定的build
方法块,所以你有更高的效率。侦听器的复杂性也低于 InheritedWidgets'(O(N) vs O(N²))。
问题是因为 Flutter 最初是打算作为一个 UI 框架的,所以默认的状态管理解决方案也是面向 UI 的。
最后,由于您需要针对不同的项目使用不同的状态管理模式,因此一个包适用于所有的场景在 imo 中是非常宝贵的。
Flutter 文档对此有一个很好的部分,他们正在讨论应用程序中的状态管理(其中很大一部分是将值传递到树中)。
Flutter 有机制让小部件为它们的后代(换句话说,不仅仅是它们的孩子,还有它们下面的任何小部件)提供数据和服务。正如您对 Flutter 所期望的那样,Everything is a Widget™,这些机制只是特殊类型的小部件——InheritedWidget、InheritedNotifier、InheritedModel 等等。我们不会在这里介绍这些,因为它们对于我们正在尝试做的事情来说有点低级。
相反,我们将使用一个与低级小部件一起使用但易于使用的包。它被称为提供者。
因此,截至 2021 年底,似乎建议使用该provider
软件包,除非您需要较低级别的访问权限——在这种情况下,您可以使用Inherited*
小部件。例如,如果您编写了自己的版本,provider
那么您将需要较低级别的访问权限。
我上面引用的文档位于https://docs.flutter.dev/development/data-and-backend/state-mgmt/simple#accessing-the-state