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