React 官方正式发布了 v16.3 版本。在这次的更新中，除了前段时间被热烈讨论的新 Context API之外，新引入的两个生命周期函数getDerivedStateFromProps，getSnapshotBeforeUpdate以及在未来 v17.0 版本中即将被移除的三个生命周期函数componentWillMount，componentWillReceiveProps，componentWillUpdate也非常值得我们花点时间去探究一下其背后的原因以及在具体项目中的升级方案。
componentWillMount
首屏无数据导致白屏
在 React 应用中，许多开发者为了避免第一次渲染时页面因为没有获取到异步数据导致的白屏，而将数据请求部分的代码放在了componentWillMount中，希望可以避免白屏并提早异步请求的发送时间。但事实上在componentWillMount执行后，第一次渲染就已经开始了，所以如果在componentWillMount执行时还没有获取到异步数据的话，页面首次渲染时也仍然会处于没有异步数据的状态。换句话说，组件在首次渲染时总是会处于没有异步数据的状态，所以不论在哪里发送数据请求，都无法直接解决这一问题。而关于提早发送数据请求，官方也鼓励将数据请求部分的代码放在组件的constructor中，而不是componentWillMount。
另一个常见的componentWillMount的用例是在服务端渲染时获取数据，因为在服务端渲染时componentDidMount是不会被调用的。针对这个问题，笔者这里提供两种解法。第一个简单的解法是将所有的数据请求都放在componentDidMount中，即只在客户端请求异步数据。这样做可以避免在服务端和客户端分别请求两次相同的数据（componentWillMount在客户端渲染时同样会被调用到），但很明显的缺点就是无法在服务端渲染时获取到页面渲染所需的所有数据，所以如果我们需要保证服务端返回的 HTML 就是用户最终看到的 HTML 的话，我们可以将每个页面的数据获取逻辑单独抽离出来，然后一一对应到相应的页面，在服务端根据当前页面的路由找到相应的数据请求，利用链式的 Promise 在渲染最终的页面前就将数据塞入 redux store 或其他数据管理工具中，这样服务端返回的 HTML 就是包含异步数据的结果了。
事件订阅
另一个常见的用例是在componentWillMount中订阅事件，并在componentWillUnmount中取消掉相应的事件订阅。但事实上 React 并不能够保证在componentWillMount被调用后，同一组件的componentWillUnmount也一定会被调用。一个当前版本的例子如服务端渲染时，componentWillUnmount是不会在服务端被调用的，所以在componentWillMount中订阅事件就会直接导致服务端的内存泄漏。另一方面，在未来 React 开启异步渲染模式后，在componentWillMount被调用之后，组件的渲染也很有可能会被其他的事务所打断，导致componentWillUnmount不会被调用。而componentDidMount就不存在这个问题，在componentDidMount被调用后，componentWillUnmount一定会随后被调用到，并根据具体代码清除掉组件中存在的事件订阅。
升级方案
将现有 componentWillMount 中的代码迁移至 componentDidMount 即可。
componentWillReceiveProps
更新由 props 决定的 state 及处理特定情况下的回调
在老版本的 React 中，如果组件自身的某个 state 跟其 props 密切相关的话，一直都没有一种很优雅的处理方式去更新 state，而是需要在componentWillReceiveProps中判断前后两个 props 是否相同，如果不同再将新的 props 更新到相应的 state 上去。这样做一来会破坏 state 数据的单一数据源，导致组件状态变得不可预测，另一方面也会增加组件的重绘次数。类似的业务需求也有很多，如一个可以横向滑动的列表，当前高亮的 Tab 显然隶属于列表自身的状态，但很多情况下，业务需求会要求从外部跳转至列表时，根据传入的某个值，直接定位到某个 Tab。
在新版本中，React 官方提供了一个更为简洁的生命周期函数：
static getDerivedStateFromProps(nextProps, prevState)
通常来讲，在componentWillReceiveProps中，我们一般会做以下两件事，一是根据 props 来更新 state，二是触发一些回调，如动画或页面跳转等。在老版本的 React 中，这两件事我们都需要在componentWillReceiveProps中去做。而在新版本中，官方将更新 state 与触发回调重新分配到了getDerivedStateFromProps与componentDidUpdate中，使得组件整体的更新逻辑更为清晰。而且在getDerivedStateFromProps中还禁止了组件去访问 this.props，强制让开发者去比较 nextProps 与 prevState 中的值，以确保当开发者用到getDerivedStateFromProps这个生命周期函数时，就是在根据当前的 props 来更新组件的 state，而不是去做其他一些让组件自身状态变得更加不可预测的事情。
升级方案
将现有componentWillReceiveProps中的代码根据更新 state 或回调，分别在getDerivedStateFromProps及componentDidUpdate中进行相应的重写即可，注意新老生命周期函数中prevProps，this.props，nextProps，prevState，this.state的不同。
componentWillUpdate
处理因为 props 改变而带来的副作用
与componentWillReceiveProps类似，许多开发者也会在componentWillUpdate中根据 props 的变化去触发一些回调。但不论是componentWillReceiveProps还是componentWillUpdate，都有可能在一次更新中被调用多次，也就是说写在这里的回调函数也有可能会被调用多次，这显然是不可取的。与componentDidMount类似，componentDidUpdate也不存在这样的问题，一次更新中componentDidUpdate只会被调用一次，所以将原先写在componentWillUpdate中的回调迁移至componentDidUpdate就可以解决这个问题。
在组件更新前读取 DOM 元素状态
另一个常见的componentWillUpdate的用例是在组件更新前，读取当前某个 DOM 元素的状态，并在componentDidUpdate中进行相应的处理。但在 React 开启异步渲染模式后，render 阶段和 commit 阶段之间并不是无缝衔接的，也就是说在 render 阶段读取到的 DOM 元素状态并不总是和 commit 阶段相同，这就导致在componentDidUpdate中使用componentWillUpdate中读取到的 DOM 元素状态是不安全的，因为这时的值很有可能已经失效了。
为了解决上面提到的这个问题，React 提供了一个新的生命周期函数：
getSnapshotBeforeUpdate(prevProps, prevState)
与componentWillUpdate不同，getSnapshotBeforeUpdate会在最终的 render 之前被调用，也就是说在getSnapshotBeforeUpdate中读取到的 DOM 元素状态是可以保证与componentDidUpdate中一致的。虽然getSnapshotBeforeUpdate不是一个静态方法，但我们也应该尽量使用它去返回一个值。这个值会随后被传入到componentDidUpdate中，然后我们就可以在componentDidUpdate中去更新组件的状态，而不是在getSnapshotBeforeUpdate中直接更新组件状态。
升级方案
将现有的componentWillUpdate中的回调函数迁移至componentDidUpdate。如果触发某些回调函数时需要用到 DOM 元素的状态，则将对比或计算的过程迁移至getSnapshotBeforeUpdate，然后在componentDidUpdate中统一触发回调或更新状态。
改变之后是不是发现变化很大，简洁的多了; 以上纯属转发，仅供学习参考，不足之处多多指教，程序猿努力学习中...
