谈谈对 React 新旧生命周期的理解

前言

在写这篇文章的时候，React 已经出了 17.0.1 版本了，虽说还来讨论目前 React 新旧生命周期有点晚了，React 两个新生命周期虽然出了很久，但实际开发我却没有用过，因为 React 16 版本后我们直接 React Hook 起飞开发项目。

但对新旧生命周期的探索，还是有助于我们更好理解 React 团队一些思想和做法，于是今天就要回顾下这个问题和理解总结，虽然还是 React Hook 写法香，但是依然要深究学习类组件的东西，了解 React 团队的一些思想与做法。

本文只讨论 React17 版本前的。

React 16 版本后做了什么

首先是给三个生命周期函数加上了 UNSAFE：

• UNSAFE_componentWillMount
• UNSAFE_componentWillReceiveProps
• UNSAFE_componentWillUpdate

这里并不是表示不安全的意思，它只是不建议继续使用，并表示使用这些生命周期的代码可能在未来的 React 版本（目前 React17 还没有完全废除）存在缺陷，如 React Fiber 异步渲染的出现。

同时新增了两个生命周期函数：

• getDerivedStateFromProps
• getSnapshotBeforeUpdate

UNSAFE_componentWillReceiveProps

UNSAFE_componentWillReceiveProps(nextProps)

先来说说这个函数，componentWillReceiveProps

该子组件方法并不是父组件 props 改变才触发，官方回答是：

如果父组件导致组件重新渲染，即使 props 没有更改，也会调用此方法。如果只想处理更改，请确保进行当前值与变更值的比较。

先来说说 React 为什么废除该函数，废除肯定有它不好的地方。

componentWillReceiveProps函数的一般使用场景是：

• 如果组件自身的某个 state 跟父组件传入的 props 密切相关的话，那么可以在该方法中判断前后两个 props 是否相同，如果不同就根据 props 来更新组件自身的 state。
  类似的业务需求比如：一个可以横向滑动的列表，当前高亮的 Tab 显然隶属于列表自身的状态，但很多情况下，业务需求会要求从外部跳转至列表时，根据传入的某个值，直接定位到某个 Tab。

但该方法缺点是会破坏 state 数据的单一数据源，导致组件状态变得不可预测，另一方面也会增加组件的重绘次数。

而在新版本中，官方将更新 state 与触发回调重新分配到了 getDerivedStateFromProps 与 componentDidUpdate 中，使得组件整体的更新逻辑更为清晰。

新生命周期方法static getDerivedStateFromProps(props, state)怎么用呢？

getDerivedStateFromProps 会在调用 render 方法之前调用，并且在初始挂载及后续更新时都会被调用。它应返回一个对象来更新 state，如果返回 null 则不更新任何内容。

从函数名字就可以看出大概意思：使用 props 来派生/更新 state。这就是重点了，但凡你想使用该函数，都必须出于该目的，使用它才是正确且符合规范的。

跟getDerivedStateFromProps不同的是，它在挂载和更新阶段都会执行（componentWillReceiveProps挂载阶段不会执行），因为更新 state 这种需求不仅在 props 更新时存在，在 props 初始化时也是存在的。

而且getDerivedStateFromProps在组件自身 state 更新也会执行而componentWillReceiveProps方法执行则取决于父组件的是否触发重新渲染，也可以看出getDerivedStateFromProps并不是 componentWillReceiveProps方法的替代品.

引起我们注意的是，这个生命周期方法是一个静态方法，静态方法不依赖组件实例而存在，故在该方法内部是无法访问 this 的。新版本生命周期方法能做的事情反而更少了，限制我们只能根据 props 来派生 state，官方是基于什么考量呢？

因为无法拿到组件实例的 this，这也导致我们无法在函数内部做 this.fetch()请求，或者不合理的 this.setState()操作导致可能的死循环或其他副作用。有没有发现，这都是不合理不规范的操作，但开发者们都有机会这样用。可如果加了个静态 static，间接强制我们都无法做了，也从而避免对生命周期的滥用。

React 官方也是通过该限制，尽量保持生命周期行为的可控可预测，根源上帮助了我们避免不合理的编程方式，即一个 API 要保持单一性，做一件事的理念。

如下例子：

// before
componentWillReceiveProps(nextProps) {
  if (nextProps.isLogin !== this.props.isLogin) {
    this.setState({
      isLogin: nextProps.isLogin,
    });
  }
  if (nextProps.isLogin) {
    this.handleClose();
  }
}

// after
static getDerivedStateFromProps(nextProps, prevState) {
  if (nextProps.isLogin !== prevState.isLogin) { // 被对比的props会被保存一份在state里
    return {
      isLogin: nextProps.isLogin, // getDerivedStateFromProps 的返回值会自动 setState
    };
  }
  return null;
}

componentDidUpdate(prevProps, prevState) {
  if (!prevState.isLogin && this.props.isLogin) {
    this.handleClose();
  }
}

UNSAVE_componentWillMount

UNSAFE_componentWillMount() 在挂载之前被调用。它在 render() 之前调用，因此在此方法中同步调用 setState() 不会触发额外渲染。

我们应该避免在此方法中引入任何副作用或事件订阅，而是选用componentDidMount()。

在 React 初学者刚接触的时候，可能有这样一个疑问：一般都是数据请求放在componentDidMount里面，但放在componentWillMount不是会更快获取数据吗？

因为理解是componentWillMount在 render 之前执行，早一点执行就早拿到请求结果；但是其实不管你请求多快，都赶不上首次 render，页面首次渲染依旧处于没有获取异步数据的状态。

还有一个原因，componentWillMount是服务端渲染唯一会调用的生命周期函数，如果你在此方法中请求数据，那么服务端渲染的时候，在服务端和客户端都会分别请求两次相同的数据，这显然也我们想看到的结果。

特别是有了 React Fiber，更有机会被调用多次，故请求不应该放在componentWillMount中。

还有一个错误的使用是在componentWillMount中订阅事件，并在componentWillUnmount中取消掉相应的事件订阅。事实上只有调用componentDidMount后，React 才能保证稍后调用componentWillUnmount进行清理。而且服务端渲染时不会调用componentWillUnmount，可能导致内存泄露。

还有人会将事件监听器（或订阅）添加到 componentWillMount 中，但这可能导致服务器渲染（永远不会调用 componentWillUnmount）和异步渲染（在渲染完成之前可能被中断，导致不调用 componentWillUnmount）的内存泄漏。

对于该函数，一般情况，如果项目有使用，则是通常把现有 componentWillMount 中的代码迁移至 componentDidMount 即可。

UNSAFE_componentWillUpdate

当组件收到新的 props 或 state 时，会在渲染之前调用 UNSAFE_componentWillUpdate()。使用此作为在更新发生之前执行准备更新的机会。初始渲染不会调用此方法。

注意，不能在该方法中调用 this.setState()；在 componentWillUpdate 返回之前，你也不应该执行任何其他操作（例如，dispatch Redux 的 action）触发对 React 组件的更新。

首先跟上面两个函数一样，该函数也发生在 render 之前，也存在一次更新被调用多次的可能，从这一点上看就依然不可取了。

其次，该方法常见的用法是在组件更新前，读取当前某个 DOM 元素的状态，并在 componentDidUpdate 中进行相应的处理。但 React 16 版本后有 suspense、异步渲染机制等等，render 过程可以被分割成多次完成，还可以被暂停甚至回溯，这导致 componentWillUpdate 和 componentDidUpdate 执行前后可能会间隔很长时间，这导致 DOM 元素状态是不安全的，因为这时的值很有可能已经失效了。而且足够使用户进行交互操作更改当前组件的状态，这样可能会导致难以追踪的 BUG。

为了解决这个问题，于是就有了新的生命周期函数：

getSnapshotBeforeUpdate(prevProps, prevState)

getSnapshotBeforeUpdate 在最近一次渲染输出（提交到 DOM 节点）之前调用。它使得组件能在发生更改之前从 DOM 中捕获一些信息（例如，滚动位置）。此生命周期的任何返回值将作为第三个参数传入componentDidUpdate(prevProps, prevState, snapshot)

与 componentWillUpdate 不同，getSnapshotBeforeUpdate 会在最终的 render 之前被调用，也就是说在 getSnapshotBeforeUpdate 中读取到的 DOM 元素状态是可以保证与 componentDidUpdate 中一致的。

虽然 getSnapshotBeforeUpdate 不是一个静态方法，但我们也应该尽量使用它去返回一个值。这个值会随后被传入到 componentDidUpdate 中，然后我们就可以在 componentDidUpdate 中去更新组件的状态，而不是在 getSnapshotBeforeUpdate 中直接更新组件状态。避免了 componentWillUpdate 和 componentDidUpdate 配合使用时将组件临时的状态数据存在组件实例上浪费内存，getSnapshotBeforeUpdate 返回的数据在 componentDidUpdate 中用完即被销毁，效率更高。

来看官方的一个例子：

class ScrollingList extends React.Component {
  constructor(props) {
    super(props);
    this.listRef = React.createRef();
  }

  getSnapshotBeforeUpdate(prevProps, prevState) {
    // 我们是否在 list 中添加新的 items？
    // 捕获滚动位置以便我们稍后调整滚动位置。
    if (prevProps.list.length < this.props.list.length) {
      const list = this.listRef.current;
      return list.scrollHeight - list.scrollTop;
    }
    return null;
  }

  componentDidUpdate(prevProps, prevState, snapshot) {
    // 如果我们 snapshot 有值，说明我们刚刚添加了新的 items，
    // 调整滚动位置使得这些新 items 不会将旧的 items 推出视图。
    //（这里的 snapshot 是 getSnapshotBeforeUpdate 的返回值）
    if (snapshot !== null) {
      const list = this.listRef.current;
      list.scrollTop = list.scrollHeight - snapshot;
    }
  }

  render() {
    return (
      <div ref={this.listRef}>{/* ...contents... */}</div>
    );
  }
}

如果项目中有用到componentWillUpdate的话，升级方案就是将现有的 componentWillUpdate 中的回调函数迁移至 componentDidUpdate。如果触发某些回调函数时需要用到 DOM 元素的状态，则将对比或计算的过程迁移至 getSnapshotBeforeUpdate，然后在 componentDidUpdate 中统一触发回调或更新状态。

除了这些，React 16 版本的依然还有大改动，其中引人注目的就是 Fiber，之后我还会抽空写一篇关于 React Fiber 的文章，可以关注我的个人技术博文 Github 仓库，觉得不错的话欢迎 star，给我一点鼓励继续写作吧~

参考：

• 为什么废弃 react 生命周期函数
• React v16.3 版本新生命周期函数浅析及升级方案