在React v16.3之后，React新增了两个新的生命周期函数

getDerivedStateFromProps
getSnapshotBeforeUpdate

而这次的新生命周期函数中 getDerivedStateFromProps是用来取代componentWillReceiveProps的，而getDerivedStateFromProps相比componentWillReceiveProps有什么优越性呢？我们可以对比看一看新旧生命周期函数。

v16.3之前的生命周期函数

从上图我们可以看出这个生命周期函数非常的对称，componentWilUpdate对应componentDidUpdate，componentWillMount对应componentDidMount；同时也考虑到了因为父组件引发渲染可能要根据props更新state的需要，所以有componentWillReceiveProps。

我们可以将生命周期分为两类：挂载卸载过程和更新过程。下面我们依次看一下这两类中各个生命周期函数的简要功能。

挂载卸载过程的生命周期函数

constructor()

constructor()中完成了React数据的初始化，它接受两个参数：props和context，当想在函数内部使用这两个参数时，需使用super()传入这两个参数。

注意：只要使用了constructor()就必须写super(),否则会导致this指向错误。

componentWillMount()

componentWillMount()一般用的比较少，它更多的是在服务端渲染时使用。它代表的过程是组件已经经历了constructor()初始化数据后，但是还未渲染DOM时。

componentDidMount()

组件第一次渲染完成，此时dom节点已经生成，可以在这里调用ajax请求，返回数据setState后组件会重新渲染

componentWillUnmount ()

在这个生命周期函数中会完成组件的卸载和数据的销毁，具体有以下几点

clear你在组建中所有的setTimeout,setInterval
移除所有组建中的监听 removeEventListener

注意：在这个生命周期函数中经常会发生在你组件销毁的时候，ajax请求还未完成的Warning,这时一个简单的方法就是设立标志isMount,具体看下面的代码：

componentDidMount() {
    this.isMount === true
    axios.post().then((res) => {
    // 增加条件ismount为true时
    this.isMount && this.setState({   
      aaa:res
    })
})
}
componentWillUnmount() {
    this.isMount === false
}

更新过程

componentWillReceiveProps (nextProps)

在接受父组件改变后的props需要重新渲染组件时用到的比较多
接受一个参数nextProps
通过对比nextProps和this.props，将nextProps的state为当前组件的state，从而重新渲染组件

  componentWillReceiveProps (nextProps) {
    nextProps.openNotice !== this.props.openNotice&&this.setState({
        openNotice:nextProps.openNotice
    }，() => {
      console.log(this.state.openNotice:nextProps)
      //将state更新为nextProps,在setState的第二个参数（回调）可以打         印出新的state
  })
}

shouldComponentUpdate(nextProps,nextState)

主要用于性能优化(部分更新)
唯一用于控制组件重新渲染的生命周期，由于在react中，setState以后，state发生变化，组件会进入重新渲染的流程，在这里return false可以阻止组件的更新
因为react父组件的重新渲染会导致其所有子组件的重新渲染，这个时候其实我们是不需要所有子组件都跟着重新渲染的，因此需要在子组件的该生命周期中做判断

componentWillUpdate (nextProps,nextState)

shouldComponentUpdate返回true以后，组件进入重新渲染的流程，进入componentWillUpdate,这里同样可以拿到nextProps和nextState。

componentDidUpdate(prevProps,prevState)

组件更新完毕后，react只会在第一次初始化成功会进入componentDidmount,之后每次重新渲染后都会进入这个生命周期，这里可以拿到prevProps和prevState，即更新前的props和state。

render()

render函数会插入jsx生成的dom结构，react会生成一份虚拟dom树，在每一次组件更新时，在此react会通过其diff算法比较更新前后的新旧DOM树，比较以后，找到最小的有差异的DOM节点，并重新渲染。

为什么要废弃旧的生命周期函数

Fiber的引入

在React引入Fiber之后，上面的生命周期函数的组合就显得很不合适，因为如果开启async rendering,在render函数之前的所有函数，都有可能被执行多次。而之前的生命周期函数总会诱导我们在render之前做一些动作，如果现在的这些动作还是放在之前的生命周期函数中，都会有可能被多次调用，这可能不是我们所期待的

开发者的不合法操作

下面简单举两个例子：

在componentWillMount()进行ajax请求

有少部分开发者为了在首次渲染页面时获取到数据，便想着将ajax请求放在componentWillMount()里，其实在 componentWillMount 执行后，第一次渲染就已经开始了，所以如果在 componentWillMount 执行时还没有获取到异步数据的话，页面首次渲染时也仍然会处于没有异步数据的状态。事实上我们需要知道在componentWillMount里发起AJAX，不管多快得到结果也赶不上首次render。而在Fiber启用异步之后，更没有理由在componentWillMount里做AJAX，因为componentWillMount可能会被调用多次，我们可能谁也不会希望在页面渲染前无谓地多次请求一个数据吧。

订阅事件

另一个常见的用例是在 componentWillMount中订阅事件，并在 componentWillUnmount中取消掉相应的事件订阅。但事实上 React 并不能够保证在 componentWillMount被调用后，同一组件的 componentWillUnmount也一定会被调用。在 React引入Fiber开启异步渲染模式后，在 componentWillMount被调用之后，组件的渲染也很有可能会被其他的事务所打断，导致 componentWillUnmount不会被调用。而 componentDidMount就不存在这个问题，在 componentDidMount被调用后，componentWillUnmount一定会随后被调用到，并根据具体代码清除掉组件中存在的事件订阅。

将被deprecate的组件

总之，大道理我们都懂，但是做不做就是另一回事了。随着getDerivedStateFromProps的推出，同时deprecate了一组生命周期API，包括：

componentWillReceiveProps
componentWillMount
componentWillUpdate

同时在React v17将彻底废除这些生命周期函数。这可能是想彻底断了程序员在这些生命周期函数里做些不该做事情的念想。

按照官方说法，以前需要利用被deprecate的所有生命周期函数才能实现的功能，都可以通过getDerivedStateFromProps的帮助来实现。下面我们具体看一看React v16.3之后新增的两个生命周期函数。

v16.3之后的生命周期函数

从上图可以注意到，getDerivedStateFromProps取代componentWillReceiveProps是不准确的，因为componentWillReceiveProps只在Updating过程中才被调用，而且只在因为父组件引发的Updating过程中才被调用；而getDerivedStateFromProps无论是Mounting还是Updating，也无论是因为什么引起的Updating，全部都会被调用。

getDerivedStateFromProps

getDerivedStateFromProps是一个静态函数，所以函数体内不能访问this，简单说，就是应该一个纯函数，纯函数是一个好东西啊，输出完全由输入决定。

static getDerivedStateFromProps(nextProps, prevState) {
  //根据nextProps和prevState计算出预期的状态改变，返回结果会被送给setState
}

每当父组件引发当前组件的渲染过程时，getDerivedStateFromProps会被调用，这样我们有一个机会可以根据新的props和之前的state来调整新的state

getSnapshotBeforeUpdate

在上面的图中我们会发现React v16.3还新增了一个getSnapshotBeforeUpdate，这函数会在render之后执行，而执行之时DOM元素还没有被更新，给了一个机会去获取DOM信息，计算得到一个snapshot，这个snapshot会作为componentDidUpdate的第三个参数传入。

getSnapshotBeforeUpdate(prevProps, prevState) {
    console.log('#enter getSnapshotBeforeUpdate');
    return 'foo';
}
componentDidUpdate(prevProps, prevState, snapshot) {
	console.log('#enter componentDidUpdate snapshot = ', snapshot);
}

之前我们会在componentWillUpdate这个生命周期函数中，读取当前某个 DOM 元素的状态，并在 componentDidUpdate 中进行相应的处理。但在 React引入Fiber开启异步渲染模式后，render 阶段和 commit 阶段之间并不是无缝衔接的，也就是说在 render 阶段读取到的 DOM 元素状态并不总是和 commit 阶段相同，这就导致在componentDidUpdate中使用 componentWillUpdate中读取到的 DOM 元素状态是不安全的，因为这时的值很有可能已经失效了。

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

官方案例：

class ScrollingList extends React.Component {
  listRef = null;

  getSnapshotBeforeUpdate(prevProps, prevState) {
    // Are we adding new items to the list?
    // Capture the scroll position so we can adjust scroll later.
    if (prevProps.list.length < this.props.list.length) {
      return (
        this.listRef.scrollHeight - this.listRef.scrollTop
      );
    }
    return null;
  }

  componentDidUpdate(prevProps, prevState, snapshot) {
    // If we have a snapshot value, we've just added new items.
    // Adjust scroll so these new items don't push the old ones out of view.
    // (snapshot here is the value returned from getSnapshotBeforeUpdate)
    if (snapshot !== null) {
      this.listRef.scrollTop =
        this.listRef.scrollHeight - snapshot;
    }
  }

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

  setListRef = ref => {
    this.listRef = ref;
  };
}

参考文章

程墨Morgan大佬进击的React专栏 React v16.3之后的组件生命周期函数

React复习 --生命周期