React入门(四)Render Prop 与 HOC
这篇博客继续来看高级指引。
这次的主题是Render Prop以及高阶组件。
Render Prop
什么是Render Prop
术语 “render prop” 是指一种在 React 组件之间使用一个值为函数的 prop 共享代码的简单技术
具有 render prop 的组件接受一个返回 React 元素的函数,并在组件内部通过调用此函数来实现自己的渲染逻辑。
1 | <DataProvider render={data => ( |
注意这段描述,看起来这个render prop和普通的prop并没有什么区别,react并不会对一个叫做render的prop做什么特殊处理,你需要自己在组件内部去调用
使用 Render Props 来解决横切关注点(Cross-Cutting Concerns)
组件是 React 代码复用的主要单元,但如何将一个组件封装的状态或行为共享给其他需要相同状态的组件并不总是显而易见。
例如,以下组件跟踪 Web 应用程序中的鼠标位置:
1 | class MouseTracker extends React.Component { |
当光标在屏幕上移动时,组件在 <p>
中显示其(x,y)坐标。
现在的问题是:我们如何在另一个组件中复用这个行为?换个说法,若另一个组件需要知道鼠标位置,我们能否封装这一行为,以便轻松地与其他组件共享它??
由于组件是 React 中最基础的代码复用单元,现在尝试重构一部分代码使其能够在 <Mouse>
组件中封装我们需要共享的行为。
1 | // <Mouse> 组件封装了我们需要的行为... |
现在 <Mouse>
组件封装了所有关于监听 mousemove
事件和存储鼠标 (x, y) 位置的行为,但其仍不是真正的可复用。
举个例子,假设我们有一个 <Cat>
组件,它可以呈现一张在屏幕上追逐鼠标的猫的图片。我们或许会使用 <Cat mouse={ { x, y }}
prop 来告诉组件鼠标的坐标以让它知道图片应该在屏幕哪个位置。
首先, 你或许会像这样,尝试在 <Mouse>
内部的渲染方法渲染 <Cat>
组件::
1 | class Cat extends React.Component { |
这种方法适用于我们的特定用例,但我们还没有达到以可复用的方式真正封装行为的目标。现在,每当我们想要鼠标位置用于不同的用例时,我们必须创建一个新的组件(本质上是另一个 <MouseWithCat>
),它专门为该用例呈现一些东西.
这段话的意思是,其实Cat这个组件还是写死在了
<MouseWithCat>
组件中,以后你可能还需要<MouseWithDog>
,<MouseWithMonkey>
这也是 render prop 的来历:相比于直接将 <Cat>
写死在 <Mouse>
组件中,并且有效地更改渲染的结果,我们可以为 <Mouse>
提供一个函数 prop 来动态的确定要渲染什么 —— 一个 render prop。
1 | class Cat extends React.Component { |
现在,我们提供了一个 render
方法 让 <Mouse>
能够动态决定什么需要渲染,而不是克隆 <Mouse>
组件然后硬编码来解决特定的用例。
更具体地说,render prop 是一个用于告知组件需要渲染什么内容的函数 prop。
这项技术使我们共享行为非常容易。要获得这个行为,只要渲染一个带有 render
prop 的 <Mouse>
组件就能够告诉它当前鼠标坐标 (x, y) 要渲染什么。
关于 render prop 一个有趣的事情是你可以使用带有 render prop 的常规组件来实现大多数高阶组件 (HOC)。 例如,如果你更喜欢使用 withMouse
HOC而不是 <Mouse>
组件,你可以使用带有 render prop 的常规 <Mouse>
轻松创建一个:
1 | // 如果你出于某种原因真的想要 HOC,那么你可以轻松实现 |
因此,你可以将任一模式与 render prop 一起使用。
使用 Props 而非 render
重要的是要记住,render prop 是因为模式才被称为 render prop ,你不一定要用名为 render
的 prop 来使用这种模式。事实上, 任何被用于告知组件需要渲染什么内容的函数 prop 在技术上都可以被称为 “render prop”.
尽管之前的例子使用了 render
,我们也可以简单地使用 children
prop!
1 | <Mouse children={mouse => ( |
记住,children
prop 并不真正需要添加到 JSX 元素的 “attributes” 列表中。相反,你可以直接放置到元素的内部!
1 | <Mouse> |
你将在 react-motion 的 API 中看到此技术。
由于这一技术的特殊性,当你在设计一个类似的 API 时,你或许会要直接地在你的 propTypes 里声明 children 的类型应为一个函数。
1 | Mouse.propTypes = { |
注意事项
将 Render Props 与 React.PureComponent 一起使用时要小心
如果你在 render 方法里创建函数,那么使用 render prop 会抵消使用 React.PureComponent
带来的优势。因为浅比较 props 的时候总会得到 false,并且在这种情况下每一个 render
对于 render prop 将会生成一个新的值。
React.PureComponent
与React.Component
很相似。两者的区别在于React.Component
并未实现shouldComponentUpdate()
,而React.PureComponent
中以浅层对比 prop 和 state 的方式来实现了该函数,也就是说React.PureComponent
更新之前会调用自己实现的shouldComponentUpdate方法,该方法会浅层比较state和prop,如果相同,就不更新。
例如,继续我们之前使用的 <Mouse>
组件,如果 Mouse
继承自 React.PureComponent
而不是 React.Component
,我们的例子看起来就像这样:
1 | class Mouse extends React.PureComponent { |
在这样例子中,每次 <MouseTracker>
渲染,它会生成一个新的函数作为 <Mouse render>
的 prop,因而在同时也抵消了继承自 React.PureComponent
的 <Mouse>
组件的效果!
每次重新渲染
<MouseTracker>
都会重新生成一个新的函数赋值给render,所以虽然函数功能是相同的,但是已经是另一个函数了,浅比较的时候,比较的是内存内置,所以一定是false,但其实要做的事没有变化。
为了绕过这一问题,有时你可以定义一个 prop 作为实例方法,类似这样:
1 | class MouseTracker extends React.Component { |
如果你无法静态定义 prop(例如,因为你需要关闭组件的 props 和/或 state),则 <Mouse>
应该继承自 React.Component
。
高阶组件(HOC)
高阶组件(HOC)是 React 中用于复用组件逻辑的一种高级技巧。HOC 自身不是 React API 的一部分,它是一种基于 React 的组合特性而形成的设计模式。
具体而言,高阶组件是参数为组件,返回值为新组件的函数。
1 | const EnhancedComponent = higherOrderComponent(WrappedComponent); |
组件是将 props 转换为 UI,而高阶组件是将组件转换为另一个组件。
使用 HOC 解决横切关注点问题
组件是 React 中代码复用的基本单元。但你会发现某些模式并不适合传统组件。
例如,假设有一个 CommentList
组件,它订阅外部数据源,用以渲染评论列表:
1 | class CommentList extends React.Component { |
稍后,编写了一个用于订阅单个博客帖子的组件,该帖子遵循类似的模式:
1 | class BlogPost extends React.Component { |
CommentList
和 BlogPost
不同 - 它们在 DataSource
上调用不同的方法,且渲染不同的结果。但它们的大部分实现都是一样的:
- 在挂载时,向
DataSource
添加一个更改侦听器。 - 在侦听器内部,当数据源发生变化时,调用
setState
。 - 在卸载时,删除侦听器。
你可以想象,在一个大型应用程序中,这种订阅 DataSource
和调用 setState
的模式将一次又一次地发生。我们需要一个抽象,允许我们在一个地方定义这个逻辑,并在许多组件之间共享它。这正是高阶组件擅长的地方。
对于订阅了 DataSource
的组件,比如 CommentList
和 BlogPost
,我们可以编写一个创建组件函数。该函数将接受一个子组件作为它的其中一个参数,该子组件将订阅数据作为 prop。让我们调用函数 withSubscription
:
1 | const CommentListWithSubscription = withSubscription( |
第一个参数是被包装组件。第二个参数通过 DataSource
和当前的 props 返回我们需要的数据。
当渲染 CommentListWithSubscription
和 BlogPostWithSubscription
时, CommentList
和 BlogPost
将传递一个 data
prop,其中包含从 DataSource
检索到的最新数据:
1 | // 此函数接收一个组件... |
请注意,HOC 不会修改传入的组件,也不会使用继承来复制其行为。相反,HOC 通过将组件包装在容器组件中来组成新组件。HOC 是纯函数,没有副作用。
被包装组件接收来自容器组件的所有 prop,同时也接收一个新的用于 render 的 data
prop。HOC 不需要关心数据的使用方式或原因,而被包装组件也不需要关心数据是怎么来的。
因为 withSubscription
是一个普通函数,你可以根据需要对参数进行增添或者删除。例如,您可能希望使 data
prop 的名称可配置,以进一步将 HOC 与包装组件隔离开来。或者你可以接受一个配置 shouldComponentUpdate
的参数,或者一个配置数据源的参数。因为 HOC 可以控制组件的定义方式,这一切都变得有可能。
与组件一样,withSubscription
和包装组件之间的契约完全基于之间传递的 props。这种依赖方式使得替换 HOC 变得容易,只要它们为包装的组件提供相同的 prop 即可。例如你需要改用其他库来获取数据的时候,这一点就很有用。
不要改变原始组件。使用组合。
不要试图在 HOC 中修改组件原型(或以其他方式改变它)。
1 | function logProps(InputComponent) { |
这样做会产生一些不良后果。其一是输入组件再也无法像 HOC 增强之前那样使用了。更严重的是,如果你再用另一个同样会修改 componentDidUpdate
的 HOC 增强它,那么前面的 HOC 就会失效!同时,这个 HOC 也无法应用于没有生命周期的函数组件。
修改传入组件的 HOC 是一种糟糕的抽象方式。调用者必须知道他们是如何实现的,以避免与其他 HOC 发生冲突。
HOC 不应该修改传入组件,而应该使用组合的方式,通过将组件包装在容器组件中实现功能:
1 | function logProps(WrappedComponent) { |
该 HOC 与上文中修改传入组件的 HOC 功能相同,同时避免了出现冲突的情况。它同样适用于 class 组件和函数组件。而且因为它是一个纯函数,它可以与其他 HOC 组合,甚至可以与其自身组合。
约定:将不相关的 props 传递给被包裹的组件
HOC 为组件添加特性。自身不应该大幅改变约定。HOC 返回的组件与原组件应保持类似的接口。
HOC 应该透传与自身无关的 props。大多数 HOC 都应该包含一个类似于下面的 render 方法:
1 | render() { |
这种约定保证了 HOC 的灵活性以及可复用性。
约定:最大化可组合性
并不是所有的 HOC 都一样。有时候它仅接受一个参数,也就是被包裹的组件:
1 | const NavbarWithRouter = withRouter(Navbar); |
HOC 通常可以接收多个参数。比如在 Relay 中,HOC 额外接收了一个配置对象用于指定组件的数据依赖:
1 | const CommentWithRelay = Relay.createContainer(Comment, config); |
最常见的 HOC 签名如下:
1 | // React Redux 的 `connect` 函数 |
*刚刚发生了什么?!*如果你把它分开,就会更容易看出发生了什么。
1 | // connect 是一个函数,它的返回值为另外一个函数。 |
换句话说,connect
是一个返回高阶组件的高阶函数!
这种形式可能看起来令人困惑或不必要,但它有一个有用的属性。 像 connect
函数返回的单参数 HOC 具有签名 Component => Component
。 输出类型与输入类型相同的函数很容易组合在一起。
1 | // 而不是这样... |
(同样的属性也允许 connect
和其他 HOC 承担装饰器的角色,装饰器是一个实验性的 JavaScript 提案。)
许多第三方库都提供了 compose
工具函数,包括 lodash (比如 lodash.flowRight
), Redux 和 Ramda。
约定:包装显示名称以便轻松调试
HOC 创建的容器组件会与任何其他组件一样,会显示在 React Developer Tools 中。为了方便调试,请选择一个显示名称,以表明它是 HOC 的产物。
最常见的方式是用 HOC 包住被包装组件的显示名称。比如高阶组件名为 withSubscription
,并且被包装组件的显示名称为 CommentList
,显示名称应该为 WithSubscription(CommentList)
:
1 | function withSubscription(WrappedComponent) { |
注意事项
高阶组件有一些需要注意的地方,对于 React 新手来说可能并不容易发现。
不要在 render 方法中使用 HOC
React 的 diff 算法(称为协调)使用组件标识来确定它是应该更新现有子树还是将其丢弃并挂载新子树。 如果从 render
返回的组件与前一个渲染中的组件相同(===
),则 React 通过将子树与新子树进行区分来递归更新子树。 如果它们不相等,则完全卸载前一个子树。
通常,你不需要考虑这点。但对 HOC 来说这一点很重要,因为这代表着你不应在组件的 render 方法中对一个组件应用 HOC:
1 | render() { |
这不仅仅是性能问题 - 重新挂载组件会导致该组件及其所有子组件的状态丢失。
如果在组件之外创建 HOC,这样一来组件只会创建一次。因此,每次 render 时都会是同一个组件。一般来说,这跟你的预期表现是一致的。
在极少数情况下,你需要动态调用 HOC。你可以在组件的生命周期方法或其构造函数中进行调用。
务必复制静态方法
有时在 React 组件上定义静态方法很有用。例如,Relay 容器暴露了一个静态方法 getFragment
以方便组合 GraphQL 片段。
但是,当你将 HOC 应用于组件时,原始组件将使用容器组件进行包装。这意味着新组件没有原始组件的任何静态方法。
1 | // 定义静态函数 |
为了解决这个问题,你可以在返回之前把这些方法拷贝到容器组件上:
1 | function enhance(WrappedComponent) { |
但要这样做,你需要知道哪些方法应该被拷贝。你可以使用 hoist-non-react-statics 自动拷贝所有非 React 静态方法:
1 | import hoistNonReactStatic from 'hoist-non-react-statics'; |
除了导出组件,另一个可行的方案是再额外导出这个静态方法。
1 | // 使用这种方式代替... |
Refs 不会被传递
虽然高阶组件的约定是将所有 props 传递给被包装组件,但这对于 refs 并不适用。那是因为 ref
实际上并不是一个 prop - 就像 key
一样,它是由 React 专门处理的。如果将 ref 添加到 HOC 的返回组件中,则 ref 引用指向容器组件,而不是被包装组件。
这个问题的解决方案是通过使用 React.forwardRef
API
在高阶组件中转发 refs
这个技巧对高阶组件(也被称为 HOC)特别有用。让我们从一个输出组件 props 到控制台的 HOC 示例开始:
1 | function logProps(WrappedComponent) { class LogProps extends React.Component { |
“logProps” HOC 透传(pass through)所有 props
到其包裹的组件,所以渲染结果将是相同的。例如:我们可以使用该 HOC 记录所有传递到 “fancy button” 组件的 props:
1 | class FancyButton extends React.Component { |
下面的示例有一点需要注意:refs 将不会透传下去。这是因为 ref
不是 prop 属性。就像 key
一样,其被 React 进行了特殊处理。如果你对 HOC 添加 ref,该 ref 将引用最外层的容器组件,而不是被包裹的组件。
这意味着用于我们 FancyButton
组件的 refs 实际上将被挂载到 LogProps
组件:
1 | import FancyButton from './FancyButton'; |
幸运的是,我们可以使用 React.forwardRef
API 明确地将 refs 转发到内部的 FancyButton
组件。React.forwardRef
接受一个渲染函数,其接收 props
和 ref
参数并返回一个 React 节点。例如:
1 | function logProps(Component) { |
logProps
组件是React.forwardRef
返回的Ref转发组件,传入它的ref属性会一层层传递到一个它被传入到ref属性的组件中。
这样说比较绕,就说是,我们创建一个refA,赋值给logProps
,但因为它是转发组件,所以这个时候并不会给refA赋值,而是直接透传到forwardedRef
属性,再透传到Component
组件的ref
属性,如果这个组件不是转发组件,那这个时候才会对这个refA真正赋值。
总结和比较
无论是Render Prop还是HOC,都是为了解决横切关注点问题。
那么首先,我们要理解下什么是横切关注点
部分关注点「横切」程序代码中的数个模块,即在多个模块中都有出现,它们即被称作「横切关注点(Cross-cutting concerns, Horizontal concerns)」。
这样说好像还是特别抽象?那我们举个例子。
日志功能就是横切关注点的一个典型案例。日志功能往往横跨系统中的每个业务模块,即“横切”所有需要日志功能的类和方法体。所以我们说日志成为了横切整个系统对象结构的关注点 —— 也就叫做横切关注点啦。
说的实际一点,就是说这两个东西都是为了解决重复代码问题的。
对于重复的代码部分,我们把它抽取成一个组件,并给不同的部分预留好位置:
- 对于HOC来讲,它是利用函数的入参(至少有一个是公共组件)去通过函数逻辑构造新的组件
- 对于Render Prop来讲,它是在公共组件中预留一个地方去调用未来传入的Render Prop。
对于不同的部分:
- 对于HOC来讲,我们可以通过HOC来利用一个函数去利用重复的部分去去生成一个新的组件。
- 对于Render Prop来讲,可以通过Render Prop直接传入生成我们要渲染的组件的函数,然后在公共部分中调用这个函数去渲染不同的组件部分。
这二者都不是什么React的特殊语法糖,也就是这两个并不是React的源码会做特殊处理的,都只是React基本语法的使用方式,Render Prop就是个普通的prop,只要你传入的prop是个返回组件的函数(设为A),并且在该组件(设为B)的某个地方调用并渲染了这个组件A,那这个prop就是Render Prop。
而HOC就是个函数而已,只不过这个函数的入参和返回都是组件,你可以利用入参的组件去创建一个新的组件,但是请不要去改变入参的组件。
区别的话,HOC更加灵活,函数中可以有很多逻辑,Render Prop就只能传入一个Render函数给Prop。