react 生命周期执行顺序，render执行条件

转载：https://segmentfault.com/a/1190000016617400

首先来列举一下react的生命周期(react16版本)

Mounting（加载阶段：涉及4个钩子函数）

1.constructor()
加载的时候调用一次，可以初始化state

2.static getDerivedStateFromProps(props, state)
组件每次被rerender的时候，包括在组件构建之后(虚拟dom之后，实际dom挂载之前)，每次获取新的props或state之后；每次接收新的props之后都会返回一个对象作为新的state，返回null则说明不需要更新state；配合componentDidUpdate，可以覆盖componentWillReceiveProps的所有用法

3.render()
react最重要的步骤，创建虚拟dom，进行diff算法，更新dom树都在此进行

4.componentDidMount()
组件渲染之后调用，只调用一次

Updating（更新阶段：涉及5个钩子函数)

1.static getDerivedStateFromProps(props, state)
组件每次被rerender的时候，包括在组件构建之后(虚拟dom之后，实际dom挂载之前)，每次获取新的props或state之后；每次接收新的props之后都会返回一个对象作为新的state，返回null则说明不需要更新state；配合componentDidUpdate，可以覆盖componentWillReceiveProps的所有用法

2.shouldComponentUpdate(nextProps, nextState)
组件接收到新的props或者state时调用，return true就会更新dom（使用diff算法更新），return false能阻止更新（不调用render）

3.render()
react最重要的步骤，创建虚拟dom，进行diff算法，更新dom树都在此进行

4.getSnapshotBeforeUpdate(prevProps, prevState)
触发时间: update发生的时候，在render之后，在组件dom渲染之前；返回一个值，作为componentDidUpdate的第三个参数；配合componentDidUpdate, 可以覆盖componentWillUpdate的所有用法

5.componentDidUpdate()
组件加载时不调用，组件更新完成后调用

Unmounting（卸载阶段：涉及1个钩子函数）
1.componentWillUnmount()

Error Handling(错误处理)
1.componentDidCatch(error，info)
任何一处的javascript报错会触发

组件的基本写法

import React, { Component } from 'react'

export default class NewReactComponent extends Component {
    constructor(props) {
        super(props)
        // getDefaultProps：接收初始props
        // getInitialState：初始化state
    }
    state = {

    }
    static getDerivedStateFromProps(props, state) { // 组件每次被rerender的时候，包括在组件构建之后(虚拟dom之后，实际dom挂载之前)，每次获取新的props或state之后；;每次接收新的props之后都会返回一个对象作为新的state，返回null则说明不需要更新state
        return state
    }
    componentDidCatch(error, info) { // 获取到javascript错误

    }
    render() {
        return (
            <h2>New React.Component</h2>
        )
    }
    componentDidMount() { // 挂载后
        
    }   
    shouldComponentUpdate(nextProps, nextState) { // 组件Props或者state改变时触发，true：更新，false：不更新
        return true
    }
    getSnapshotBeforeUpdate(prevProps, prevState) { // 组件更新前触发
         return null;
    }
    componentDidUpdate() { // 组件更新后触发

    }
    componentWillUnmount() { // 组件卸载时触发

    }
}

新的生命周期

2103351222-5bbb1369e1f41_articlex.jpg

1.React16新的生命周期弃用了componentWillMount、componentWillReceiveProps，componentWillUpdate
2.新增了getDerivedStateFromProps、getSnapshotBeforeUpdate来代替弃用的三个钩子函数（componentWillMount、componentWillReceiveProps，componentWillUpdate）
3.React16并没有删除这三个钩子函数，但是不能和新增的钩子函数（getDerivedStateFromProps、getSnapshotBeforeUpdate）混用，React17将会删除componentWillMount、componentWillReceiveProps，componentWillUpdate
4.新增了对错误的处理（componentDidCatch）

了解了生命周期，下面来说一说生命周期的执行顺序

1.组件生命周期的执行次数

1.只执行一次： constructor、componentDidMount
2.执行多次：render、getDerivedStateFromProps、shouldComponentUpdate、getSnapshotBeforeUpdate、componentDidUpdate
3.有条件执行：componentWillUnmount

1.组件的生命周期执行顺序

假设组件嵌套关系parent组件中有child组件

不更新dom执行顺序如下

1602223811(1).jpg

更新dom执行顺序如下

1602213835(1).jpg

修改父组件的state

1602214634(1).jpg

修改子组件的state

1602214666(1).jpg

结论

1.完成前的顺序是从根部到子部，完成时是从子部到根部。（类似于事件机制）
2.子组件setState是不能触发其父组件的生命周期更新函数，只能触发更低一级别的生命周期更新函数。

setState在生命周期中的使用注意事项
1、仅当子组件的props发生变化时getDerivedStateFromProps生命钩子才会被触发。该生命周期会有一个参数nextProps，表示子组件被更新后的props。因此可以在该周期获取最新的props在通过setState更新组件状态。

2、子组件props或state更新都会触发shouldComponentUpdate生命钩子。该生命周期有两个参数nextProps，nextState 表示更新后的props和更新后的state，该生命周期是整提高组件性能的一个重要函数，它通过判断当前状态与之前状态来返回一个布尔值并决定是否更新视图，如果返回false视图始终不会更新。返回true就会更新视图

3、getSnapshotBeforeUpdate生命周期在shouldComponentUpdate返回true后被触发。在这两个生命周期只要视图更新就会触发，因此不能再这两个生命周期中使用setState。否则会导致死循环。

4、componentDidUpdate生命周期在shouldComponentUpdate返回true后触发。在此生命周期中setState会导致视图再次更新，类似于componentDidMount，因此除非特殊业务需求，否则不建议在此生命周期中使用setState。

5、componentWillUnmount生命周期在组件被卸载后触发，在此生命周期使用setState不会触发。

以下文章来源于魔术师卡颂，作者卡颂

react render渲染条件

点击Parent组件的div，触发更新，Son组件会打印child render!么？

function Son() {
  console.log('child render!');
  return <div>Son</div>;
}


function Parent(props) {
  const [count, setCount] = React.useState(0);

  return (
    <div onClick={() => {setCount(count + 1)}}>
      count:{count}
      {props.children}
    </div>
  );
}


function App() {
  return (
    <Parent>
      <Son/>
    </Parent>
  );
}

const rootEl = document.querySelector("#root");
ReactDOM.render(<App/>, rootEl);

render需要满足的条件

React创建Fiber树时，每个组件对应的fiber都是通过如下两个逻辑之一创建的：
render。即调用render函数，根据返回的JSX创建新的fiber。
bailout。即满足一定条件时，React判断该组件在更新前后没有发生变化，则复用该组件在上一次更新的fiber作为本次更新的fiber。
可以看到，当命中bailout逻辑时，是不会调用render函数的。
所以，Son组件不会打印child render!是因为命中了bailout逻辑。

bailout需要满足的条件

什么情况下会进入bailout逻辑？当同时满足如下4个条件时：

oldProps === newProps ？

即本次更新的props（newProps）不等于上次更新的props（oldProps）。
注意这里是全等比较。
我们知道组件render会返回JSX，JSX是React.createElement的语法糖。
所以render的返回结果实际上是React.createElement的执行结果，即一个包含props属性的对象。
即使本次更新与上次更新props中每一项参数都没有变化，但是本次更新是React.createElement的执行结果，是一个全新的props引用，所以oldProps !== newProps。
如果我们使用了PureComponent或Memo，那么在判断是进入render还是bailout时，不会判断oldProps与newProps是否全等，而是会对props内每个属性进行浅比较。

context没有变化

即context的value没有变化。

workInProgress.type === current.type ？

更新前后fiber.type是否变化，比如div是否变为p。

!includesSomeLane(renderLanes, updateLanes) ？

当前fiber上是否存在更新，如果存在那么更新的优先级是否和本次整棵fiber树调度的优先级一致？
如果一致则进入render逻辑。
就我们的Demo来说，Parent是整棵树中唯一能触发更新的组件（通过调用setCount）。
所以Parent对应的fiber是唯一满足条件4的fiber。

Demo的详细执行逻辑

所以，Demo中Son进入bailout逻辑，一定是同时满足以上4个条件。我们一个个来看。
条件2，Demo中没有用到context，满足。
条件3，更新前后type都为Son对应的函数组件，满足。
条件4，Son本身无法触发更新，满足。
所以，重点是条件1。让我们详细来看下。
本次更新开始时，Fiber树存在如下2个fiber

FiberRootNode
      |
  RootFiber

其中FiberRootNode是整个应用的根节点，RootFiber是调用ReactDOM.render创建的fiber。
首先，RootFiber会进入bailout的逻辑，所以返回的App fiber和更新前是一致的。

FiberRootNode
      |
  RootFiber      
      |
  App fiber

由于App fiber是RootFiber走bailout逻辑返回的，所以对于App fiber，oldProps === newProps。并且bailout剩下3个条件也满足。
所以App fiber也会走bailout逻辑，返回Parent fiber。

FiberRootNode
      |
  RootFiber      
      |
   App fiber
      |
 Parent fiber

由于更新是Parent fiber触发的，所以他不满足条件4，会走render的逻辑。
接下来是关键
如果render返回的Son是如下形式：

<Son/>

会编译为

React.createElement(Son, null)

执行后返回JSX。
由于props的引用改变，oldProps !== newProps。会走render逻辑。
但是在Demo中Son是如下形式：

{props.children}

其中，props.children是Son对应的JSX，而这里的props是App fiber走bailout逻辑后返回的。
所以Son对应的JSX与上次更新时一致，JSX中保存的props也就一致，满足条件1。
可以看到，Son满足bailout的所有条件，所以不会render。