vue中使用v-for时为啥不能用index作为key?
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了vue中使用v-for时为啥不能用index作为key?相关的知识,希望对你有一定的参考价值。
参考技术AVue 和 React 都实现了一套虚拟DOM,使我们可以不直接操作DOM元素,只操作数据便可以重新渲染页面。而隐藏在背后的原理便是其高效的Diff算法。
Vue 和 React 的虚拟DOM的Diff算法大致相同,其核心是基于两个简单的假设:
基于以上这两点假设,使得虚拟DOM的Diff算法的复杂度从O(n^3)降到了O(n)。
用一张图简单说明一下:
当页面的数据发生变化时,Diff算法只会比较同一层级的节点:
如果节点类型不同,直接干掉前面的节点,再创建并插入新的节点。
如果节点类型相同,则会重新设置该节点的属性,从而实现节点的更新。
举个栗子:
我们希望可以在B和C之间加一个F,Diff算法默认执行起来是这样的:
即把C更新成F,D更新成C,E更新成D,最后再插入E,这样效率不高,且性能不够好。
但是,如果使用key来给每个节点做一个唯一标识,Diff算法就可以正确的识别此节点,找到正确的位置区插入新的节点。
总而言之,key的作用主要是为了高效的更新虚拟DOM 。另外vue中在使用相同标签名元素的过渡切换时,也会使用到key属性,其目的也是为了让vue可以区分它们,否则vue只会替换其内部属性而不会触发过渡效果。
这里,也建议尽可能在使用 v-for 时提供 key attribute,除非遍历输出的 DOM 内容非常简单。
举个栗子:
此时,删除 “Person4” 是正常的,但是如果我删除 “Person2” 就会出现问题。
删除前
如果此时 list 的 item 是 select 的选项,其中 Person3 是选中的,这个时候 Person2 被删除了,用 index 作为 key 就会变成是 Person4 选中的了,这就产生了bug。
如果使用唯一id作为key,删除 Person2 后,剩下的元素因为与 key 的关系没有发生变化,都不会被重新渲染,从而达到提升性能的目的。此时,list 的 item 作为 select 的选项,也不会出现上面所描述的bug。
之所以会产生bug是因为‘就地复用’策略
就地复用官方的解释 :
这句话比较难理解, 看下面这个例子:
首先输入框, 文本, 按钮是写在一个div里面
在"就地复用"策略中, 点击按钮, 输入框不随文本一起下移, 是因为输入框没有与数据(data)绑定, 所以vuejs默认使用已经渲染的dom, 然而文本是与数据绑定的, 所以文本被重新渲染. 这种处理方式在vue或者angularjs中都是默认的列表渲染策略, 因为高效.
这种"就地复用"一般在"列表展示"的场景中不会出现问题, 所以我的建议是 : 如果你的列表元素存在与用户交互的场景(比如form表单或者重新排序等), 那么请你为 v-for指令设置key参数,key指向列表中每个元素的唯一值.
官方解释:
参考:
https://blog.csdn.net/aihuanhuan110/article/details/98223011
https://www.zhihu.com/question/61078310
为啥 vue3 不必要地重新渲染 v-for 中的节点?
【中文标题】为啥 vue3 不必要地重新渲染 v-for 中的节点?【英文标题】:Why vue3 unnecessary re-renders nodes in v-for?为什么 vue3 不必要地重新渲染 v-for 中的节点? 【发布时间】:2021-03-31 12:32:02 【问题描述】:这是我为调查 vue3 中列表的不必要节点重新渲染而进行的一个小测试(vue2 具有相同的行为):https://kasheftin.github.io/vue3-rerender/。这是源代码:https://github.com/Kasheftin/vue3-rerender/tree/master。
我试图理解为什么 vue 在某些情况下会重新渲染 v-for 中已经渲染的节点。我知道(并将在下面提供)一些避免重新渲染的技术,但对我来说,理解理论至关重要。
对于测试,我添加了一个虚拟 v-test 指令,该指令仅在触发 mount/beforeUnmount 挂钩时记录。
测试 1
<div v-for="i in n" :key="i">
<div> i </div>
<div v-test="log2"> log(i) </div>
</div>
结果:当 n 增加时,所有节点都重新渲染。为什么?如何避免?
测试 2
Test2.vue:
<RerenderNumber v-for="i in n" :key="i" :i="i" />
RerenderNumber.vue:
<template>
<div v-test="log2"> log() </div>
</template>
结果:它工作正常。将内部内容从 test1 移动到单独的组件可以解决此问题。为什么?
测试 3
<RerenderObject v-for="i in n" :key="i" :test=" i: i: i " />
结果:不必要的重新渲染。在将对象发送到某个子组件之前,似乎不允许在循环中动态构造对象,可能是因为 JavaScript 中的 !=
。
测试 4
<template>
<RerenderNumberStore v-for="item in items" :key="item.id" :item="item" />
</template>
<script>
export default
computed:
items ()
return this.$store.state.items
,
methods:
addItem ()
this.$store.commit('addItem', id: this.items.length, name: `Item $this.items.length` )
</script>
这里使用了最简单的 vuex 存储。它工作正常 - 尽管 item prop 是一个对象,但没有不必要的重新渲染。
测试 5
<RerenderNumberStore v-for="item in items" :key="item.id" :item=" id: item.id, name: item.name " />
与测试 4 相同,但重新构建了 item 道具 - 我们得到了不必要的重新渲染。
测试 6
Test6.vue:
<RerenderNumberStoreById v-for="item in items" :key="item.id" :item-id="item.id" />
RerenderNumberStoreById.vue:
<template>
<div v-test="log"> item.name </div>
</template>
<script>
export default
props: ['itemId'],
computed:
item () return this.$store.state.items.find(item => item.id === this.itemId)
</script>
结果:不必要的重新渲染。为什么?我找不到行为与测试 4 不同的任何原因。这对我来说不太清楚 - 当新项目添加到 items 数组时,计算的项目不会以任何方式更改。它返回相同的对象。它必须被缓存,与之前的值匹配,并且不会触发 DOM 中的任何更新。
【问题讨论】:
【参考方案1】:Vue 是一个反应式系统,因此,要回答这个问题,我们应该了解可缓存的 observables 是如何工作的,以及它们的粒度是多少。所以,请多多包涵。
假设你有一个昂贵的功能,例如
getCurrentTotal() return state.x + state.y;
并且它没有副作用,即对于相同的x
和y
,结果完全相同,我们无需再次调用它,除非其中任何一个值发生变化。
要启用观察,你会想出一些类似的包装器
const state = reactive(x:1,y:2,z:3)
这个包装器会创建一个观察者地图:
--- initial state ---
x -> []
y -> []
z -> []
(无论这张地图“生活”在哪里或以何种形式存在,都有很多策略)
它还会创建结果缓存。
当您的函数第一次被调用(又名“试运行”)时,每次访问 响应式state
对象都会被记住,并且观察者的地图会更新为: p>
--- after first run of getCurrentTotal() ---
x -> [getCurrentTotal]
y -> [getCurrentTotal]
z -> []
结果缓存将获得getCurrentTotal,x:1, y:2 -> 3
(简化)。
现在,如果你做类似的事情
state.x++
state.x
的设置器会发现它需要再次运行 getCurrentTotal()
,因为 x:2, y:2
不在缓存中,等等,你有一个更新。
现在,TLDR:
在您的第一个示例 Test1 中,可观察函数是整个 for 循环:
observedRenderer1()
for i in n:
add or modify (if :key exists) a div and inside put all the stuff
注意,n
中的任何更改都会调用它,并将遍历整个循环。这里没有捷径。
在您的第二个示例 Test2 中,
observedRenderer2()
for i in n:
callSomeOtherRenderer(i)
啊哈!循环仍然存在。但是现在我们的工作单元更加细化了。反应式系统检查它的缓存,如果它已经有这些结果,则不会调用 RerenderNumber(1)
或 RenderNumber(2)
的渲染器。
现实情况要复杂一些,Vue 将所有结果的副本保存在 Virtual DOM 中(不要与 Shadow DOM 混淆!)其中保存了足够的信息来了解shouldComponentUpdate
与否。是的,可以在虚拟树中为循环迭代中的每个 div 创建一个 VNode。但是对于 100x100 单元格的密集表,您的树中将有 10k 个对象,作为 Vue 的用户,您将永远无法优化它。
虽然您的问题感觉像是发现了一个错误,但它实际上是一种强大的机制,可让您精确控制更新的粒度。内存/速度权衡之类的东西。
Test3(或 Test5)失败的更深层次的原因是相同的:每次迭代都在创建新对象,并且在重新渲染期间对它们调用 deep equals 在现实生活中过于昂贵。将它们作为单独的道具(如 Test4)传递,你会没事的。
如果您认为在试运行期间每个项目都必须运行整个项目集合,那么测试 6 很容易解释,因此,每个呈现的 RerenderNumberStoreById
的依赖关系图由列表中的每个项目组成。
【讨论】:
感谢您的精彩解释。我们可以以某种方式将其转换为指南吗?出现的下一个问题是如何避免重新渲染。基本上,我们在商店中有一些 items[],一些迭代 ItemEntry 的 ItemList 组件,最后一个不应该使用任何 getter(下界功能,itemById: (state) => (itemId) => state.items.find( item => item.id === itemId), 也不是 map, itemByIds: (state) => state.items.reduce((out, item) => out[item.id] = item; return out, ))。但是我们可以在 ItemList 中使用 getter。我没有看到任何这样的指南,有吗?以上是关于vue中使用v-for时为啥不能用index作为key?的主要内容,如果未能解决你的问题,请参考以下文章