容器组件和展示组件(翻译)

作者：Dan Abramov 原文链接：Presentational and Container Components

在用 React 写应用的时候，我发现了一种非常好用又简单的模式。如果你已经使用过 React，很可能你早就发现它了。这篇文章讲得很好，但是，我还是想补充几点。

当你尝试把组件分成两类后，你会发现它们更容易被重用和理解（reuse and reason）。我将他们分为容器组件和展示组件（Container and Presentational components）。我也听过其他说法，比如“胖的"和"瘦的"（Fat and Skinny），"智能的"和"单调的"（Smart and Dumb），"多状态变量"和"单纯的"（Stateful and Pure），"封装物"和"元件"（Screens and Components），等。这些概念并不完全一样，但核心思想都是一致的。

我所说的展示组件(My presentational components)：

• 只关心它们的样子（how things look）。
• 可能同时包含子级容器组件和展示组件，一般含 DOM 标签和自己的样式。
• 通常用this.props.children来包含其他组件
• 不依赖 app 其它组件，比如 flux 的 actions 和 stores
• 不会定义数据如何读取，如何改变
• 只通过this.props接受数据和回调函数
• 很少有自己的状态变量，即使有，也是 UI 的状态变量，比如toggleMenuOpen，InputFocus
• 一般是函数级组件，除非它们需要状态，lifecycle hooks，优化处理。
• 例子：Page，Sidebar，Story，UserInfo，List。

我所说的容器组件(My container components:)：

• 只关心它们的运作方式（ how things work）。
• 可能同时包含子级容器组件和展示组件，但大都不含 DOM 标签，而含他们自己所用的 wrapping div，从不用自己的样式。
• 为展示组件或其他组件提供数据和方法。
• 调用 Flux 的 actions，并且将其作为展示组件的回调函数。
• 维持许多状态变量，通常充当一个数据源。
• 通常由高阶组件生成，比如 Redux 里的 connect()，Relay 里的 createContainer()，Flux Utils 里的 Container.create()，而非手工写出。
• 例子：UserPage, FollowersSidebar, StoryContainer, FollowedUserList。

我把他们放在不同的文件夹中，以示区别。

这种方法的好处(Benefits of This Approach)

• 更好的分离关注，用这种方式写组件，你可以更好的理解 你的 app 和 你的 UI。
• 更易复用，同样的展示组件可以在不同的状态源、数据源中使用。也可以封装成容器组件，在未来重用它们。
• 展示组件是 app 的调色板。你可以把它们放到单独的页面，并让设计师来调整它们的样式和结构，而不用改变 app 的逻辑。单独的页面有静态性，你可以在上面进行 screenshot regression 测试。
• 这会强迫你去抽象出layout components，比如 Sidebar, Page, ContextMenu，强迫你去使用 this.props.children，而非在不同容器中不断复制markup and layout。

记住，React 的组件不一定要生成 DOM，它们只需要考虑如何设计 UI 之间的分界与组合关系。

好好利用一这点。

什么时候引入容器？(When to Introduce Containers?)

我建议你做 app 的时候优先使用展示组件。当你意识到，有一些中间组件传递了过多的 props，有一些组件并不使用它们继承的 props 而只是将这些 props 传递给他们的子级，而且每次子级组件需要更多数据时，你都需要重新调整或编写这些中间组件，那么，这时候你可以考虑引入容器组件了。这样做，你可以传递 props 和方法给末端的子级组件，而不必麻烦一些不相关的中间组件。

这是一个持续的重构过程，所以不要试图第一次就把它做好。你尝试着这种模式，慢慢地你会培养起一种直觉，知道何时引入容器，就像你知道何时提取函数一样。我的免费redux 教程也许会帮助到你。

其他二分法（Other Dichotomies）

容器组件和展示组件的分别并不被严格定义，理解这一点很重要。为了对比，我再列举一些相关（但是不同的）的二分法。

多状态变量和少状态变量（Stateful and Stateless）

有些组件用setState()，有些不用。容器组件通常多状态变量，而展示组件却不，这不是铁规律。展示组件也可以多状态变量，而容器组件也可以少状态变量。

类与函数（Classes and Functions）

自从 React0.14，组件可以被声明为类，也可以被声明为函数。定义函数方便，却少了类独有的特性。有些限制或许会在未来消失，但是它们至少是存在的。因为函数容易理解，所以我推荐使用函数，除非你需要那些，现在只有类才有的状态管理，lifecycle hooks，性能优化等特性。

纯的不纯的（Pure and Impure）

人们说一个组件纯，是指给予它一样props和state，它保证能输出一样的结果。

纯函数可以是类，可以是函数，可以多状态，可以无状态。

Another important aspect of pure components is that they don’t rely on deep mutations in props or state, so their rendering performance can be optimized by a shallow comparison in their shouldComponentUpdate() hook。

目前只有类可以定义shouldComponentUpdate()，或许将来有改变吧。

展示组件和容器组件都有上述的二分特性。

在我看来，展示组件倾向于少状态、纯的函数，容器组件倾向于多状态，纯的类。

当然啦，这只是个人观察，而非规则，我也见过完全相反的情况。

不要将展示组件和容器组件当作教条。有些时候，不必划出清晰的线条，也不用觉得划出区分会很困难。如果你分不清某个组件是展示组件还是容器组件，也许是为时尚早。别着急！（Don’t sweat it!）

Footnotes

在本文的早期版本中，我将它们称为 smart 组件和 dumb 组件，但这对 presentational components 来说太苛刻了，更重要的是，这并没有真正解释它们的目的的不同。我更喜欢新的专业术语，我希望你们也喜欢!

在本文的早期版本中，我声称 presentational components 应该只包含其他 presentational components。我认为情况不再是这样了。component是presentational component 还是 container 是其实现细节。你应该能够在不修改任何调用栈的情况下，用 container 替换 presentational component。因此，presentational component 和 container components 都可以包含其他 presentational or container components。

——完——