React(v16.8.4)生命周期详解

当前版本v16.8.4

装载过程(组件第一次在DOM树中渲染的过程)：

constructor(经常使用) -> getInitialState(v16.0已废弃) -> getDefaultProps(v16.0已废弃) -> componentWillMount(v17.0中将被弃用) -> getDerivedStateFromProps(v16.3新增，并在v16.4中升级优化了一下) -> render(必需要) -> componentDidMount(经常使用)

更新过程(当组件被从新渲染的过程，state改变或props改变或父组件forceUpdate引起子组件的从新渲染)：

componentWillReceiveProps(v17.0中将被弃用) -> getDerivedStateFromProps -> shouldComponentUpdate -> componentWillUpdate(v17.0中将被弃用) -> render -> getSnapshotBeforeUpdate -> componentDidUpdate

卸载过程(组件从DOM中删除的过程)：

componentWillUnmount

错误处理(当组件发生错误的时候，用得极少)

getDerivedStateFromError(v16.6新增) -> componentDidCatch(将来将被废弃)

constructor：(能够不写，直接写state = {})

ES6中每一个类的构造函数，并非每一个组件都须要定义本身的构造函数。好比无状态组件。
做用：

1. 初始化state, 例如super(props)下的 this.state = {}
2. 绑定成员函数的this环境。例如 this.onClickButton = this.onClickButton.bind(this)。但这种方案通常都会用箭头函数代替
   而综合以上两点做用，其实不少时候，你会在antd官网的例子上看到一些例子，并无使用contructor, 而是直接简写为

state = {
   count: 0
  }
  // 这是由于在ES6的继承中，其实无论子类写不写constructor,在new实例的过程都会给补上constructor
  class ColorPoint extends Point {
  
  }
  // 等同于 
  class ColorPoint extends Point {
    constructor(...args) {
      super(...args);
    }
  }

getInitialState: (随着v16.0版本createClass被弃用，该方法也不存在了)

返回值会用来初始化组件的this.state

getDefaultProps: (随着v16.0版本createClass被弃用，该方法也不存在了)

返回值能够做为props的初始值

componentWillMount：（即将在v17.0中被弃用，不用）

能够作：

1. 直接使用setState改变组件状态，render会打印一次改变后的值（可是你这样作没什么意义，还不如直接在constructor的时候设好初始值）
2. 发送Ajax请求（服务端渲染的时候）

不要作：

1. 发送ajax请求（缘由以下）
2. 执行DOM操做（这个阶段DOM还没渲染出来）

最终建议：

不要用这个生命周期

在没被弃用的时候也几乎不用，这时候没有任何渲染出来的结果，即便调用this.setState修改状态也不会引起从新绘制。全部在这里能够作的事，均可以提早到 constructor中去作。有些人可能用过vue, 在vue中也常常在created中去请求接口，好比可能初始值是0，而后在created中请求接口，简单的理解成想页面在展现的时候就直接显示接口请求返回后的数据1了，而不是咱们看到页面的时候先看到0，而后忽然变成1了。我的理解vue的created和react的componentWillMount应该也是相差不了太多的，若是是在componentWillMount的时候你的数据还不是1的话，你这时候请求数据，实际上是另外开了一个线程去执行异步操做了，render函数并不会等你异步请求结果返回1才去执行render。网络差的话，你先看到0再看到忽然变成1也是很正常的事。在这里请求和在componentDidMount中请求并不会有太大的差异。同理，其实vue中特地区分该在created中仍是mounted中请求接口也是不必的，还不如统一到mounted/componentDidMount中去请求接口，由于咱们有些方法仍是要等真实dom存在后才去执行的。

getDerivedStateFromProps(props, state):

第一次在装载阶段（当前组件实例化）会被触发比较好理解，可是组件更新阶段，究竟组件更新阶段的什么操做会触发这个函数？
假如我在父组件改变了props 会触发这个函数吗？答案是会。
假如我在当前组件 this.setState 会触发这个函数吗？在v16.3中不会，可是在v16.4以上就会了。截至2019-03-17，在 https://react.docschina.org/docs/react-component.html#static-getderivedstatefromprops 上看到的翻译仍是错的。不信能够本身试试？
假如我在父组件只是执行了 forceUpdate 强行引起一次从新绘制，那当前组件(子组件)的getDerivedStateFromProps又会被触发吗？
同样，在v16.3中不会，可是在v16.4以上就会了。
它返回一个对象来更新状态，若是返回的是null就表示不更新任何内容
这个方法react官方都意识到不少人对如何使用它存在许多误解(https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html)，
目前不少人的博客其实写得也有点问题的。

render：（必需要）

返回一个JSX表示的对象，而后由React库来根据返回对象决定如何渲染。并非返回的真实DOM，其余的生命周期均可以省，可是这个必需要

componentDidMount:（经常使用）

能够作：

1. 发送ajax请求

不要作：

1. 直接使用this.setState更新状态，这样会二次渲染（不过常常会有发送请求后，在回调函数里setState，这也是不可避免的）

仅在浏览器端执行，此时已经有了真实的dom节点，在这个阶段经常使用于处理接口请求，或者一些DOM操做。由于有些组件的启动动做是依赖DOM的，例如动画等。

须要注意的是：能够在这里发送异步请求，在回调函数里调用setState设置state。可是尽可能不要在这里直接调用setState()设置状态。由于会触发一次额外的从新渲染，可能形成性能问题。

componentWillReceiveProps(nextProps):（即将在v17.0中被弃用，不用）

能够作：

1. 根据props的更新同步组件状态。

不要作：

1. 发送ajax请求
2. 尤为是不要在这里setState

当前组件setState()不会调用；
父组件props改变会调用；
父组件经过forceUpdate从新执行render，也会调用当前组件的componentWillReceiveProps；
只要父组件的render函数被调用，那么当前组件(子组件)都会触发这个函数，无论父组件的props发不发生变化。例如父组件执行了 forceUpdate 强行引起一次从新绘制。当前组件的componentWillReceiveProps就会被触发。而在当前组件this.setState是不会触发这个函数的。由于componentWillReceiveProps适合根据新的props值（也就是参数nextProps）来计算出是否是要更新内部状态state。更新组件内部状态的方法就是this.setState。若是this.setState的调用致使componentWillReceiveProps再依次被调用，那就是一个死循环了。

componentWillReceiveProps(nextProps) {
    if (this.props.oneProp !== nextProps.oneProp) {
        // 不少人会在这里同时写setState 而且 发送异步请求，其实这是不合理的
        // 应该只在这里根据props的改变去执行 setState来同步props到组件的状态中, 不应在这里发送异步请求
    }
}
// 现现在更好的方式是使用getDerivedStateFromProps 去改变state 和 componentDidUpdate 去异步请求 来代替上面的方案

shouldComponentUpdate(nextProps, nextState):(若是你对性能有更极致的要求，水平没达到必定高度就不要去动它了)

当前组件setState()会调用；
父组件props改变会调用；
父组件经过forceUpdate从新执行render，不会调用当前组件的shouldComponentUpdate；
这个方法主要是为了性能优化而设计的，考虑使用内置的PureComponent,而不是本身在这个函数里写比较，更不建议在这个组件里使用JSON.stringify去深度检查，效率很是低。
这里返回一个布尔值，默认都返回的true, 若是返回false，那这个生命周期后面的更新阶段的生命周期都不会执行了。

componentWillUpdate(nextProps, nextState):（即将在v17.0中被弃用，不用）

它能够作的，不要作的同componentWillMount同样

当前组件setState()会调用；
父组件props改变会调用；
父组件经过forceUpdate从新执行render，也会调用当前组件的shouldComponentUpdate；
其实和componentWillMount相似，
这个方法也应该尽可能避免使用，将要被遗弃。几乎用不上。应该都统一到componentDidUpdate中去处理。

getSnapshotBeforeUpdate(prevProps, prevState)：

setState(),props发生改变，父组件从新render都会调用。发生在更新状态的render以后，这时候已经能够读取dom了。一般用于处理滚动位置的聊天线程等UI中。
和getDerivedStateFromProps同样它返回一个对象来更新状态，若是返回的是null就表示不更新任何内容

componentDidUpdate(prevProps, prevState):

它能够作的，不要作的同componentDidUpdate同样

setState(),props发生改变，父组件从新render都会调用。这个方法相对用得也比较多。同componentDidMount处理事件函数相似，若是组件被更新的时候，原有的内容被从新绘制后可能也须要再次处理事件函数。

componentDidUpdate(prevProps, prevState) {
  if(prevProps.oneProp !== this.props.oneProp) {
    // 若是有变化，在这里作一些异步请求，可能会在异步请求的回调函数里setState
    // 不要直接去执行this.setState
  }
}

componentWillUnmount():

当react组件要从dom树上删除掉的时候，这个方法就会被调用。
若是在componentDidMount中使用非React的方法创造了一些DOM元素，若是撒手无论可能会形成内存泄漏，那就须要在componentWillUnmount中把这些创造的DOM元素清理掉。
应用场景：清理定时器，关闭socket, 清除监听器等

import React, { Component } from "react";

export default class LifeCycle extends Component {
  state = {
  
  }
  static getDerivedStateFromProps(props, state) {
  
  }  
  componentDidMount = () => {

  }  
  shouldComponentUpdate = (nextProps, nextState) => {

  }
  getSnapshotBeforeUpdate = (prevProps, prevState) => {

  }
  componentDidUpdate = (prevProps, prevState) => {
    
  }
  componentWillUnmount = () => {
    
  }
  render() {
    return (
      <div>
        
      </div>
    )
  }
}