作用域模型的目的/在内置状态管理工程时提供包

Question

初来乍到，请原谅我的问题。

我在玩弄使用状态小部件管理整个应用程序的状态(变量/对象)的需要--这有点麻烦，但我得到了这个方法。

我看到有一些包提供了类似的功能(scoped_model和provide) --它们给混合带来了什么?它们解决了什么问题？在开始一种特定的方法之前，我想我是在问经验丰富的颤栗开发人员正在使用什么以及为什么？

谢谢

Answer 1

它主要是关于应用程序的可伸缩性和性能。对于小型应用程序来说，使用StatefulWidget是可以的，但是想象一下，如果您有一个深度为30的小部件树，而只有两个叶小部件需要知道一些counter值，并且它们都位于小部件树的两端。使用StatefulWidget方法，您必须将值放在树的顶部，并将其传递到整个树下，这样两个小部件就可以得到它。然后，过一段时间，您还需要树的一个完全无关的分支中的另一个小部件来获得counter --现在您需要修改整个分支来传递值。然后，稍后，您决定将原来的一个叶子移到另一个地方--再一次，您必须修改整个代码库以适应这种情况。

通过使用InheritedWidget，provider和scoped_model都可以使用，您可以将counter注入到树的顶部，并让需要它的小部件使用Consumer或scoped_model等效工具从context中提取值。这还将解决另一个问题:既然中间部件都不了解counter，那么当值发生变化时，它们就不再需要重新构建了。现在，您可以随意移动您的小部件并添加/删除对counter的依赖关系，而不是像这样处理不相关的小部件。

您甚至可以更进一步使用blocs。我记得我读过一篇比较所有方法的文章，发现bloc可以通过消除某些构建来进一步提高应用程序的性能，尽管一开始理解bloc模式中发生了什么可能有点让人望而生畏。

Answer 2

只使用StatefulWidget并不坏。您不必使用提供者/作用域模型。

默认情况下，StatefulWidgets非常强大并具有可伸缩性。

他们的缺点是：

• 他们是非常冗长的
• 很难在有状态小部件之间重用有状态逻辑(尽管有变体，比如flutter_hooks)
• 重构可能是痛苦的

这些都是InheritedWidgets解决的问题，提供者/作用域模型也是如此。

但正如你所看到的，这些主要是生活质量的问题。如果您可以支持它们，那么只使用StatefulWidget是可以的。