我是react redux的新手，它有一个“容器组件”的概念，和react中的“容器组件”是一样的，关注的是事情是如何工作的。在 redux 中，容器组件用于从 store 中访问 state，以避免将 props 向下传递给太多嵌套的子组件。
以下是我的问题：
(1) 容器组件是否负责组织业务逻辑？
(2) 有很多帖子，比如Where do I put my business logic in a React-Redux application?，都提到了把逻辑放到reducor/action creator/thunk 等等，但是没说容器组件，是不是漏掉了什么重要的东西？
【问题讨论】：
标签： reactjs react-redux
1) 不，业务逻辑应该保存在中间件、reducers 和 selectors 中。
2) 容器组件实际上是由 connect HOC 创建的每个组件（与存储连接的所有内容）。如第 1 点所述，它不是业务逻辑的地方。
更多关于 Redux 架构的答案
当使用 Redux 时，container->presentation 组件的约定并不是真正需要的。您应该专注于将组件与商店直接连接起来。因此，您应该专注于直接交付所需的数据，而不是选择哪些组件是连接的，是容器，哪些不是，是呈现的。
首选是避免从父组件传递 props 并在没有其他方法的情况下使用它。避免传递 props 的一个例子是 List -> Element components 关系。在使用容器组件的方法中，存储将连接到List(container)，List 会将所有数据传递给每个Element(presentation) 组件。在没有container->presentation 的方法中，您将只向Element 组件发送id，而Element 组件将连接到商店，以获取强制属性。所以这里发送props减少到最低限度，而且由于两个组件都连接到store，你在container->presentation上是无法区分的。
关于非 redux 架构的附加通知
如果应用没有像redux这样的状态管理工具，那么使用container->presentation组件的方式是非常合理的。这是因为业务逻辑只保留在程序的一部分中，我的意思是容器组件，而表示组件可以是纯的和无状态的。感谢container->presentation 分割应用程序在状态修改和状态纯度之间有明确的分离。
【讨论】：
一般做法
container 组件指定presentational 组件应呈现的数据。容器组件还指定行为。如果展示组件有任何交互性——比如一个按钮——它会调用container 组件给它的prop-function。 container 组件是向Redux store 发送操作的组件。容器组件还可以访问 Redux 存储中的数据
presentational 组件是只呈现 HTML 的组件。该组件的唯一功能是表示性标记。在 Redux 驱动的应用中，展示组件不与 Redux 存储交互。
这是@DanAbramov 在this关于容器组件的文章中提到的一些要点
关心事物的运作方式。
内部可能同时包含展示组件和容器组件**，但通常没有任何自己的 DOM 标记，除了一些 包装 div，并且永远不会有任何样式。
向展示或其他容器组件提供数据和行为。
调用 Flux 操作并将这些操作作为回调提供给演示组件。
通常是有状态的，因为它们往往用作数据源。
通常使用高阶组件生成，例如 React Redux 的 connect()、Relay 的 createContainer() 或 Container.create() 来自 Flux Utils，而不是手写。
【讨论】：