React Reconciliation

React给我们提供了很多的API，比如setState或者hook(setXXX)帮助我们更新state，从而在页面上展示新的数据。

我们只知道调用了更新state的API，react会默默的帮助我们去做UI的update，但是并不知道其中的更新的过程。接下来我会给大家介绍state改变之后，react帮助我们做的事情。

react UI update流程

组件state/props发生改变
触发组件render函数的执行，render函数会创建一个新的react element tree（js object/aka virtual dom）
react会根据某一种diff算法，对比新产生的react element tree和之前tree之间，有哪些element需要被更新
更新UI（真实DOM）

Reconciliation

react Reconciliation 算法就是所谓的react diff算法，这种算法用来compare新旧的react element tree（virtual dom），找到一个更新真实UI的最高效的方式。

算法的大概思路是：
react会从上往下diff react element tree，也就是从root element开始向下diff。

image.png

接下来的diff方式取决于root element的类型：

React DOM Element

当root element是一个普通的HTML tag，比如div、span等标签

Same type

如果新旧的virtual DOM tree的某一个root节点dom类型完全相同，那么react会去check DOM元素的所有属性，最终只会update改变的DOM属性，而不会updateDOM元素。

different type

如果新旧DOM tree的root element dom类型不同，那么react会直接将当前的这个root element以及其tree上的所有节点全部删除，创建新的root element，并重新构建其树中的所有其他元素。

example:

image.png

当react check到新的树的某一个root element的类型不同，那么react会直接删除div，unmount Counter组件，然后创建新的span，并且构建新的ounter instance。

那么组件的lifecycle的执行顺序是：

老Counter组件的componentWillUnmount调用
新Counter组件的constructor调用
新Counter组件的getDerivedStateFromProps调用
新Counter组件的第一次render调用
新Counter组件的componentDidMount调用

React Component Element

Same class/function Component

如果新旧DOM Tree的root component的类型完全相同，那么react只会更新当前的component element的instance，让当前的root component进入Updating阶段

example:

// old


// new

React check新旧component element都是Counter，这时候当前的counter组件的生命周期方法会按照顺序触发

getDerivedStateFromProps()
shouldComponentUpdate()
render()
getSnapshotBeforeUpdate()
componentDidUpdate()

Diff算法处理列表

react处理列表并没有什么特殊，但是对于不同的情况，可能和你想象的顺序不同，比如对于下面这些情况：

在列表的尾部插入新的元素

react首先check root element ul，发现type和属性均没有改变，因此依次diff所有子节点

，发现有新的子节点

3

，就会创建

在列表的头部插入新的元素

react首先check root element ul，发现type和属性均没有改变，因此依次diff所有子节点

。
diff第一个li，发现其子元素text发生了改变1 ---> 3，因此之后要update这个元素

diff第二个li，发现其子元素text发生了改变2 ---> 1，因此之后要update这个元素

由于第三个li，以前并不存在，因此创建新的元素

2

这流程似乎和我们想象的直接创建新的

3

不一样，因此如果在列表的头部插入元素，可能会导致performance变差。

因此为了解决此类列表问题，react引入了key属性。

使用key

对于像这种list这样的组件，他们通常都使用一样的DOM type以及类似的属性和结构。

react在没有特别的设置下，会按照顺序从左向右依次diff list中的每一个元素，因此对于list头部插入元素的情况，会导致list中的每一个元素都被更新。

为了提高list的diff效率，react期待我们给每一个list item都加上一个id，也就是key，让react在diff中这些非常相似的item时，尝试按照key去diff。

也就是key相同的元素，react就默认这个元素就是之前的那个元素，只需要check是否有改变的属性，只进行Update。对于新的key值，直接创建新的元素。

example

// old


    1
    2


// new 

    3
    1
    2

对于上面这种情况，react发现key='1'以及key='2'元素完全没变属性也没变，因此不做任何update，而只是创建一个新的

3

为什么最好不要使用array的index作为key值？

case1

在原数组的头部加入一个新的元素

// old


    {[1,2].map((value,index) => {value})}


// new 



    {[3,1,2].map((value,index) => {value})}

如果原数组的头部加了3，那么diff流程和不加key完全一样，所有元素都需要被update，并且创建新的元素

2

case2

从原数组的中间删除一个元素。

// old


    {[1,2,3].map((value,index) => {
        return (
            
                {value}
                
            
        )
    })}


// new 



    {[1,3].map((value,index) => {
        return (
            
                {value}
                
            
        )
    })}

对于这种情况，react diff的流程：

diff第一个元素1没问题，属性不变不更新。
diff第二个元素3的时候，发现他的key是1，react惊喜的发现以前就一个key是1的元素，那么就把以前的2元素更新成3吧，其他部分比如input部分没有任何属性改变，那就不更新吧。
发现新树不再存在key是2的元素，于是将以前的3元素直接删除

你本来期待的是让react把中间的元素删除，但是react只是在原来的基础上更新了第二个元素，而删除了第三个元素。这时候会造成，其他本来和元素2配套的组件（比如input），现在变成了和元素3配套，本应该和元素3配套的组件被删除了。