商店中真正属于多少状态？

Posted 2023-02-22

【中文标题】商店中真正属于多少状态？

【英文标题】：How much state does really belong in the stores?

【发布时间】：2016-08-22 09:26:03

【问题描述】：

我想知道，有多少状态真正属于存储而不属于组件？我在一些地方读到过，所有州都应该住在商店里。

这是否包括真正特定于组件的内容，例如输入值（在提交之前）、输入验证、模式是否打开、是否已单击某些内容等？

这里有哪些最佳做法？

【问题讨论】：

老实说，我不喜欢那种有通量的模式。我以前用过助焊剂，但我没有深入到商店状态。我所做的是使用通量来提供服务器/操作所需的数据，并让它给我数据。当商店有该数据时，我可以根据商店数据设置状态。然而琐碎的事情，如输入值、活动类的切换状态视图、打开或关闭模式……我让组件管理这些事情，而不必执行操作。它更有意义，是一个很好的模式

【参考方案1】：

显而易见的答案： 尽可能将组件的特定状态（输入值、模态打开/关闭、单击的内容、布局、格式）保持在组件状态中。 以及商店内的应用程序特定状态。其中包括但不限于您通过服务器来回发送的内容。

也就是说，这里有很多灰色区域：

过滤器是否应用于搜索列表组件状态？或应用状态（如果您保存过滤器以供将来访问同一页面）？ 访问的链接是处于全局根菜单根组件状态还是应用状态？ 如果您使用乐观更新，您可能需要在与服务器通信之前和之后将用户输入的内容保存在商店中。

我使用的一些经验法则：

如果状态与组件具有相同的生命周期，则状态属于组件（因此，如果状态在组件挂载之前不需要存在，并且在组件卸载后可以忘记） 如果在关闭和重新打开应用程序时需要记住状态，最好将其放在商店中（与服务器和/或本地存储进行交换的地方） 如有疑问，请仅从组件中的状态开始：它使状态更加本地化（针对组件）并使您的代码更易于管理。稍后，您可以随时将状态移动到商店。

【讨论】：

我认为您已经指出了这些很好的规则。我要补充一点，“在关闭和重新打开应用程序时需要记住”的状态也可以（并非在所有情况下）保留在 URL 中，有时甚至最好将其保留在那里而不是 localStorage。

好点。但是如果该数据在 url 中，那么严格来说数据不是状态，而是必须以某种方式作为道具传递给您的反应树。严格来说：应用程序不会记住数据，但必须将其保存在 url..

【参考方案2】：

将所有东西保存在助焊剂商店中可能对某些应用有益。

所以首先，您应该尝试确定您的应用是否是这样的。

如果您不确定某个状态是否属于通量存储，那么很可能它不属于。 You'll know when you need flux。当您对此类应用程序架构是否适合您有了一定程度的了解后，您可能也会知道最初问题的答案。

当然，最好有某种特定的指导，也许只是一个心理指导，告诉你何时将状态保持在组件内，何时不保持。

我会选择这些指南：

此状态是否纯粹与 UI 相关？那么您可能不需要将其保存在商店中。 此状态是否共享组件之外的任何其他地方？如果没有，那就不要把它放在商店里。组件内部没问题。 能否在 URL 中保留此状态？如果是这样，那就不要把它放在商店里；把它放在网址中！它可能是输入或当前打开的选项卡的搜索查询。

所有这些都可能有例外，但总的来说，我认为这与 Flux 应用程序的原始想法非常吻合。

---

附：另外我应该说，有很多谈话说您应该（可能）将所有 UI 保留在不可变的状态树中。这就是向很多人介绍 redux 的方式。我认为你应该明白，虽然这是一个很棒的概念，它允许你保存/重放任何用户交互，但它往往不必要，这不是 Flux 的主要思想。而且 redux 本身是一个很棒的通量工具，它不会强迫您将所有 UI 状态保留在商店中。

【参考方案3】：

特定于组件的视图状态属于该组件。涉及许多组件的应用状态属于商店。

【参考方案4】：

这是有争议的。 例如，redux 提出了一种模式，其中所有状态都属于 store。我个人认为在许多情况下这是不切实际的。当我有任何理由存储商店中按钮的状态时，这是非常罕见的。 但有时它可能是有利的。当您的整个应用程序是无状态的时，测试肯定会更容易。