Redux - 组件不同的方法（智能/哑/容器/演示）答案

【问题标题】：Redux - Component different approaches (Smart / Dumb / Container / Presentation)Redux - 组件不同的方法（智能/哑/容器/演示）
【发布时间】：2016-04-28 08:44:59
【问题描述】：

所以，我知道没有一种“正确”的方法可以解决这个问题，但我想就每种方法的优缺点进行一次对话。

所以，在阅读了 Dan Abramov 的 post 和 comment 并阅读了 this 教程之后，我想知道这两种不同方法的优缺点：

方法 A：

├── Smart / Container component
│   ├── Dumb / presentation component
│   │   ├── Dumb / presentation component
│   ├── Dumb / presentation component

方法 B：

├── Smart / Container component
│   ├── Dumb / presentation component
│   │   ├── Smart / Container component
│   ├── Dumb / presentation component

这里的主要区别在于您如何管理您的状态。在选项 B 中，最深的组件应该知道 redux（例如调度），这可能是一个缺点。在方法 A 中，您可能需要在许多 Dumb 组件之间向下传递道具。

编辑

奇怪的是，在Redux docs 的“传递存储”部分，您可以在“提供者”（反应上下文）后面找到对“magic”的引用。在上下文文档中明确表示：

正如在编写清晰的代码时最好避免使用全局变量一样，您在大多数情况下应该避免使用上下文

和：

在使用此 API 构建组件之前，请考虑是否有更清洁的替代品。我们喜欢简单地将项目作为这种情况下的数组

所以，据我所知，这是一种不好的做法？（选项 B...）

【问题讨论】：

标签： javascript reactjs redux

【解决方案1】：

这变成了可读性和重新渲染性能的问题。有时通过几个级别显式传递道具可能更具可读性。其他时候，如果您开始一个新的连接并在那里提取您需要的数据，可能会更容易理解。另外，请注意connect() 做了很多工作以确保您自己的组件仅在真正需要时重新渲染，因此您实际上可以在连接组件时获得一些潜在的性能改进.相比之下，“哑”组件通常不实现shouldComponentUpdate，这意味着它们每次都会重新渲染。

正如您所说，没有唯一的正确答案 - 只要对您自己的应用程序结构有意义，请使用 connect()。

编辑：

为了回答您关于 React Context 文档的问题，React-Redux 的 <Provider> 组件专门封装了它恰好使用 Context 的事实。这样，如果将来对 Context API 或行为有任何更改，您自己的应用不必担心它，因为它可以通过更新 Provider 来处理。

换句话说，别担心:)

【讨论】：