reactjs - 什么是渲染 Prop ，它与高阶组件有何不同？

Question

看来render props到目前为止还没有得到足够的关注，但是，它被著名的 React 库广泛使用，例如 react-router 4、reactmotion 等。并且 React 网站也有一个专门的部分那么，这种模式出现的原因是什么，与众所周知的 HOC(高阶组件)模式相比如何？

Answer 1

为我的研究留下答案，非常欢迎不同的答案和讨论!

HOC 借用了 High Order Function 的概念:

a higher-order function (also functional, functional form or functor) is a function that does at least one of the following:

• takes one or more functions as arguments (i.e., procedural parameters),
• returns a function as its result.[disputed – discuss]

<小时/>

HOC

A higher-order component (HOC) is an advanced technique in React for reusing component logic.

源自此Gist .

这个模式是关于STATIC组合的。核心/可重用逻辑封装在 HOC 中，而将移动部分留给组件。

使用withRouter以 react 路由器为例:

withRouter will pass updated match, location, and history props to the wrapped component whenever it renders.

// This gets around shouldComponentUpdate

withRouter(connect(...)(MyComponent))

现在你得到了一个增强的 MyComponent，它具有由路由器 HOC 传递的 { History, match, location, ...connectProps, ...ownProps } 的属性。

常见的方法是

compose(
  connect( ... ),
  enhance( ... ),
  withRouter( ... ),
  lifecycle( ... ),
  somethingElse( ... )
)(MyComponent);  

最重要的是，您可以使用 compose utility 无限地组合这些 HOC。获得组件的最终增强版本，并且您的组件将获得有关从 HOC 返回的新组件注入(inject)的 redux store、react router 等的知识。

该方法的缺点是:

1. 组件的行为是在运行时之前定义的，因此失去了 React 渲染生命周期的能力，比如说你不能做这样的事情:

   compose(
     this.state.shouldConnect && connect( ... ),
     this.state.shouldEnhance && enhance( ... ),
     this.state.shouldWithRouter && withRouter( ... ),
     ...
   )(MyComponent); 
   

   因为 state/props 在代码运行之前不可用。

2. 间接和命名冲突。

using a HOC with ES6 classes poses many of the same problems that mixins did with createClass, just re-arranged a bit.

HOCs introduce a lot of ceremony due to the fact that they wrap components and create new ones instead of being mixed in to existing components.

<小时/>

渲染 Prop

A render prop is a function prop that a component uses to know what to render.

首先由 react-motion 采用，早见于 Dan's Gist第一次提交 redux 前几周。

此模式是关于动态组合的。核心/可重用逻辑保留在组件中，而移动部分作为回调属性传递。

您可以通过渲染 Prop 创建 HOC。

仍以withRouter为例:

const withRouter = Component => {
  const C = props => {
    const { wrappedComponentRef, ...remainingProps } = props;
    return (
      <Route
        render={routeComponentProps => (
          <Component
            {...remainingProps}
            {...routeComponentProps}
            ref={wrappedComponentRef}
          />
        )}
      />
    );
  };
  ...
  return hoistStatics(C, Component);
}; 

但事实并非如此。

<Connect render={connectPropsMergedWithState => {
  <Enhance render={enhancePropsMergedWithState => {
    <WithRouter render={routerPropsMergedWithState => {
      <Lifecycle render={lifecyclePropsMergedWithState => {
        <SomethingElse render={somethingElsePropsMergedWithState => {
          ...
        }/>
        ...
      }/>
      ...
    }/>
    ...
  }/>
  ...
}/>

虽然看起来不太好，但收获还是很多的。

1. 它具有更好的显式性，因为我们可以看到作为参数传递给渲染 Prop 的具体内容。
2. 因为 1，它可以让我们避免潜在的 Prop 碰撞。
3. 它是动态的，我们可以传递任何我们喜欢的内容(包括 state/props)来渲染 props。

众所周知的缺点是 performance optimization is tricky ，因为要接收的 props 被推迟到运行时。进行任何过早的优化可能不是一个好主意，但这可能完全是另一个话题。

_{如果你同意 react 路由器从 3 到 4 的方向移动，渲染 Prop 可能是你的障碍。}

引用文献:

1. https://cdb.reacttraining.com/use-a-render-prop-50de598f11ce
2. https://reactrocket.com/post/turn-your-hocs-into-render-prop-components