React 生命周期函数深入浅出

本篇博文基于 React 16.5.2

吐槽：

作为一个后端开发，15 年开始关注大前端发展趋势，于 17 年去线下听了场前端开发会议，那个时候 Vue2.0 刚出没多久，就被那快速构建页面给吸引了。最早重返前端还是大半年前，新项目用vue写了几个功能页面，发现现在写前端是真挺舒服，尤其是对于后端人员来说（排除掉 CSS ），快速入门并上手不是什么问题。

至于为什么最终选择了 react 而非 vue ？是因为当时对 react 和 vue 及 RN 和 weex 做了番调研对比，鉴于 weex 的不给力，及后期 react 和 vue 学习成本差不多，但 react 的社区更为活跃，外加发起者背景，就毅然选择了 react 。（我个人是通一精百的支持者，所以对于 react 的理念（learn once，write anywhere），是很赞成的。而 weex 的理念 (write once，run anywhere) 虽然很吸引人，但时下个人觉得技术并未达到此程度，配置的复杂度及大量的轮子需造，难以满足大型项目的要求。包括目前 JD 推出的 Taro，个人目前持观望态度，等到 react 这块应用到项目之后，再码一波 Taro 实际调研一番）。

接触 React 的时候已经是 React 16.3 ，不禁感慨前端发展至今，越有后端的趋势。前后花了3个多月的时间过了一遍 webpack 4， npm ， react ，在公司内部做了几场培训，发现了其中的一些不协调，但随着版本的迭代，这些不协调也依次在被更正。（看 React 17 的更新内容，原本一些摸棱两可的方法、属性元素命名均会得到改善：）

正文

本篇博文会对 React 16.5.2 中的常用生命周期函数做一些翻译、讲解说明及发表一些个人的理解和看法，如有错误、歧义之处，还望大家不吝啬指出，互相交流：）

开篇借用官方提供的生命周期函数图：（虽然是 React 16.4 的，但同样适用于 16.5 版本）

出处：http://projects.wojtekmaj.pl/react-lifecycle-methods-diagram/

react 组件生命周期函数说明官方地址：https://reactjs.org/docs/react-component.html

getDerivedStateFromProps()方法的 16.3 版本与之后的 16.4 和 16.5 有所调整：

  • 在 16.3 版本上，该方法仅在 props 变动时才会被触发。

  • 在 16.3 之后的版本上，该方法调整为 props 和 state 的变动都会触发该方法。

从上图中，我们可以看到，React 的生命周期函数主要集中在三个阶段：挂载阶段（Mounting），更新阶段（Updating）和卸载阶段（Unmounting）。

其中：

  • Mounting阶段主要有这几个方法需要注意：
    • constructor(props)
    • componentWillReceiveProps(nextProps)
    • getDerivedStateFromProps(props, state)
    • componentWillMount()
    • render()
    • componentDidMount()
  • Updating阶段主要有这几个方法需要注意：
    • componentWillReceiveProps(nextProps)
    • getDerivedStateFromProps(props, state)
    • shouldComponentUpdate()
    • componentWillUpdate()
    • render()
    • componentDidUpdate()
  • Unmounting阶段只有一个方法需要注意：
    • componentWillUnmount()
  • 额外的几个方法说明：
    • componentDidCatch()
    • this.setState()
    • this.forceUpdate()

下面我们就对以上生命周期函数做进一步说明：

Mounting：

constructor(props)

  • 在构造函数中，一般就做两件事情：
    1. 初始化 state
      • 在构造函数中初始化 state 需直接赋值，不能调用 this.setState() 方法。
      • constructor() 是唯一能够让你直接给 this.state 赋值的地方，可能有同学会说可以在构造函数外(跟 constructor 同级)直接给 state 赋值，确实，因为 state 派生自 Component 或者 PureComponent 模块，在外层直接赋值，其实是在给基类中的 state 赋值，而在 constructor() 使用 this.state = {…} 进行初始化，实际指的是当前组件这个实例。以下两种赋值方法均可：

class TestContainer extends PureComponent {

    state = {
        content:"1"     //先执行
    }

    constructor(props){
        super(props);
        this.state={
            content:"2" //后执行，最终 this.state.content 为 2
        }
    }
    ...
}

2. 绑定方法：this.handleClick = this.handleClick.bind(this);
    - 我所认为的是：在构造函数中进行方法的绑定后，在使用的时候可以减少匿名方法的产生，进而提高性能。
  • 如果不需要初始化state，或者绑定方法，那么可以不用实现constructor(props)。
  • 如果实现了这个方法，那么应当在方法体的最开始调用 super(props)，否则会导致 this.props 为 undefined 的问题。
  • 不应在该方法中进行 “事件的订阅/引入有 side-effects 的方法”。（这种应该放在 componentDidMount() 中）

这里的 side-effects 方法，翻译出来是 “副作用” 的意思，个人觉得不妥，有点生涩，可能翻译成 “附加作用” 更为妥当。

它指的是，render() 方法应该只完成它的主要功能（如初始化 state 和 绑定方法 ），不应顺带完成其他的附加功能，如 统计，动画 等。

componentWillReceiveProps(nextProps)

该方法的应用场景：根据特定的 props 变换，来触发 state 的更新。如我们可能会有一个 canvas 用来表示页面 loading 百分比，这个时候就可以根据传入的 nextProps 中的百分比属性跟当前 state 的百分比属性做对比，若不一致，则更新，如下：

componentWillReceiveProps(nextProps) {
    if (this.props.percent !== nextProps.percent) {
        this.setUpCircle(nextProps.percent);
    }
}
  • 该方法在 React 16 版本中已经被标记为 unsafe ，虽然目前依然可以使用（即使用 componentWillReceiveProps 或者 UNSAFE_componentWillReceiveProps 均可），但在 React 17 中将会移除，不再建议使用【该方法将会被 getDerivedStateFromProps() 取代。】。
  • 在组件对新(下一个) props 执行任何操作之前，该方法会被触发，并将 下一个props 作为参数。
  • 初始渲染时该方法不会被触发。
  • 可以在该方法内调用 this.setState()，但并不建议调用，因为这会导致只要组件更新，这个方法就会被执行。

getDerivedStateFromProps(props, state)

该方法的应用场景：使组件能够根据父组件传入的 props 来更新其自身的 state

在 16.4 版本之前，只有 props 更新才会触发该方法；但 FB 在 16.4 版本做了完善，目前 props 和 state 的更新均会触发该方法。

  • 该方法的两个入参，分别表示：

    • props：父组件传入的值。可能重命名为 nextProps 更为直观。
    • state：组件自身的state，相当于 this.state，可能重命名为 prevState 更好理解。

  • 该方法在调用 render() 方法前被触发。

  • 如果父组件的 state 进行了更新，那么其子组件也会触发 getDerivedStateFromProps() 方法。

  • 使用该方法的时候需要初始化 state ，否则在控制台中会出现警告信息，如下图：

  • 使用该方法，需要在该方法中返回一个：对象/null：

    • 如果返回的是 对象 ，则会更新 state。
    • 如果返回的是 null ，则表示不更新。

  • 该方法用于取代：componentWillReceiveProps(nextProps) 生命周期函数。

    • getDerivedStateFromProps(props, state) 和 componentWillReceiveProps(nextProps) 的差异：
      • componentWillReceiveProps(props, state)：仅在父组件更新时触发。
      • getDerivedStateFromProps(props, state)：除了父组件更新，其自身的 state 更新时也会触发。

  • 该方法无法访问组件的实例，换句话说，不能在该方法内部，调用 this.state，this.myFunction() 等实例对象/方法。

componentWillMount()

使用场景：可以在根组件的 componentWillMount 中做一些App的配置。

  • 该方法在 React 16 版本中已经被标记为 unsafe ，虽然目前依然可以使用（即使用 componentWillMount 或者 UNSAFE_componentWillMount 均可），但在 React 17 中将会移除，不再建议使用。
  • 该方法将会被 getDerivedStateFromProps() 取代。
  • 该方法是 SSR（server-side render） 渲染上唯一的生命周期函数。
  • 不要在该方法中使用 RPC 请求加载组件的数据。
  • 不能在该方法中调用 this.setState() 。

render()

  • 组件中唯一必须的方法。
  • render() 方法的返回类型目前有 string，number，boolean，null，portal 以及 fragments (带有key属性的数组)，eg：

render() {
    return "string";    //string
    return 123;         //number
    return true;        //如果返回的是 false，则什么都不渲染
    return null;        //如果返回的是 null，则什么都不渲染
    return ReactDOM.createPortal(<MyComponent></MyComponent>, domNode);//portal
    return [            
        <div key="unique_1">如果返回的是数组类型</div>,
        <span key="unique_2">需要在每个html元素上加上 key 值</span>,     //fragments
        <p key="unique_3">否则控制台会报错</p>
    ]
}
  • 需要注意的是，组件在更新的时候，也会触发 render() 方法，但如果 shouldComponentUpdate() 返回的是false，则在 “更新阶段” ，render() 方法不会被触发。
  • 该方法应为一个纯函数，除了做渲染的动作外，不应顺带完成其他动作（如 setState 等），即应避免 side-effects。
  • 应尽量仅在 render() 这个生命周期函数中中从 this.props 和 this.state 中读取数据。

componentDidMount()

使用场景：整体来说就是做“获取一些数据”，或者做必须要有 DOM 才能做的设置。

  • 只会触发一次：在组件被挂载到页面之后被触发，之后就不会再执行了（如页面的更新等都不会再触发，需注意）。
  • 一般一些 rpc 请求会放到这个方法中进行调用。
  • 一般事件的订阅会写在该方法中（但是不要忘记在组件unmount的时候进行取消订阅。）
  • 一些需要初始化DOM节点的操作可以放在这个声明周期函数中进行。
  • 可以在该方法中使用 this.setState()。但需要注意，该操作会在浏览器更新屏幕之前发生，对于用户而言是无感的（即在该方法中又额外调用了一次 this.setState ，导致 render() 触发了2次，但用户的感受依然是屏幕更新了一次）。不过要谨慎在该方法中调用 this.setState，会导致性能问题。

Mounting 阶段，生命周期函数执行顺序如下图（包含子组件）

排除了 UNSAFE 的方法。

Updating：

componentWillReceiveProps(nextProps)

getDerivedStateFromProps(props, state)

shouldComponentUpdate(nextProps, nextState)

使用场景：一般用于精确控制组件是否需要重新渲染（这个方法一般用于性能优化），在绝大多数情况下，每次 state 的更改都应该让组件重新渲染。

  • 只要有一个字段进行了更新，那么其他所有字段都会进行更新，这个会减慢页面速度。（通过 shouldComponentUpdate ，允许我们只有当我们关心的 props 更新的时候，才进行组件的更新）。
  • 但需要谨慎使用，因为一旦你自己忘记实现了这个方法，可能会导致你的 react 组件无法正常更新。

  • 该方法返回的数据类型是一个 boolean ，用于决定组件是否应该更新。

    • 默认返回 true。
    • 当返回 false 的时候，阻止的是当前的组件进行更新，对于当前组件的 “子组件” ，并不受影响。

  • 不应该在继承于 PureComponent 的组件中显示实现 shouldComponentUpdate()，控制台会有警告。

  • 目前，当该方法返回 false 的时候，componentWillUpdate()、更新时的 render() 以及 componentDidUpdate() 都将不会被触发。（FB在官网上说后期有可能会调整该方法：即使返回 false，依然有可能会触发再次渲染，需留个心）

  • 什么时候该方法不会被触发？

    • 组件第一次渲染时。
    • 在组件中调用 this.forceUpdate() 时。

  • 个人建议：

    • 该方法应尽量不去手动实现。
    • 不应使用该方法来做一些防止组件渲染的操作，这可能会导致一些莫名的 bug，如组件明明应该更新，但是却没有更新。
    • 优先可以考虑继承 PureComponent 而非 Component 来优化组件而不是手动实现 shouldComponentUpdate。

  • 不能在这个方法中使用 this.setState()。

componentWillUpdate(nextProps, nextState)

使用场景：当你实现了 shouldComponentUpdate (返回 true 时) 并且在 props 更改时需要执行某些操作的时候，那么 componentWillUpdate 这个方法还是有点意义的，但个人认为，作用不是太大，反倒是增加了理解的复杂度，被删除也是情理之中。

  • 该方法在 React 16 版本中已经被标记为 unsafe，虽然目前依然可以使用（即使用 componentWillUpdate 或者 UNSAFE_componentWillUpdate() 均可），但在 React 17 中将会移除，不再建议使用。
  • 从功能上来说，componentWillUpdate(nextProps, nextState) 跟 componentWillReceiveProps(nextProps) 基本相同，只是前者不允许调用 this.setState()。但是，这2个方法
  • 当 shouldComponentUpdate 返回 false 时， 该生命周期函数将不会被触发。
  • 不能使用 setState。

render()

componentDidUpdate(prevProps, prevState, snapshot)

使用场景：

  • 一般在这个方法中进行 RPC 请求。（可以比较下先前的 props 和当前的 props 是否一致，若一致，则可以不用请求网络数据。）
  • 如果想要在DOM自身更新之后做一些动作（如重新排列网格等），那么可以在这个方法中进行。
  • 该生命周期函数在组件更新完成后立即执行。组件第一次渲染的时候，该生命周期函数不会被触发。
  • 可以做跟 componentDidMount 中所作的相同的事情：如重置布局，重绘画布等
  • 可以使用 setState。

Updating 阶段，生命周期函数执行顺序如下图（包含子组件）

排除了 UNSAFE 的方法。

Unmounting：

componentWillUnmount()

  • 该方法在组件将要被卸载的时候触发。
  • 另外，在渲染期间，当前组件/其子组件的 componentDidMount() 函数发生错误时，该方法也将被触发。
  • eg：
    • 我刻意在”嵌套在子组件中的组件”中的 componentDidMount() 方法中，抛出了一个异常，此时该组件往上的父级组件均触发了 componentWillUnmount()
      • 我尝试在 construct()，componentDidUpdate() 等生命周期函数中抛出异常，均不会触发 componentWillUnmount()。

Unmounting 阶段，生命周期函数执行顺序如下图（包含子组件）

这里需要注意下，该函数是 will unmount，所以触发顺序上是从父组件到子组件，但释放顺序上，是最内层的子组件先释放，最终最外层的根组件才释放。

额外的几个方法说明：

componentDidCatch(error,info)

使用场景：UI中的一些JS错误不应该使整个App崩溃，为了解决这个问题，React 16 中引入了 Error Boundary(错误边界) 这个概念，旨在解决允许页面的部分组件异常但不影响 App 的渲染。可以认为是组件中的 try-catch。而为了实现这个功能，就需要借助 componentDidCatch() 这个生命周期函数。

  • Error Boundaris 是自定义的 react 的组件，这些组件可以捕获其子组件的异常，并显示子组件错误时的替代组件内容，而 App 不会崩溃。
  • 怎么样的组件可以认为是 Error Boundary 组件？
    • 只要该组件内部实现了 componentDidCatch 这个方法就可以认为是 ErrorBoundary 组件，如：

...
class MyErrorBoundary extends Component{
    ...
    componentDidCatch(error,info){
        ...
    }
    ...
}
  • 一个例子：当子组件发生错误时，显示 “sth wrong here.”
    • MyErrorBoundary:

import React, { Component } from 'react';
class MyErrorBoundary extends Component {
    state = {
        isError: false
    }
    render() {
        if (this.state.isError) {
            return (<div>sth wrong here.</div>);
        }
        return this.props.children;
    }
    componentDidCatch(error, info) {
        console.log(error, info);
        this.setState({
            isError = true
        });
        //也可以做其他的一些事情，如 日志，异常数统计 等
    }
}
export default MyErrorBoundary;

- App.js


...
render(){
    return (
    ...
    <MyErrorBoundary>
        <OtherComponent />
    </MyErrorBoundary>
    ...
    );
}
...
  • ErrorBoundary 组件只能捕获其子组件，无法捕获其自身的异常。
  • 为什么用 ErrorBoundary 这样的组件？直接在代码中 try-catch 不是很直观？
    • 这个问题，就仁智各见了， try-catch 面向的是 代码，而 ErrorBoundary 面向的是组件：这里我想用一个后端例子来说明，在写后端代码时（比如一个 Web Api） ，你可以在具体业务代码中使用 try-catch 来对可能出现异常的代码块做处理，但有的时候，你可能想针对所有 “方法” 做异常处理，这个时候使用 AOP 的方式来写一个异常处理的方法更好（或者可以认为是 Exception filters 这样的自定义类）
  • 注意事项：若要查看 ErrorBoundary 的效果，无法在开发模式下进行（即 mode=development）【或者直接运行 npm start，是不会出效果的，会显示具体的错误信息。】，有两种方法可以解决：
      1. 使用 npm run build 命令将项目打包后发布到服务器上进行；
      1. 将项目的模式从 development 调整为 production
        • 需注意，若是使用 create-react-app 来创建的项目，配置文件需要解包后才能进行编辑，运行命令： npm run eject，解包后调整”/scripts/build.js”，将 process.env.NODE_ENV 赋值为 production，之后再运行 npm start 的时候就能看到上面示例代码的效果。

this.setState()

  • 用来设置 state 的值。
  • 在 16.3 开始，FB 建议使用 setState 的异步函数写法，如：
    原先我们在使用的时候是直接进行赋值：

inputHandler = (e) => {
    this.setState({
        inputValue: e.target.value              //不再这么做
    });
)

而是改用：

inputHandler = (e) => {
    let value = e.target.value;
    this.setState(() => {
        return {inputValue: value};   //使用方法的形式，最终再返回一个对象，这里需要注意下，这么写是异步的，但存在一个问题，即输入的内容，需要再方法外层先获取到：如这里的value。
    })
}
  • 异步写法中，该方法提供了一个回调函数，通过该回调函数，可以确保只有等到 setState 触发完成之后，才会执行回调的方法（另外一个可以确保在 setState 执行完成之后再执行的点是 componentDidUpdate 方法），如：

this.setState((prevState, props)=>{
    ...    
}, callback);

- 该方法提供了2个入参，prevState 和 props，前者相当于是 this.state。
- 只有当 setState 方法的第一个参数执行完成之后，才会执行 callback方法。
- 需要注意的是，因为 setState 是一个异步方法，所以在赋值的时候需要注意下，如果需要从表单或者其他地方获取值赋值给 state 的某一个属性，需要先把这个值在 setState 方法之前赋给一个变量，再在 setState 方法中使用这个变量。如


let name = e.target.value;
this.setState((prevState, props)=>{
    return {
        userName : name  //不能够直接 userName:e.target.value，异步方法中获取不到当前上下文
    }    
}, callback);
  • 补充：对于 setState ，其不一定在调用 setState 的时候就立即触发这个动作。为了性能，react 会自行判断，将组件的所有 setState 在同一个时间点一同执行（批量执行），而非调用一次就执行一次。
  • 每一次 setState 都会导致组件的再次渲染，除非 shouldComponentUpdate 返回 false。

this.forceUpdate()

  • 调用forceUpdate()的时候，将会跳过 shouldComponentUpdate() 而直接重新 render() 组件。
  • 父组件中调用 forceUpdate 亦会导致子组件的生命周期函数被触发（包括 componentDidUpdate）。
  • 正常情况下，这个方法很少使用。