在 Redux 中,全局状态应该替换组件状态吗?

In Redux, should global state replace component state?

我的问题是,我应该继续使用有状态的 React 组件还是应该将该状态移动到 Redux 存储中?

我建议阅读此媒体 post:Presentational and Container Components。它概述了将组件状态用于 UI 状态但非 UI 状态是全局(redux)的想法。它还提出了一种模式,即如何通过让容器组件负责管理对全局状态的访问以及容器将状态作为道具传递给的简单视图组件来实现这一点。

所以我认为答案有点复杂,因为存在不同类型的状态。

我强烈推荐这个深入介绍 Redux 并提供大量解释以快速积累知识的免费视频系列:Getting Started with Redux

深入研究 Redux 并将其用于项目学习后,我发现自己正在使用它来存储 UI 状态。特定用例是长滚动 div。当使用后退按钮时,我希望 div 的滚动位置相同。将点击连接到调度以更新当前 div.scrollTop 的状态然后在 componentMount(按下后退按钮,组件重新安装)上只需将 div.scrollTop 设置为来自州的位置。

所以我认为在 Redux 中使用 UI 状态也是非常有用的。推理起来更容易,做起来也更简单。我可以看到以这种方式构建非常强大的 UIs,不会出现单页应用程序中常见的典型 UI 问题。

您的问题没有唯一正确答案。

你有不同类型的状态。您有模型的状态(就 MVC 而言)和 UI(视图)状态。在经典 MVC 中,您的模型不应依赖于 UI。所以,这里我们有一个问题:是否可以在全局 redux 存储中保存 UI 状态(输入、复选框状态)。

在这种情况下,最通用的规则是使用常识 :)。您可以根据需要选择任何一种方法,如果它更适合您的情况就可以了。

但是,让我们看几个例子。

适用于一切的全球 redux 商店

我知道在全局 redux 存储中保存整个 UI 状态的应用程序。我的意思是任何字段中的每次击键都会触发事件并更新全局存储。

优点:

  1. 当整个状态都在一个地方时,很容易跟踪状态变化。
  2. 您可以序列化整个状态以进行调试。它可以自动保存错误状态。或者 QA 工程师可以使用特殊的键盘快捷键转储 UI 状态并发送给开发人员。开发人员可以获取此序列化状态并将整个 UI 恢复为 QA 机器上的状态。

缺点

  1. 每次击键时重新渲染整个应用程序。
  2. 许多中间状态(在全局存储中)仅在用户输入某些数据时才需要。
  3. 将状态传递给您的组件。您将为此使用 "Container" 组件,但问题是您的 "Container" 组件应该只是顶级组件,还是应该将叶转储组件包装在容器中。两种变体都是可以接受的,但在大多数情况下,最好将状态移动到更高的位置(虽然这是有意义的)。阅读 "Smart vs Dumb" 个组件或 "Containers vs Presentational components"
  4. 您应该在一个全局存储中管理不同类型的状态(来自不同来源)。

UI 组件中的状态。

例如,您有一个表格。您的表单会自行管理您输入的状态。所以你只需将其呈现为 <Form onSubmit={ (fields) => saveFields(fields) }>

优点

  1. 中间表单状态是表单私有的。你可以认为这种状态根本不存在,对你来说无所谓。
  2. 私有状态的形状更容易改变。
  3. 组件更连贯。它们更加独立,就像大型应用程序中的简单迷你应用程序一样。

缺点

  1. 其他组件无法访问此状态。
  2. 没有单一的存储状态的地方。
  3. 状态管理的不同方法。
  4. 增加了存在多个真实来源的情况的可能性。

其他资源:

一些有用的一般想法:

  1. 在您的组件中处理尽可能少的状态,但不要少于所需的状态。无状态组件更易于使用。但请记住,状态将被移动到某个地方,因此您在任何情况下都需要处理它(它可以是存储或展示包装组件等)。
  2. 让你的组件尽可能独立。你可以用私有状态制作好的独立组件,也可以让它们成为无状态的。
  3. 将组件拆分为表示组件(上下文无关)和容器组件(上下文相关)。
  4. 尽可能高地移动状态。更喜欢在上层组件中保存状态。它不仅可以是容器组件。你可以创建展示组件来包装你的无状态组件只是为了管理状态(它们将与 redux 无关)