react15与react16.3生命周期的比较

react15： 

注意：render 在执行过程中并不会去操作真实 DOM，它的职能是把需要渲染的内容返回出来。真实 DOM 的渲染工作，在挂载阶段是由 ReactDOM.render 来承接的。componentDidMount 方法在渲染结束后被触发，此时因为真实 DOM 已经挂载到了页面上。

组件的更新分为两种：一种是由父组件更新触发的更新；另一种是组件自身调用自己的 setState 触发的更新

componentReceiveProps 并不是由 props 的变化触发的，而是由父组件的更新触发的

react16.3

注意：16.3生命周期可以按照“挂载”“更新”和“卸载”三个阶段

 比较：

消失的 componentWillMount，新增的 getDerivedStateFromProps

getDerivedStateFromProps 这个 API，其设计的初衷不是试图替换掉 componentWillMount，而是试图替换掉 componentWillReceiveProps，因此它有且仅有一个用途：使用 props 来派生/更新 state

getDerivedStateFromProps 是一个静态方法，内部是访问不到 this

接收两个参数：props 和 state，它们分别代表当前组件接收到的来自父组件的 props 和当前组件自身的 state

getDerivedStateFromProps 方法对 state 的更新动作并非“覆盖”式的更新，而是针对某个属性的定向更新

挂载：

 更新：

 

react16.3和16.4区别

在 React 16.4 中，任何因素触发的组件更新流程（包括由 this.setState 和 forceUpdate 触发的更新流程）都会触发 getDerivedStateFromProps；

而在 v 16.3 版本时，只有父组件的更新会触发该生命周期

为什么要改声生命周期，主要是为fiber让路，

Fiber 会将一个大的更新任务拆解为许多个小任务。每当执行完一个小任务时，渲染线程都会把主线程交回去，看看有没有优先级更高的工作要处理，确保不会出现其他任务被“饿死”的情况，进而避免同步渲染带来的卡顿

 getDerivedStateFromProps 直接被定义为 static 方法这件事上就可见一斑—— static 方法内部拿不到组件实例的 this，这就导致你无法在 getDerivedStateFromProps 里面做任何类似于 this.fetch()、不合理的 this.setState（会导致死循环的那种）这类可能会产生副作用的操作。