React Hooks 深入不浅出 - 图1

这个标题可能不太好，但此文章确实不是一篇使用教程，而且也不会覆盖太多点，建议时间充裕的还是应该完整地看下 官网文档。

React Hooks 对于部分人来说可能还是陌生的，但还是阻止不了它成为了当前 React 社区里「最」热门的一个词汇。

React Hooks 深入不浅出 - 图2

一开始了解到这个还是 Dan Abramov 在十月底的时候发了一个推，是一篇文章 Making Sense of React Hooks，建议没看过的先看下。看完第一感受就是：React 本就应该是这样的啊！

看完这篇文章，希望你可以从整体上对 Hooks 有个认识，并对其设计哲学有一些理解，希望看的过程不要急，跟着我的思路走。

如果你想自己跟着文章一起练手，需要把 react 和 react-dom 更新到 16.7.0-alpha 及以上，如果配置了 ESLint，记得添加对应的 Plugin。

插曲

长期以来很多人会把 Stateless Component 和 Functional Component 混为一谈，我会试着跟他们解释这不是一回事（不是一个维度），但当时 Functional Component 里确实无法使用 state，我无论怎么解释都会显得很无力。难道这冥冥之中都预示着会有类似 React Hooks 的东西出现？

React Hooks 的本质

稍微复杂点的项目肯定是充斥着大量的 React 生命周期函数（注意，即使你使用了状态管理库也避免不了这个），每个生命周期里几乎都承担着某个业务逻辑的一部分，或者说某个业务逻辑是分散在各个生命周期里的。

React Hooks 深入不浅出 - 图3

而 Hooks 的出现本质是把这种面向生命周期编程变成了面向业务逻辑编程，你不用再去关心本不该关心的生命周期。

React Hooks 深入不浅出 - 图4

一个 Hooks 演变

我们先假想一个常见的需求，一个 Modal 里需要展示一些信息，这些信息需要通过 API 获取且跟 Modal 强业务相关，要求我们：

  • 因为业务简单，没有引入额外状态管理库

  • 因为业务强相关，并不想把数据跟组件分开放

  • API 数据会随机变动，因此需要每次打开 Modal 才获取最新数据

  • 为了后期优化，不可以有额外的组件创建和销毁

我们可能的实现如下：

代码完整演示地址

  1. class RandomUserModal extends React.Component {
  2.   constructor(props) {
  3.     super(props);
  4.     this.state = {
  5.       user: {},
  6.       loading: false,
  7.     };
  8.     this.fetchData = this.fetchData.bind(this);
  9.   }
  11.   componentDidMount() {
  12.     if (this.props.visible) {
  13.       this.fetchData();
  14.     }
  15.   }
  17.   componentDidUpdate(prevProps) {
  18.     if (!prevProps.visible && this.props.visible) {
  19.       this.fetchData();
  20.     }
  21.   }
  23.   fetchData() {
  24.     this.setState({ loading: true });
  25.     fetch('https://randomuser.me/api/')
  26.       .then(res => res.json())
  27.       .then(json => this.setState({
  28.         user: json.results[0],
  29.         loading: false,
  30.       }));
  31.   }
  33.   render() {
  34.     const user = this.state.user;
  35.     return (
  36.       <ReactModal
  37.         isOpen={this.props.visible}
  38.       >
  39.         <button onClick={this.props.handleCloseModal}>Close Modal</button>
  40.         {this.state.loading ?
  41.           <div>loading...</div>
  42.           :
  43.           <ul>
  44.             <li>Name: {`${(user.name || {}).first} ${(user.name || {}).last}`}</li>
  45.             <li>Gender: {user.gender}</li>
  46.             <li>Phone: {user.phone}</li>
  47.           </ul>
  48.         }
  49.       </ReactModal>
  50.     )
  51.   }
  52. }

我们抽象了一个包含业务逻辑的 RandomUserModal，该 Modal 的展示与否由父组件控制，因此会传入参数 visible 和 handleCloseModal（用于 Modal 关闭自己）。

为了实现在 Modal 打开的时候才进行数据获取，我们需要同时在 componentDidMount 和 componentDidUpdate 两个生命周期里实现数据获取的逻辑，而且 constructor 里的一些初始化操作也少不了。

其实我们的要求很简单：在合适的时候通过 API 获取新的信息，这就是我们抽象出来的一个业务逻辑，为了这个业务逻辑能在 React 里正确工作，我们需要将其按照 React 组件生命周期进行拆解。这种拆解除了代码冗余，还很难复用。

下面我们看看采用 Hooks 改造后会是什么样：

完整演示地址

  1. function RandomUserModal(props) {
  2.   const [user, setUser] = React.useState({});
  3.   const [loading, setLoading] = React.useState(false);
  5.   React.useEffect(() => {
  6.     if (!props.visible) return;
  7.     setLoading(true);
  8.     fetch('https://randomuser.me/api/').then(res => res.json()).then(json => {
  9.       setUser(json.results[0]);
  10.       setLoading(false);
  11.     });
  12.   }, [props.visible]);
  14.   return (
  15.     // View 部分几乎与上面相同
  16.   );
  17. }

很明显地可以看到我们把 Class 形式变成了 Function 形式，使用了两个 State Hook 进行数据管理（类比 constructor），之前 cDM 和 cDU 两个生命周期里干的事我们直接在一个 Effect Hook 里做了（如果有读取或修改 DOM 的需求可以看 这里）。做了这些，最大的优势是代码精简，业务逻辑变的紧凑，代码行数也从 50+ 行减少到 30+ 行。

Hooks 的强大之处还不仅仅是这个，最重要的是这些业务逻辑可以随意地的的抽离出去，跟普通的函数没什么区别（仅仅是看起来没区别），于是就变成了可以复用的自定义 Hook。具体可以看下面的进一步改造：

完整演示地址

  1. // 自定义 Hook
  2. function useFetchUser(visible) {
  3.   const [user, setUser] = React.useState({});
  4.   const [loading, setLoading] = React.useState(false);
  6.   React.useEffect(() => {
  7.     if (!visible) return;
  8.     setLoading(true);
  9.     fetch('https://randomuser.me/api/').then(res => res.json()).then(json => {
  10.       setUser(json.results[0]);
  11.       setLoading(false);
  12.     });
  13.   }, [visible]);
  14.   return { user, loading };
  15. }
  17. function RandomUserModal(props) {
  18.   const { user, loading } = useFetchUser(props.visible);
  20.   return (
  21.     // 与上面相同
  22.   );
  23. }

这里的 useFetchUser 为自定义 Hook，它的地位跟自带的 useState 等比也没什么区别，你可以在其它组件里使用，甚至在这个组件里使用两次，它们会天然地隔离开。

业务逻辑复用

这里说的业务逻辑复用主要是需要跨生命周期的业务逻辑。单单按照组件堆积的形式组织代码虽然也可以达到各种复用的目的，但是会导致组件非常复杂，数据流也会很乱。组件堆积适合 UI 布局，但是不适合逻辑组织。为了解决这些问题，在 React 发展过程中，产生了很多解决方案，我认知里常见的有以下几种：

Mixins

坏处远远大于带来的好处，因为现在已经不再支持，不多说，可以看看这篇文章：Mixins Considered Harmful。

Class Inheritance

官方 很不推荐此做法，实际上我也没真的看到有人这么做。

High-Order Components (HOC)

React 高阶组件 在封装业务组件上简直是屡试不爽，它的实现是把自己作为一个函数，接受一个组件，再返回一个组件，这样它可以统一处理掉一些业务逻辑并达到复用目的。

比较常见的一个就是 react-redux 里的 connect 函数：

React Hooks 深入不浅出 - 图5

（图片来自 这里）

但是它也被很多人吐槽嵌套问题：

React Hooks 深入不浅出 - 图6

（图片来自 这里）

Render Props

Render Props 其实很常见，比如 React Context API：

  1. class App extends React.Component {
  2.   render() {
  3.     return (
  4.       <ThemeProvider>
  5.         <ThemeContext.Consumer>
  6.           {val => <div>{val}</div>}
  7.         </ThemeContext.Consumer>
  8.       </ThemeProvider>
  9.     )
  10.   }
  11. }

它的实现思路很简单，把原来该放「组件」的地方，换成了回调，这样当前组件里就可以拿到子组件的状态并使用。

但是，同样这会产生 Wrapper Hell 问题：

React Hooks 深入不浅出 - 图7

（图片来自 这里）

Hooks

Hooks 本质上面说了，是把面向生命周期编程变成了面向业务逻辑编程，写法上带来的优化只是顺带的。

这里，做一个类比，await/async 本质是把 JS 里异步编程思维变成了同步思维，写法上表现出来的特点就是原来的 Callback Hell 被打平了。

总结对比：

  • await/async 把 Callback Hell 干掉了，异步编程思维变成了同步编程思维

  • Hooks 把 Wrapper Hell 干掉了，面向生命周期编程变成了面向业务逻辑编程

这里不得不客观地说，HOC 和 Render Props 还是有存在的必要，一方面是支持 React Class，另一方面，它们不光适用于纯逻辑封装，很多时候也适合逻辑 + 组件的封装场景，虽然此时使用 Hooks 也可以，但是会显得啰嗦点。另外，上面诟病的最大的问题 Wrapper Hell，我个人觉得使用 Fragment 也可以基本解决。

状态盒子

首先，React Hooks 的设计是反直觉的，为什么这样说呢？可以先试着问自己：为什么 Hooks 只能在其它 Hooks 的函数或者 React Function 组件里？

在我们的认知里，React 社区一直推崇函数式、纯函数等思想，引入 Hooks 概念后的 Functional Component 变的不再纯了，useXxx 与其说是一条执行语句，不如说是一个声明。声明这里放了一个「状态盒子」，盒子有输入和输出，剩下的内部实现就一无所知，重要的是，盒子是有记忆的，下次执行到此位置时，它有之前上下文信息。

类比「代码」和「程序」的区别，前者是死的，后者是活的。表达式 c = a + b 表示把 a 和 b 累加后的值赋值给 c，但是如果写成 c := a + b 就表示 c 的值由 a 和 b 相加得到。看起来表述差不多，但实际上，后者隐藏着一个时间的维度，它表示的是一种联系，而不单单是个运算。这在 RxJS 等库中被大量使用。

React Hooks 深入不浅出 - 图8

这种声明目前是通过很弱的 use 前缀标识的（但是设计上会简洁很多），为了不弄错每个盒子和状态的对应关系，书写的时候 Hooks 需要 use 开头且放在顶层作用域，即不可以包裹 if/switch/when/try 等。如果你按文章开头引入了那个 ESLint Plugin 就不用担心会弄错了。

总结

这篇文章可能并没有一个很条理的目录结构，大多是一些个人理解和相关思考。因此，这不能替代你去看真正的文档了解更多。如果你看完后还是觉得废话太多，不知所云，那我希望你至少可以在下面几点上跟作者达成共鸣：

  • Hooks 本质是把面向生命周期编程变成了面向业务逻辑编程；

  • Hooks 使用上是一个逻辑状态盒子，输入输出表示的是一种联系；

  • Hooks 是 React 的未来，但还是无法完全替代原始的 Class。

参考

文章可随意转载，但请保留此 原文链接。
非常欢迎有激情的你加入 ES2049 Studio，简历请发送至 caijun.hcj(at)alibaba-inc.com 。