什么应该是与 redux 存储连接的容器组件，什么不应该是？答案

【问题标题】：What should be a container component connected with a redux store and what should not be?什么应该是与 redux 存储连接的容器组件，什么不应该是？
【发布时间】：2017-07-09 23:30:58
【问题描述】：

对于哪些组件应该是与 redux 存储连接的容器组件，哪些组件不应该是，是否有任何指导方针？

大概，我应该问什么样的状态需要成为应用程序级的状态，什么样的状态需要成为组件级的状态。

我个人对此还没有任何指导方针，但我认为这些状态是应用程序级状态的候选者。

由多个组件共享的状态。
嗯...就是这样，不是吗？

那么，回到我最初的问题，任何具有由多个组件共享状态的组件都是与 redux 存储连接的容器组件的良好候选者？

【问题讨论】：

嗯，任何需要访问全局状态的组件都应该被连接起来。不依赖全局状态的不需要连接。
谢谢！所以，一般来说，全局状态是被多个组件或其他东西访问的东西，对吧？如果某个状态只被一个组件访问，该状态不应该是全局状态吗？
是的，多个组件可以访问相同的全局状态。如果状态是内部的并且特定于一个组件，例如输入值，那么它不应该是全局状态
我不同意安德鲁的观点。首先，我不喜欢“全局状态”的概念，我知道我们在这里谈论的是 Redux 商店中的状态。您可以拥有多个商店，并且没有理由不为页面的每个功能部分（顶级组件或其他）创建一个。其次，在我看来，所有状态都应该去 redux 商店。我很难想象输入是组件的内部状态，并且不会影响应用程序的其余部分。在 Redux 中拥有所有状态，例如，您可以重新加载页面或让用户导航并且应用程序按预期运行。
@MikeSzyndel，虽然您可以拥有多家商店，但我很少（如果有的话）推荐它。主要原因是当使用react-redux 时，Provider 只能提供一个 store，这使得从两个或多个 store 中访问一点数据变得异常困难。

标签： reactjs redux react-redux

【解决方案1】：

理想情况下，您的组件应该只根据道具呈现 UI。所以从一个功能组件开始。如果你需要生命周期钩子，你当然需要一个类，但尽量不要使用状态。

要填充组件的 props，您需要一个容器。这是一个黑盒组件，它将数据和编组到组件的 props 中。它可以从 redux、您的 API、graphql 甚至使用来自 recompose 的 HOC 获取数据。

【讨论】：