使用 Flutter Provider 就意味着没有 StatefulWidgets？答案

【问题标题】：Using Flutter Provider means no StatefulWidgets?使用 Flutter Provider 就意味着没有 StatefulWidgets？
【发布时间】：2020-04-14 03:43:20
【问题描述】：

我正准备使用 Flutter 和 Provider 编写我的第一个重要应用程序。我已经阅读了 Provider 如何促进不可变小部件 (StatelessWidgets)。我的问题是，在使用 Provider 时使用 StatefulWidgets 是否总是是一种反模式？如果不是，哪些情况下在 Provider 应用中使用 StatefulWidgets 更好？

编辑

使用 Provider 已经几个月了，在每种情况下，我仍然偏爱它而不是 StatefulWidgets。我时不时地介绍一个 StatefulWidget，主要是为了尝试熟悉它们，然后几乎立即后悔并重构为 Provider。前几天我遇到了不刷新的小部件，因为它们是相同的类型，所以正在考虑引入键以便它们刷新。前几次尝试都失败了，所以我重构为 Provider 并且一切正常（不需要密钥）。

反模式在我的 OP 中不是合适的术语。我想我的问题是，有没有 StatefulWidgets 更干净或更容易/更好使用的例子？

【问题讨论】：

标签： flutter provider

【解决方案1】：

provider 不在乎你写的是无状态/有状态还是其他任何东西（钩子？）。

它消除了在许多情况下编写StatefulWidget 的需要，但它并没有声称您应该只使用StatelessWidget。

最后，决定是否需要StatefulWidget 是您的工作。例如，在编写动画时可能需要它。

【讨论】：

感谢@Rémi Rousselet。关于您对使用 StatefulWidget 进行动画的评论，是因为动画数据是特定于 UI 的吗？那么，最佳实践是将应用程序/业务数据存储在 Provider 对象中，而 UI 状态（独立于应用程序数据）更好地存储在 StatefulWidgets 中？那么，如果用户在输入后脉动 3 倍的文本字段中输入 50 美元进行转账，那么 50 美元存储在 Provider 类中，而脉动计数器最好存储在 StatefulWidget 中？

【解决方案2】：

添加到 Rémi 的答案和此实施的新内容：

为共享模型使用 Provider
在需要时使用小部件状态来管理特定于该问题的模型
想象一个用户对象在 auth 之后，之前为 null，通过应用程序共享，具有特定于编辑字段的状态的表单，如昵称或其他，更新本地状态并可能传播到产品的其余部分（当在后端完成更新？......谁知道）并且当不再需要该视图时该状态被处理，但用户引用仍然通过提供者引用。在提供者模型中管理所有状态变化是没有意义的——结果就是这样。

根据我在 React+Redux 以及在原生 Web 组件（与这两者的生命周期相似）以及 LitElement 周围传递对象的经验，在这里做一些假设。到目前为止，这些模式看起来很相似，如果不一样的话。

【讨论】：

【解决方案3】：

Provider.of<ProviderClass>(context, listen: false);

Provider 是 Flutter 拥有的一种状态管理机制，在底层，Provider 会跟踪小部件内部所做的更改。无论是无状态小部件还是有状态小部件，Provider 都无所谓，如果有任何变化，它将重新构建小部件。

listen: false 告诉提供者不要重建小部件，即使数据被修改。这意味着它只能在父小部件被 setState() 或 ProviderClass 类值修改时重新构建。

【讨论】：