《容器组件和展示组件》作者:Dan Abramov
作者:互联网
作者:Dan Abramov
原文链接:
https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0
容器组件和展示组件
容器组件和展示组件名词都来自于redux中文文档。
我在用react写程序时,发现了一种简单好用的模式。如果你也熟悉react,或许它早就被你发现了。有一篇文章讲得很好,但是,我想补充几点。
如果你将组件分成两类,你会发现它们容易更被重用和理解。这两类我称之为容器组件和展示组件。我也听过其他说法,比如"臃肿的"和"苗条的","智能的"和"单调的","多状态变量"和"单纯的","封装物"和"元件"等等。概念不完全一致,却有一样的中心思想。
我所说的展示组件:
- 只关心它们的样子。
- 可能同时包含子级容器组件和展示组件,一般含DOM标签和自定的样式。
- 通常用<code>this.props.children</code>来包含其他组件
- 不依赖app其它组件,比如flux的actions和stores
- 不会定义数据如何读取,如何改变
- 只通过<code>this.props</code>接受数据和回调函数
- 很少有自己的状态变量,即使有,也是UI的状态变量,比如<code>toggleMenuOpen</code>,<code>InputFocus</code>
- 一般是函数级组件,除非它们需要状态,lifecycle hooks,优化处理。
lifecycle hook这个词语很形象,但我不知道怎么翻译得贴切-_-!大概指那些监控组件生命周期里一些关键时刻的函数,比如,我需要在这组件初始化的时候调用某函数,那么我实现一个<code>onInit()</code>接口。react中的componentWillMount之类的函数也许也是lifecycle hook?
- 例子有Page,Sidebar,Story,UserInfo,List。
我所说的容器组件
- 只关心它们的运作方式。
- 可能同时包含子级容器组件和展示组件,但大都不含DOM标签,而含他们自己所用的wrapping div,从不用自己的样式。
- 为展示组件或其他组件提供数据和方法。
- 调用Flux的actions,并且将其作为展示组件的回调函数。
- 维持许多状态变量,通常充当一个数据源。
- 通常由高阶组件生成,比如Redux里的connect(),Relay里的createContainer(),Flux Utils里的Container.create(),而非手工写出(译者:可能在meteor中数据是例外吧)
- 例子有UserPage, FollowersSidebar, StoryContainer, FollowedUserList。
我把他们放在不同的文件夹中,以示区别。
这种方法的好处
- 分离关注,你可以更好的理解app和UI。
- 更易复用,同样的展示组件可以在不同的状态源、数据源中使用。也可以封装成容器组件,在未来重用它们。
- 展示组件是app的调色板。你可以把它们放到单独的页面,并让设计师来调整它们的样式和结构,而不用改变app的逻辑。单独的页面有静态性,你可以在上面进行screenshot regression测试。
- 这种方法会强迫你去解析布局相关的组件,比如Sidebar, Page, ContextMenu,强迫你去使用this.props.children,而非在不同容器中不断复制jsx那块地方。
记住,react的组件不一定要生成DOM,它们只需要考虑如何设计UI之间的分界与组合关系。利用好这一点。
什么时候引入容器?
我的建议是,你最好先做展示组件。当你意识到,有一些中间组件传递了过多的props,有一些组件并不使用它们继承的props而只是将这些props传递给他们的子级,而且每次子级组件需要更多数据时,你都需要重新调整或编写这些中间组件,那么,这时候你可以考虑引入容器组件了。这样做,你可以传递props和方法给末端的子级组件,而不必麻烦一些不相关的中间组件。
这是一个边写边改的重构,所以不必一步到位。你尝试着这种模式,慢慢地会培养起一种对何时引入容器的直觉,就像你知道何时该增加函数一样。我的redux教程也许会帮助你哦
其他二分法
容器组件和展示组件的分别并不被严格定义,理解这一点很重要。为了对比,我再列举一些相关(但是不同的)的二分法。
多状态变量和少状态变量
有些组件用<code>setState()</code>,有些不用。容器组件通常多状态变量,而展示组件却不,这不是铁规律。展示组件也可以多状态变量,而容器组件也可以少状态变量。
类与函数
自从React0.14,组件可以被声明为类,也可以被声明为函数。定义函数方便,却少了类独有的特性。有些限制或许会在未来消失,但是它们至少是存在的。因为函数容易理解,所以我推荐使用函数,除非你需要那些,现在只有类才有的状态管理,lifecycle hooks,性能优化等特性。
纯的不纯的
人们说一个组件纯,是指给予它一样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。目前只有类可以定义<code>shouldComponentUpdate()</code>,或许将来有改变吧。
展示组件和容器组件都有上述的二分特性。在我看来,展示组件倾向于少状态、纯的函数,容器组件倾向于多状态,纯的类。当然啦,这只是个人观察,而非规则,我也见过完全相反的情况。
不要将展示组件和容器组件当作教条。有些时候,不必划出清晰的线条,也不用觉得划出区分会很困难。如果你分不清某个组件是展示组件还是容器组件,也许是为时尚早。要知道,心急吃不了热豆腐。
标签:容器,函数,展示,Dan,Abramov,状态变量,props,组件 来源: https://www.cnblogs.com/cczlovexw/p/13595818.html