应用程序设计：多少 Redux 状态？
Application design: how much Redux state?
我目前正在使用 React 构建一个小型应用程序（6 个前端容器式组件，15 个后端数据库表）。
我正在尝试导入 Redux，但我很难设计我的应用程序状态。看来我需要将基础广泛的状态（例如用户会话）存储到 Redux 中，但大多数其他状态我将从后端提取并且不一定 需要 它总是 100% 最新。
基于那里所有的 "redux-todo" 样式示例，人们似乎会在他们的 Redux 存储中存储 所有东西（因为状态相对较小，我想）。
但是，就我而言，我想知道 Redux 是否应该只是一个超轻量级存储，仅用于需要在整个应用程序中保留的内容，Ember 风格 'service'.
我的想法是否正确？或者我应该在 Redux 中存储更多状态？
我们的想法是存储您的应用运行所需的任何状态。你的 React 组件除了拥有数据后如何处理数据之外，对数据一无所知。 React/Redux "way" 是 只有 他们从您的 Redux 商店获取它的方式。
因此，如果您在应用加载时获取项目列表，那么它会进入您的商店。然后你的应用程序在整个会话中都有它。如果有人离开然后回来，或者重新加载页面，它会再次获取，并再次在 Redux 中存储一个新副本。一旦它存在，您可能不会创建任何操作来修改它，并且您可能不需要很快再次获取它，但这是它应该存在的地方，以便您的组件可以从中获取东西。
如果你不把它存储在 Redux 中，你会把它放在哪里？您的组件将如何访问它？
我一直在努力解决这个确切的问题。这确实需要一些时间来适应，但正如另一个答案所说，如果 你正在使用 Redux，惯用的方法是将基本上所有的东西都存储在 Redux 商店中。一个例外（事实证明这种情况相当罕见）是 UI-only 数据，例如设置 class 等的可见性切换或下拉信息。也就是说，数据是短暂的，对其所在组件之外的任何事物都没有影响。即便如此，您会发现一些 UI-only 项使用操作和缩减器更容易管理，因为它们通常最终会触及其他项。
编辑补充：正如下面的评论所述，官方 Redux 文档在这个问题上没有表态。这就是为什么这么多人都在为这些问题而苦苦挣扎的原因之一——您可以自由地构建 React/Redux 应用程序。我的建议应该被理解为基于尝试不同方法的经验的建议。以下是我看到的将状态放入商店的三个主要原因：
通常情况下，我放入 state 的东西最终会在其他地方被需要，并且通过 props 将它放到那里需要比我刚开始将数据放入 Redux store 时更多的工作.
此外，随着应用的增长和变得越来越复杂，重构您的应用以将组件拆分为更多模块化的可重用部分是很常见的。如果您的状态数据在一个组件的两个位置使用，那么您将无法轻松将该组件拆分成更小的部分。
最后，可读性。很高兴能够浏览您的 mapStateToProps 调用并准确了解每个组件接收或使用的道具。
问题在于，当物品的动作和影响很简单时，Redux 和将所有东西都放在商店中会让人觉得有很多不必要的复杂性。如果是这样，我建议您至少首先考虑放弃 Redux。重构将需要大量工作，但它将帮助您欣赏 Redux 的闪光点。另一方面，您的应用程序实际上可能并不真正需要它。
回到你原来的问题，是的，在我看来，你应该在 Redux 商店中放更多。除了一些非常狭窄的例外，一切都在那里。来自后端的数据尤其应该作为第一步进入商店，然后再映射到使用它的组件中的道具。
我目前正在使用 React 构建一个小型应用程序（6 个前端容器式组件，15 个后端数据库表）。
我正在尝试导入 Redux，但我很难设计我的应用程序状态。看来我需要将基础广泛的状态（例如用户会话）存储到 Redux 中，但大多数其他状态我将从后端提取并且不一定 需要 它总是 100% 最新。
基于那里所有的 "redux-todo" 样式示例，人们似乎会在他们的 Redux 存储中存储 所有东西（因为状态相对较小，我想）。
但是，就我而言，我想知道 Redux 是否应该只是一个超轻量级存储，仅用于需要在整个应用程序中保留的内容，Ember 风格 'service'.
我的想法是否正确？或者我应该在 Redux 中存储更多状态？
我们的想法是存储您的应用运行所需的任何状态。你的 React 组件除了拥有数据后如何处理数据之外，对数据一无所知。 React/Redux "way" 是 只有 他们从您的 Redux 商店获取它的方式。
因此，如果您在应用加载时获取项目列表，那么它会进入您的商店。然后你的应用程序在整个会话中都有它。如果有人离开然后回来，或者重新加载页面，它会再次获取，并再次在 Redux 中存储一个新副本。一旦它存在，您可能不会创建任何操作来修改它，并且您可能不需要很快再次获取它，但这是它应该存在的地方，以便您的组件可以从中获取东西。
如果你不把它存储在 Redux 中，你会把它放在哪里？您的组件将如何访问它？
我一直在努力解决这个确切的问题。这确实需要一些时间来适应，但正如另一个答案所说，如果 你正在使用 Redux，惯用的方法是将基本上所有的东西都存储在 Redux 商店中。一个例外（事实证明这种情况相当罕见）是 UI-only 数据，例如设置 class 等的可见性切换或下拉信息。也就是说，数据是短暂的，对其所在组件之外的任何事物都没有影响。即便如此，您会发现一些 UI-only 项使用操作和缩减器更容易管理，因为它们通常最终会触及其他项。
编辑补充：正如下面的评论所述，官方 Redux 文档在这个问题上没有表态。这就是为什么这么多人都在为这些问题而苦苦挣扎的原因之一——您可以自由地构建 React/Redux 应用程序。我的建议应该被理解为基于尝试不同方法的经验的建议。以下是我看到的将状态放入商店的三个主要原因：
通常情况下，我放入 state 的东西最终会在其他地方被需要，并且通过 props 将它放到那里需要比我刚开始将数据放入 Redux store 时更多的工作.
此外，随着应用的增长和变得越来越复杂，重构您的应用以将组件拆分为更多模块化的可重用部分是很常见的。如果您的状态数据在一个组件的两个位置使用，那么您将无法轻松将该组件拆分成更小的部分。
最后，可读性。很高兴能够浏览您的 mapStateToProps 调用并准确了解每个组件接收或使用的道具。
问题在于，当物品的动作和影响很简单时，Redux 和将所有东西都放在商店中会让人觉得有很多不必要的复杂性。如果是这样，我建议您至少首先考虑放弃 Redux。重构将需要大量工作，但它将帮助您欣赏 Redux 的闪光点。另一方面，您的应用程序实际上可能并不真正需要它。
回到你原来的问题，是的，在我看来，你应该在 Redux 商店中放更多。除了一些非常狭窄的例外，一切都在那里。来自后端的数据尤其应该作为第一步进入商店，然后再映射到使用它的组件中的道具。