javascript - Redux - 组件不同的方法(智能/哑/容器/演示)

Question

所以，我知道没有一种“正确”的方法，但我想就每种方法的优缺点进行对话。

所以，读完 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(例如 dispach)，这可能是一个缺点。在方法 A 中，您可能需要在许多 Dumb 组件之间沿树传递 props。

编辑

一件奇怪的事情是在 Redux docs 中，在“传递 Store”部分，您可以找到“Provider”( react 上下文)后面对“magic”的引用。在上下文文档中明确指出:

Just as global variables are best avoided when writing clear code, you should avoid using context in most cases

和:

Before you build components with this API, consider if there are cleaner alternatives. We're fond of simply passing the items as an array in cases like this

所以，据我所知，这是某种不好的做法？ (选项B...)

Answer 1

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

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

编辑:

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

换句话说，不用担心:)