本篇博文基于 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个多月的时间过了一遍webpack4，npm，react，在公司内部做了几场培训，发现了其中的一些不协调，但随着版本的迭代，这些不协调也依次在被更正。（看React17的更新内容，原本一些摸棱两可的方法、属性元素命名均会得到改善：）
后续会以此文为契机，开一个专栏，记录、分享公司现有电商项目逐步迁移至react技术栈。
正文
本篇博文会对React16.5.2中的常用生命周期函数做一些翻译、讲解说明及发表一些个人的理解和看法，如有错误、歧义之处，还望大家不吝啬指出，互相交流：）
开篇借用官方提供的生命周期函数图：（虽然是React 16.4的，但同样适用于16.5版本）
出处： projects.wojtekmaj.pl/react-lifec…react组件生命周期函数说明官方地址：reactjs.org/docs/react-…
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)
- 在构造函数中，一般就做两件事情：
- 初始化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 } } 。。。 } 复制代码
- 绑定方法：this.handleClick = this.handleClick.bind(this);
- 我所认为的是：在构造函数中进行方法的绑定后，在使用的时候可以减少匿名方法的产生，进而提高性能。
- 初始化state
- 如果不需要初始化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);
}
}
复制代码- 该方法在React16版本中已经被标记为unsafe，虽然目前依然可以使用（即使用 componentWillReceiveProps 或者 UNSAFE_componentWillReceiveProps 均可），但在 React17 中将会移除，不再建议使用【该方法将会被 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更新时也会触发。
- getDerivedStateFromProps(props, state) 和 componentWillReceiveProps(nextProps) 的差异：
- 该方法无法访问组件的实例，换句话说，不能在该方法内部，调用 this.state，this.myFunction() 等实例对象/方法。
componentWillMount()
使用场景：可以在根组件的componentWillMount中做一些App的配置。
- 该方法在React16版本中已经被标记为unsafe，虽然目前依然可以使用（即使用 componentWillMount 或者 UNSAFE_componentWillMount 均可），但在 React17 中将会移除，不再建议使用。
- 该方法将会被 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(, domNode);//portal return [ 如果返回的是数组类型, 需要在每个html元素上加上 key 值, //fragments否则控制台会报错
] } 复制代码 -
需要注意的是，组件在更新的时候，也会触发 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 这个方法还是有点意义的，但个人认为，作用不是太大，反倒是增加了理解的复杂度，被删除也是情理之中。
- 该方法在React16版本中已经被标记为unsafe，虽然目前依然可以使用（即使用 componentWillUpdate 或者 UNSAFE_componentWillUpdate() 均可），但在 React17 中将会移除，不再建议使用。
- 从功能上来说，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崩溃，为了解决这个问题，React16中引入了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 ( ...<OtherComponent /> MyErrorBoundary> ... ); } ... 复制代码
-
- ErrorBoundary 组件只能捕获其子组件，无法捕获其自身的异常。
- 为什么用 ErrorBoundary 这样的组件？直接在代码中 try-catch 不是很直观？
- 这个问题，就仁智各见了，try-catch 面向的是 代码，而 ErrorBoundary 面向的是组件：这里我想用一个后端例子来说明，在写后端代码时（比如一个 Web Api） ，你可以在具体业务代码中使用 try-catch 来对可能出现异常的代码块做处理，但有的时候，你可能想针对所有“方法”做异常处理，这个时候使用 AOP 的方式来写一个异常处理的方法更好（或者可以认为是 Exception filters这样的自定义类）
- 注意事项：若要查看ErrorBoundary的效果，无法在开发模式下进行（即mode=development）【或者直接运行 npm start，是不会出效果的，会显示具体的错误信息。】，有两种方法可以解决：
-
- 使用 npm run build命令将项目打包后发布到服务器上进行；
-
- 将项目的模式从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 //不再这么做 }); ) 复制代码
而是改用：
```javascript
inputHandler = (e) => {
let value = e.target.value;
this.setState(() => {
return {inputValue: value}; //使用方法的形式，最终再返回一个对象，这里需要注意下，这么写是异步的，但存在一个问题，即输入的内容，需要再方法外层先获取到：如这里的value。
})
}
```
复制代码-
异步写法中，该方法提供了一个回调函数，通过该回调函数，可以确保只有等到setState触发完成之后，才会执行回调的方法（另外一个可以确保在setState执行完成之后再执行的点是componentDidUpdate方法），如：
this.setState((prevState, nextState)=>{ ... }, 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）。
- 正常情况下，这个方法很少使用。