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处理列表并没有什么特殊,但是对于不同的情况,可能和你想象的顺序不同,比如对于下面这些情况:

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

// old

  • 1
  • 2
  • 1
  • 2
  • 3

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

  • ,发现有新的子节点
  • 3
  • ,就会创建

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

    // old
    
    
    • 1
    • 2
    • 3
    • 1
    • 2

    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 (
      ) })}
    // new
      {[1,3].map((value,index) => { return (
      ) })}

    对于这种情况,react diff的流程:

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

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

    你可能感兴趣的:(React Reconciliation)