Vue 中的 key 是用来做什么的?为什么不推荐使用 index 作为 key?常常听说这样的问题,本篇文章带你从原理来一探究竟。
以这样一个列表为例:
<ul> <li>1</li> <li>2</li> </ul> 复制代码
那么它的 vnode
也就是虚拟 dom 节点大概是这样的。
{ tag: 'ul', children: [ { tag: 'li', children: [ { vnode: { text: '1' }}] }, { tag: 'li', children: [ { vnode: { text: '2' }}] }, ] } 复制代码
假设更新以后,我们把子节点的顺序调换了一下:
{ tag: 'ul', children: [ + { tag: 'li', children: [ { vnode: { text: '2' }}] }, + { tag: 'li', children: [ { vnode: { text: '1' }}] }, ] } 复制代码
很显然,这里的 children
部分是我们本文 diff
算法要讲的重点(敲黑板)。
首先响应式数据更新后,触发了 渲染 Watcher
的回调函数 vm._update(vm._render())
去驱动视图更新,
vm._render()
其实生成的就是 vnode
,而 vm._update
就会带着新的 vnode
去走触发 __patch__
过程。
我们直接进入 ul
这个 vnode
的 patch
过程。
对比新旧节点是否是相同类型的节点:
isSameNode
为false的话,直接销毁旧的 vnode
,渲染新的 vnode
。这也解释了为什么 diff
是同层对比。
ul
,进入👈)。会调用src/core/vdom/patch.js
下的patchVNode
方法。
就直接调用浏览器的 dom api
把节点的直接替换掉文字内容就好。
说明是新增 children,直接 addVnodes
添加新子节点。
说明是删除 children,直接 removeVnodes
删除旧子节点
li 子节点列表
,进入👈)那么就是我们 diff算法
想要考察的最核心的点了,也就是新旧节点的 diff
过程。
通过
// 旧首节点 let oldStartIdx = 0 // 新首节点 let newStartIdx = 0 // 旧尾节点 let oldEndIdx = oldCh.length - 1 // 新尾节点 let newEndIdx = newCh.length - 1 复制代码
这些变量分别指向旧节点的首尾
、新节点的首尾
。
根据这些指针,在一个 while
循环中不停的对新旧节点的两端的进行对比,直到没有节点可以对比。
在讲对比过程之前,要讲一个比较重要的函数:sameVnode
:
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) ) ) ) } 复制代码
它是用来判断节点是否可用的关键函数,可以看到,判断是否是 sameVnode
,传递给节点的 key
是关键。
然后我们接着进入 diff
过程,每一轮都是同样的对比,其中某一项命中了,就递归的进入 patchVnode
针对单个 vnode
进行的过程(如果这个 vnode
又有 children
,那么还会来到这个 diff children
的过程 ):
旧首节点和新首节点用 sameNode
对比。
旧尾节点和新首节点用 sameNode
对比
旧首节点和新尾节点用 sameNode
对比
旧尾节点和新尾节点用 sameNode
对比
如果以上逻辑都匹配不到,再把所有旧子节点的 key
做一个映射表,然后用新 vnode
的 key
去找出在旧节点中可以复用的位置。
然后不停的把匹配到的指针向内部收缩,直到新旧节点有一端的指针相遇(说明这个端的节点都被patch过了)。
在指针相遇以后,还有两种比较特殊的情况:
有新节点需要加入。
如果更新完以后,oldStartIdx > oldEndIdx
,说明旧节点都被 patch
完了,但是有可能还有新的节点没有被处理到。接着会去判断是否要新增子节点。
有旧节点需要删除。
如果新节点先patch完了,那么此时会走 newStartIdx > newEndIdx
的逻辑,那么就会去删除多余的旧子节点。
假设我们有这样的一段代码:
<div id="app"> <ul> <item :key="index" v-for="(num, index) in nums" :num="num" :class="`item${num}`" ></item> </ul> <button @click="change">改变</button> </div> <script src="./vue.js"></script> <script> var vm = new Vue({ name: "parent", el: "#app", data: { nums: [1, 2, 3] }, methods: { change() { this.nums.reverse(); } }, components: { item: { props: ["num"], template: ` <div> {{num}} </div> `, name: "child" } } }); </script> 复制代码
其实是一个很简单的列表组件,渲染出来 1 2 3
三个数字。我们先以 index
作为key,来跟踪一下它的更新。
我们接下来只关注 item
列表节点的更新,在首次渲染的时候,我们的虚拟节点列表 oldChildren
粗略表示是这样的:
[ { tag: "item", key: 0, props: { num: 1 } }, { tag: "item", key: 1, props: { num: 2 } }, { tag: "item", key: 2, props: { num: 3 } } ]; 复制代码
在我们点击按钮的时候,会对数组做 reverse
的操作。那么我们此时生成的 newChildren
列表是这样的:
[ { tag: "item", key: 0, props: { + num: 3 } }, { tag: "item", key: 1, props: { + num: 2 } }, { tag: "item", key: 2, props: { + num: 1 } } ]; 复制代码
发现什么问题没有?key的顺序没变,传入的值完全变了。这会导致一个什么问题?
本来按照最合理的逻辑来说,旧的第一个vnode
是应该直接完全复用 新的第三个vnode
的,因为它们本来就应该是同一个vnode,自然所有的属性都是相同的。
但是在进行子节点的 diff
过程中,会在 旧首节点和新首节点用
sameNode对比。
这一步命中逻辑,因为现在新旧两次首部节点
的 key
都是 0
了,
然后把旧的节点中的第一个 vnode
和 新的节点中的第一个 vnode
进行 patchVnode
操作。
这会发生什么呢?我可以大致给你列一下:
首先,正如我之前的文章props的更新如何触发重渲染?里所说,在进行 patchVnode
的时候,会去检查 props
有没有变更,如果有的话,会通过 _props.num = 3
这样的逻辑去更新这个响应式的值,触发 dep.notify
,触发子组件视图的重新渲染等一套很重的逻辑。
然后,还会额外的触发以下几个钩子,假设我们的组件上定义了一些dom的属性或者类名、样式、指令,那么都会被全量的更新。
而这些所有重量级的操作(虚拟dom发明的其中一个目的不就是为了减少真实dom的操作么?),都可以通过直接复用 第三个vnode
来避免,是因为我们偷懒写了 index
作为 key
,而导致所有的优化失效了。
<item :key="Math.random()" v-for="(num, index) in nums" :num="num" :class="`item${num}`" /> 复制代码
其实我听过一种说法,既然官方要求一个 唯一的key
,是不是可以用 Math.random()
作为 key
来偷懒?这是一个很鸡贼的想法,看看会发生什么吧。
首先 oldVnode
是这样的:
[ { tag: "item", key: 0.6330715699108844, props: { num: 1 } }, { tag: "item", key: 0.25104533240710514, props: { num: 2 } }, { tag: "item", key: 0.4114769152411637, props: { num: 3 } } ]; 复制代码
更新以后是:
[ { tag: "item", + key: 0.11046018699748683, props: { + num: 3 } }, { tag: "item", + key: 0.8549799545696619, props: { + num: 2 } }, { tag: "item", + key: 0.18674467938937478, props: { + num: 1 } } ]; 复制代码
可以看到,key
变成了完全全新的 3 个随机数。
上面说到,diff
子节点的首尾对比如果都没有命中,就会进入 key
的详细对比过程,简单来说,就是利用旧节点的 key -> index
的关系建立一个 map
映射表,然后用新节点的 key
去匹配,如果没找到的话,就会调用 createElm
方法 重新建立 一个新节点。
具体代码在这:
// 建立旧节点的 key -> index 映射表 oldKeyToIdx = createKeyToOldIdx(oldCh, oldStartIdx, oldEndIdx); // 去映射表里找可以复用的 index idxInOld = findIdxInOld(newStartVnode, oldCh, oldStartIdx, oldEndIdx); // 一定是找不到的,因为新节点的 key 是随机生成的。 if (isUndef(idxInOld)) { // 完全通过 vnode 新建一个真实的子节点 createElm(); } 复制代码
也就是说,咱们的这个更新过程可以这样描述:
123
-> 前面重新创建三个子组件 -> 321123
-> 删除、销毁后面三个子组件 -> 321
。
发现问题了吧?这是毁灭性的灾难,创建新的组件和销毁组件的成本你们晓得的伐……本来仅仅是对组件移动位置就可以完成的更新,被我们毁成这样了。
经过这样的一段旅行,diff
这个庞大的过程就结束了。
我们收获了什么?
用组件唯一的 id
(一般由后端返回)作为它的 key
,实在没有的情况下,可以在获取到列表的时候通过某种规则为它们创建一个 key
,并保证这个 key
在组件整个生命周期中都保持稳定。
别用 index
作为 key
,和没写基本上没区别,因为不管你数组的顺序怎么颠倒,index 都是 0, 1, 2
这样排列,导致 Vue 会复用错误的旧子节点,做很多额外的工作。
千万别用随机数作为 key
,不然旧节点会被全部删掉,新节点重新创建,你的老板会被你气死。