解密Vue中key的神奇原理:优化列表渲染效率的关键策略!

简介: 欢迎来到前端入门之旅!

⭐  专栏简介


       欢迎来到前端入门之旅!这个专栏是为那些对Web开发感兴趣、刚刚开始学习前端的读者们打造的。无论你是初学者还是有一些基础的开发者,我们都会在这里为你提供一个系统而又亲切的学习平台。我们以问答形式更新,为大家呈现精选的前端知识点和最佳实践。通过深入浅出的解释概念,并提供实际案例和练习,让你逐步建立起一个扎实的基础。无论是HTML、CSS、JavaScript还是最新的前端框架和工具,我们都将为你提供丰富的内容和实用技巧,帮助你更好地理解并运用前端开发中的各种技术。


       同时,我们也会关注最新的前端趋势和发展动态。随着Web技术的不断演进,前端开发也在不断推陈出新。我们会及时介绍最新的前端框架、工具和技术,使你能够站在前沿,与时俱进。通过掌握最新的前端技术,你将能够在竞争激烈的Web开发领域中有更大的竞争力。


📘  文章引言


一、Key是什么

开始之前,我们先还原两个实际工作场景


当我们在使用v-for时,需要给单元加上key

<ul>
    <li v-for="item in items" :key="item.id">...</li>
</ul>


用+new Date()生成的时间戳作为key,手动强制触发重新渲染

<Comp :key="+new Date()" />


那么这背后的逻辑是什么,key的作用又是什么?


一句话来讲


key是给每一个vnode的唯一id,也是diff的一种优化策略,可以根据key,更准确, 更快的找到对应的vnode节点


场景背后的逻辑


当我们在使用v-for时,需要给单元加上key


如果不用key,Vue会采用就地复地原则:最小化element的移动,并且会尝试尽最大程度在同适当的地方对相同类型的element,做patch或者reuse。


如果使用了key,Vue会根据keys的顺序记录element,曾经拥有了key的element如果不再出现的话,会被直接remove或者destoryed


用+new Date()生成的时间戳作为key,手动强制触发重新渲染


当拥有新值的rerender作为key时,拥有了新key的Comp出现了,那么旧key Comp会被移除,新key Comp触发渲染


二、设置key与不设置key区别


举个例子:


创建一个实例,2秒后往items数组插入数据


<body>
  <div id="demo">
    <p v-for="item in items" :key="item">{{item}}</p>
  </div>
  <script src="../../dist/vue.js"></script>
  <script>
    // 创建实例
    const app = new Vue({
      el: '#demo',
      data: { items: ['a', 'b', 'c', 'd', 'e'] },
      mounted () {
        setTimeout(() => { 
          this.items.splice(2, 0, 'f')  // 
       }, 2000);
     },
   });
  </script>
</body>


在不使用key的情况,vue会进行这样的操作:


分析下整体流程:


比较A,A,相同类型的节点,进行patch,但数据相同,不发生dom操作

比较B,B,相同类型的节点,进行patch,但数据相同,不发生dom操作

比较C,F,相同类型的节点,进行patch,数据不同,发生dom操作

比较D,C,相同类型的节点,进行patch,数据不同,发生dom操作

比较E,D,相同类型的节点,进行patch,数据不同,发生dom操作

循环结束,将E插入到DOM中

一共发生了3次更新,1次插入操作


在使用key的情况:vue会进行这样的操作:


比较A,A,相同类型的节点,进行patch,但数据相同,不发生dom操作

比较B,B,相同类型的节点,进行patch,但数据相同,不发生dom操作

比较C,F,不相同类型的节点

比较E、E,相同类型的节点,进行patch,但数据相同,不发生dom操作

比较D、D,相同类型的节点,进行patch,但数据相同,不发生dom操作

比较C、C,相同类型的节点,进行patch,但数据相同,不发生dom操作

循环结束,将F插入到C之前

一共发生了0次更新,1次插入操作


通过上面两个小例子,可见设置key能够大大减少对页面的DOM操作,提高了diff效率


设置key值一定能提高diff效率吗?


其实不然,文档中也明确表示


当 Vue.js 用 v-for 正在更新已渲染过的元素列表时,它默认用“就地复用”策略。如果数据项的顺序被改变,Vue 将不会移动 DOM 元素来匹配数据项的顺序, 而是简单复用此处每个元素,并且确保它在特定索引下显示已被渲染过的每个元素


这个默认的模式是高效的,但是只适用于不依赖子组件状态或临时 DOM 状态 (例如:表单输入值) 的列表渲染输出


建议尽可能在使用 v-for 时提供 key,除非遍历输出的 DOM 内容非常简单,或者是刻意依赖默认行为以获取性能上的提升


三、原理分析


这里判断是否为同一个key,首先判断的是key值是否相等如果没有设置key,那么key为undefined,这时候undefined是恒等于undefined


function sameVnode (a, b) {
    return (
        a.key === b.key && (
            (
                a.tag === b.tag &&
                a.isComment === b.isComment &&
                isDef(a.data) === isDef(b.data) &&
                sameInputType(a, b)
            ) || (
                isTrue(a.isAsyncPlaceholder) &&
                a.asyncFactory === b.asyncFactory &&
                isUndef(b.asyncFactory.error)
            )
        )
    )
}


updateChildren方法中会对新旧vnode进行diff,然后将比对出的结果用来更新真实的DOM


function updateChildren (parentElm, oldCh, newCh, insertedVnodeQueue, removeOnly) {
    ...
    while (oldStartIdx <= oldEndIdx && newStartIdx <= newEndIdx) {
        if (isUndef(oldStartVnode)) {
            ...
        } else if (isUndef(oldEndVnode)) {
            ...
        } else if (sameVnode(oldStartVnode, newStartVnode)) {
            ...
        } else if (sameVnode(oldEndVnode, newEndVnode)) {
            ...
        } else if (sameVnode(oldStartVnode, newEndVnode)) { // Vnode moved right
            ...
        } else if (sameVnode(oldEndVnode, newStartVnode)) { // Vnode moved left
            ...
        } else {
            if (isUndef(oldKeyToIdx)) oldKeyToIdx = createKeyToOldIdx(oldCh, oldStartIdx, oldEndIdx)
            idxInOld = isDef(newStartVnode.key)
                ? oldKeyToIdx[newStartVnode.key]
                : findIdxInOld(newStartVnode, oldCh, oldStartIdx, oldEndIdx)
            if (isUndef(idxInOld)) { // New element
                createElm(newStartVnode, insertedVnodeQueue, parentElm, oldStartVnode.elm, false, newCh, newStartIdx)
            } else {
                vnodeToMove = oldCh[idxInOld]
                if (sameVnode(vnodeToMove, newStartVnode)) {
                    patchVnode(vnodeToMove, newStartVnode, insertedVnodeQueue, newCh, newStartIdx)
                    oldCh[idxInOld] = undefined
                    canMove && nodeOps.insertBefore(parentElm, vnodeToMove.elm, oldStartVnode.elm)
                } else {
                    // same key but different element. treat as new element
                    createElm(newStartVnode, insertedVnodeQueue, parentElm, oldStartVnode.elm, false, newCh, newStartIdx)
                }
            }
            newStartVnode = newCh[++newStartIdx]
        }
    }
    ...
    }


⭐  写在最后


请大家不吝赐教,在下方评论或者私信我,十分感谢🙏🙏🙏.


✅ 认为我某个部分的设计过于繁琐,有更加简单或者更高逼格的封装方式


✅ 认为我部分代码过于老旧,可以提供新的API或最新语法


✅ 对于文章中部分内容不理解


✅ 解答我文章中一些疑问


✅ 认为某些交互,功能需要优化,发现BUG


✅ 想要添加新功能,对于整体的设计,外观有更好的建议


最后感谢各位的耐心观看,既然都到这了,点个 👍赞再走吧!

相关文章
|
2月前
|
缓存 监控 JavaScript
如何优化 Vue 的执行流程?
【10月更文挑战第2天】
105 59
|
25天前
|
缓存 监控 JavaScript
Vue.js 框架下的性能优化策略与实践
Vue.js 框架下的性能优化策略与实践
|
25天前
|
JavaScript 前端开发 API
介绍一下Vue中的响应式原理
介绍一下Vue中的响应式原理
27 1
|
28天前
|
监控 JavaScript 算法
深度剖析 Vue.js 响应式原理:从数据劫持到视图更新的全流程详解
本文深入解析Vue.js的响应式机制,从数据劫持到视图更新的全过程,详细讲解了其实现原理和运作流程。
|
1月前
|
JavaScript
Vue 双向数据绑定原理
Vue的双向数据绑定通过其核心的响应式系统实现,主要由Observer、Compiler和Watcher三个部分组成。Observer负责观察数据对象的所有属性,将其转换为getter和setter;Compiler解析模板指令,初始化视图并订阅数据变化;Watcher作为连接Observer和Compiler的桥梁,当数据变化时触发相应的更新操作。这种机制确保了数据模型与视图之间的自动同步。
|
1月前
|
缓存 JavaScript 搜索推荐
Vue SSR(服务端渲染)预渲染的工作原理
【10月更文挑战第23天】Vue SSR 预渲染通过一系列复杂的步骤和机制,实现了在服务器端生成静态 HTML 页面的目标。它为提升 Vue 应用的性能、SEO 效果以及用户体验提供了有力的支持。随着技术的不断发展,Vue SSR 预渲染技术也将不断完善和创新,以适应不断变化的互联网环境和用户需求。
74 9
|
25天前
|
JavaScript 前端开发 API
Vue.js响应式原理深度解析:从Vue 2到Vue 3的演进
Vue.js响应式原理深度解析:从Vue 2到Vue 3的演进
54 0
|
1月前
|
监控 JavaScript 前端开发
Vue 异步渲染
【10月更文挑战第23天】Vue 异步渲染是提高应用性能和用户体验的重要手段。通过理解异步渲染的原理和优化策略,我们可以更好地利用 Vue 的优势,开发出高效、流畅的前端应用。同时,在实际开发中,要注意数据一致性、性能监控和调试等问题,确保应用的稳定性和可靠性。
|
2月前
|
缓存 JavaScript UED
优化Vue的响应式性能
【10月更文挑战第13天】优化 Vue 的响应式性能是一个持续的过程,需要不断地探索和实践,以适应不断变化的应用需求和性能挑战。
38 2
|
2月前
|
JavaScript 算法 前端开发
深入剖析Vue中v-for的使用及index作为key的弊端
深入剖析Vue中v-for的使用及index作为key的弊端
39 2