精读《我不再使用高阶组件》

[ascoders]

本期精读文章是：https://medium.com/tandemly/im-breaking-up-with-higher-order-components-44b0df2db052

作者对 HOC 提出了不一样的观点，让我们一起看看吧。

[BlackGanglion]

我一直是 HOC 的忠实拥护者，在业务研发中，HOC 带来了很强的功能抽象能力，让我屡试不爽、着迷其中。不久前有人问我 HOC 有没有什么不好的地方，我回答地并不好，其实我的第一反应是没有什么不好。。。从那时我开始重新审视 HOC，我认为我看问题的角度可能出现了问题，对我一个开发 HOC 的而言，HOC 确实很出色，让我对于很多业务组件共有的功能进行了抽象统一。但对于使用和维护 HOC 而言呢？确实是痛苦的，HOC 很封闭，无法拿到 HOC 包裹组件的 ref，必须由 HOC 进行一次传递，HOC 包裹组件的 props 将变得不在可控，会新增哪些 props？props 是否会发生冲突？不得而知。JSX 中无法直接使用 HOC，多个 HOC compose 在一起，这样对于维护而言简直噩梦，理解成本也会变得很高。

回到精读文章中提到的 renderProps 模式，最近社区对于这种模式似乎十分推崇，与 HOC 相比，其开放性提升明显，原本 HOC 所做的功能抽象可通过 render Props 获取，而 render 也可以访问到父级的一切：

[ascoders]

从评论里看出，renderProps 还是存在一些瑕疵：

1. this.props.children 不该作为函数调用。
2. 渲染粒度变大，表格等需要性能优化的场景不适合。
3. renderProps 渲染的并不是 React 组件，无法为其单独使用 redux，mobx dob 等依赖收集粒度也放不下去。

renderProps 为了解耦，让控制权从上到下传递，而底层实现不需要了解上层实现，这是解决 JSX 修改组件模版问题的方法之一，作为优化点之一，可以考虑让传入的 props 自身作为一个组件：

const View = ({title}) => <div>{title}</div>

// ...
render() {
  return (
    <Component view={View} />
  )
}