Skip to content

Latest commit

 

History

History
192 lines (145 loc) · 7.29 KB

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

File metadata and controls

192 lines (145 loc) · 7.29 KB
Raw

本期精读的文章是：我不再使用高阶组件。

懒得看文章？没关系，稍后会附上文章内容概述，同时，更希望能通过阅读这一期的精读，穿插着深入阅读原文。

1 引言

logo

React 与 Vue 相比，组件为一等公民是最大特色之一。

由于组件可以作为一个 props 向下传递，因此 React 具备了高度抽象化的能力，Vue 虽然更易上手，但因 template 特点，没有所谓 props 传递组件这种概念，但这样导致在抽象能力上落后于 React。可能这是 JSX 与 template 之间的差异吧，也是变量与字符串之间的差异，变量同名但含义不同，所以可抽象，而模版靠规则和名称确定含义。

当然 Vue 也有 babel-plugin-transform-vue-jsx 这里不做展开。

强大的组件能力，导致了实践的多样性，高阶组件就是其一。高阶组件的特点是，JSX 描述的子元素，会注入到父级组件的 this.props.children 中，因此可以无入侵增强组件能力，常用比如权限、跳转、埋点、异常、描述、注入等等。

高阶组件也带来了使用中的困扰，作者这篇文章阐述了高阶组件存在的问题，值得我们了解。

2 内容概要

高阶组件由于可嵌套，如果有一环高阶组件没有将内部 wrappedComponent 暴露出来，会导致后续叠加的高阶组件都无法获取、注入到原始组件。

另外就算所有高阶组件都遵循了规范，组件也难以察觉被注入的数据是由哪些高阶组件提供的，而且高阶组件之间互相隔离，导致可能存在覆盖 props 的危险情况，这些问题高阶组件都束手无策。这体现出约定比约束更加效率，但约定的可维护性低于约束。

因此更好的解决思路可能是叫做 render props render callback function as child 这些名字的方法，组件定义如下：

// Contrived example for simplicity
import React, { Component } from 'react';
import PropTypes from 'prop-types';
class Caffeinate extends Component {
  propTypes = { children: PropTypes.func.isRequired };
  state = { coffee: "Americano" };
  render() {
    return this.props.children(this.state.coffee);
  }
}

直接将函数作为子元素，可以认为是一个匿名组件：

render(
  <Caffeinate>
    {(beverage) => <div>Drinking an {beverage}.</div>}
  </Caffeinate>,
  document.querySelector("#root")
);
//=> Drinking an Americano.

这种用法在 React Motion React Router 里都有采用。

3 精读

本质是将组件作为参数

我们看另一种写法：

import React, { Component } from 'react';
import PropTypes from 'prop-types';
class Caffeinate extends Component {
  propTypes = { children: PropTypes.func.isRequired };
  state = { coffee: "Americano" };
  render() {
    return this.props.child(this.state.coffee);
  }
}

// usage
render(
  <Caffeinate child={
    (beverage) => <div>Drinking an {beverage}.</div>
  } />,
  document.querySelector("#root")
);

render props 本质上与上面这种很常规的写法没什么不同，差异在于利用了 props.children，将参数写在 JSX 的子元素中。相比高阶组件用法，这样嵌套下来，看得清楚数据流动，解决了高阶组件反复嵌套导致的各类问题：

render(
  <RenderProps1>
    {(title) => <div>
      <h1>{title}</h1>
      <RenderProps2>
        {(name) =>
          <RenderProps3>
            {(age) => {
              <div>{name}, {age}</div>
            }}
          </RenderProps3>
        }
      </RenderProps2>
    </div>}
  </RenderProps1>
)

与高阶组件对比

与 HOC 相比，render props 开放性提升明显，原本 HOC 所做的功能抽象可通过 render Props 获取，而 render 也可以访问到父级的一切：

compare with high order component

Render Props 存在的问题

  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} />
  )
}

简约即美

与其绕那么大一圈，还不如回归到最普通的 props 传参，这说明 renderProps 作为其中一种特例，可能观赏价值大于其实用价值。其控制放权的思想也是为了解决组件 dom 结构定制化的问题。

但是这也涉及到限度的问题，以下就是两种极端：

render() {
  return this.props.children
}
render() {
  return (
    <div>
      <Header />
      <Sidebar>
        <Toolbox>
          <ul>
            <li>..</li>
            <li>{this.props.secondLi}</li>
            <li>..</li>
          </ul>
        </Toolbox>
      </Sidebar>
      <Footer />
    </div>
  )
}

可以看出，写出这两种代码的目的，都为了从外部控制组件结构，以至于最大限度提高组件的复用能力。其实很难在不了解组件自身含义时，妄下一个通用的结论，说 “你只要这么写，就能保证任何组件都非常通用”。

比如 Card 组件可以将 title extra 设定为 ReactNode，加上 children，其实用性已经足够了：

render() {
  return (
    <Container>
      <Title>
        {this.props.title}
        {this.props.extra}
      </Title>
      <Body>
        {this.props.children}
      </Body>
    </Container>
  )
}

再比如 Modal 也只需要对 Header Footer children 支持 ReactNode 就可以保证足够的通用性。

在业务场景，由于代码修改频率较高，复用性重要程度就没那么高。

4. 总结

作者也提到了，高阶组件在某些场景很有用，所以不会完全拒绝使用。

在不为组件做注入的场景下是高阶组件的好场景，利用其生命周期实现权限、埋点，在层级少的时候用作依赖注入也非常方便。

其实程序员在思考这些最佳实践时，与艺术家的思考方式很类似，况且这些最佳实践在不同场景、不同团队，不同项目下都有所侧重，所以不用逮着所谓最完美的实践把代码全部重构，以后也全部用一种风格写代码。就像陶瓷艺术家也不会说：我再也不做彩瓷了，因为白瓷这种颜色非常简约，在我心中是完美的，因此我宁愿一辈子只做白瓷。

这一期也想表达一个积极含义，精读周刊是不会 give up 的！

如果你想参与讨论，请点击这里，每周都有新的主题，每周五发布。