我是靠谱客的博主 微笑楼房,最近开发中收集的这篇文章主要介绍React Diff原理深入分析,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

在了解Diff前,先看下React的虚拟DOM的结构

这是html结构

<div id="father">
  <p class="child">I am child p</p>
  <div class="child">I am child div</div>
</div>

这是React渲染html时的js代码   自己可以在babel上试试

React.createElement("div", {id: "father"}, 
    React.createElement("p", {class: "child"}, "I am child p"),             
    React.createElement("div", {class: "child"}, "I am child div")
);

由此可以看出这是一个树结构

React在调用render方法时会创建一颗树(简称pre),在下一次调用render方法时会返回一颗不同的树(简称cur)。React就会比较pre和cur这两棵树之间的差别来判断如何高效的更新UI,保证当前UI与最新的树cur保持同步。

为了高效更新UI,React在以下两个假设的基础上提出了一套O(n)的启发算法:

1.两个不同类型的元素会产生出不同的树;

2.开发者可以通过设置 key 属性,来告知渲染哪些子元素在不同的渲染下可以保存不变;

Diffing 算法

逐层比较

在对比两棵树时,React是逐层进行比较的,只会对相同颜色框内的DOM节点进行比较。

首先比较两棵树的根节点,不同类型的根节点会有不同的形态。当根节点为不同类型的元素时,React 会拆卸原有的树并且建立起新的树。举个例子,当一个元素从 <a> 变成 <img>,从 <Article> 变成 <Comment>,或从 <Button> 变成 <div> 都会触发一个完整的重建流程。

//before
<div>
    <App/>
</div>
//after
<p>
    <App/>
</p>

React会销毁App组件(该组件的子组件也全都销毁),并且重新创建一个新的App组件(也包括App的子组件)。

如下的DOM结构转换:

React只会简单的考虑同层节点的位置变换,对于不同层的节点,只有简单的创建和删除。当根节点发现子节点中A不见了,就会直接销毁A;而当D发现自己多了一个子节点A,则会创建一个新的A作为子节点。因此对于这种结构的转变的实际操作是:

A.destroy();
A = new A();
A.append(new B());
A.append(new C());
D.append(A);

虽然看上去这样的算法有些“简陋”,但是其基于的是第一个假设:两个不同类型的元素会产生出不同的树。根据React官方文档,这一假设至今为止没有导致严重的性能问题。这当然也给我们一个提示,在实现自己的组件时,保持稳定的DOM结构会有助于性能的提升。例如,我们有时可以通过CSS隐藏或显示某些节点,而不是真的移除或添加DOM节点。

对比同类型的组件元素

当一个组件更新时,组件实例会保持不变,但是state或props中数据的变化会调用render从而改变该组件中的子元素进行更新。 

对比同一类型的元素

当对比两个相同类型的 React 元素时,React 会保留 DOM 节点,仅比对及更新有改变的属性。

<div className="before" title="stuff" />

<div className="after" title="stuff" />

React将div的className由before修改为after(类似于React中更新state的合并操作)。

对子节点进行递归

默认情况下(逐层比较),当递归 DOM 节点的子元素时,React 会同时遍历两个子元素的列表;当产生差异时,生成一个 mutation(突变)。

所以在列表末尾新增元素时,更新开销比较小。例如:

<ul>
  <li>first</li>
  <li>second</li>
</ul>

<ul>
  <li>first</li>
  <li>second</li>
  <li>third</li>
</ul>

React 会先匹配两个 <li>first</li> 对应的树,然后匹配第二个元素 <li>second</li> 对应的树,最后插入第三个元素的 <li>third</li> 树。

如果只是简单的将新增元素插入到表头,那么更新开销会比较大。比如:

<ul>
  <li>Duke</li>
  <li>Villanova</li>
</ul>

<ul>
  <li>Connecticut</li>
  <li>Duke</li>
  <li>Villanova</li>
</ul>

React 并不会意识到应该保留 <li>Duke</li> 和 <li>Villanova</li>,而是会重建每一个子元素。这种情况会带来性能问题。

Keys

为了解决上述问题,React 引入了 key 属性。当子元素拥有 key 时,React 使用 key 来匹配原有树上的子元素以及最新树上的子元素。以下示例在新增 key 之后,使得树的转换效率得以提高:

<ul>
  <li key="2015">Duke</li>
  <li key="2016">Villanova</li>
</ul>

<ul>
  <li key="2014">Connecticut</li>
  <li key="2015">Duke</li>
  <li key="2016">Villanova</li>
</ul>

现在 React 知道只有带着 '2014' key 的元素是新元素,带着 '2015' 以及 '2016' key 的元素仅仅移动了。所以只是创建了 key=2014的元素,并不会创建剩下的两个元素。

所以key的取值最好不要使用数组的下标,因为数组的顺序可能会发生变化,最好使用自身数据携带的唯一标识(id或是其它的属性)。

1. 虚拟DOM中key的作用:
                    1). 简单的说: key是虚拟DOM对象的标识, 在更新显示时key起着极其重要的作用。

                    2). 详细的说: 当状态中的数据发生变化时,react会根据【新数据】生成【新的虚拟DOM】,  随后React进行【新虚拟DOM】与【旧虚拟DOM】的diff比较,比较规则如下:

                                    a. 旧虚拟DOM中找到了与新虚拟DOM相同的key:
                                                (1).若虚拟DOM中内容没变, 直接使用之前的真实DOM
                                                (2).若虚拟DOM中内容变了, 则生成新的真实DOM,随后替换掉页面中之前的真实DOM

                                    b. 旧虚拟DOM中未找到与新虚拟DOM相同的key
                                                根据数据创建新的真实DOM,随后渲染到到页面

2. 用index作为key可能会引发的问题:
                                1. 若对数据进行:逆序添加、逆序删除等破坏顺序操作:
                                                会产生没有必要的真实DOM更新 ==> 界面效果没问题, 但效率低。

                                2. 如果结构中还包含输入类的DOM:
                                                会产生错误DOM更新 ==> 界面有问题。                                                
                                3. 注意!如果不存在对数据的逆序添加、逆序删除等破坏顺序操作,
                                        仅用于渲染列表用于展示,使用index作为key是没有问题的。

以上就是React Diff原理深入分析的详细内容,更多关于React Diff原理的资料请关注靠谱客其它相关文章!

最后

以上就是微笑楼房为你收集整理的React Diff原理深入分析的全部内容,希望文章能够帮你解决React Diff原理深入分析所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(116)

评论列表共有 0 条评论

立即
投稿
返回
顶部