为什么 vue3 不必要在 v-for 中重新渲染节点?
Why vue3 unnecessary re-renders nodes in v-for?
这是我做的一个小测试,用于调查 vue3 中列表的不必要节点重新渲染(vue2 具有相同的行为):https://kasheftin.github.io/vue3-rerender/. That's the source code: https://github.com/Kasheftin/vue3-rerender/tree/master.
我试图理解为什么在某些情况下 vue 会重新渲染 v-for 中已经渲染过的节点。我知道(并将在下面提供)一些避免重新渲染的技术,但对我来说理解理论至关重要。
为了测试,我添加了一个虚拟的 v-test 指令,它只在触发 mounted/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 store。它工作正常 - 尽管 item prop 是一个对象,但没有不必要的重新渲染。
测试 5
<RerenderNumberStore v-for="item in items" :key="item.id" :item="{ id: item.id, name: item.name }" />
与测试 4 相同,但项目道具已重组 - 我们得到了不必要的重新渲染。
测试 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 不同的任何原因。这个对我来说不太清楚 - 当新项目添加到项目数组时,计算的项目不会以任何方式改变。它 returns 相同的对象。它必须被缓存,与以前的值匹配并且不触发 DOM.
中的任何更新
Vue 是一个反应式系统,因此,要回答这个问题,应该了解可缓存的可观察对象是如何工作的以及它们的粒度是多少。所以,请耐心等待。
假设您有一个昂贵的功能,例如
getCurrentTotal() { return state.x + state.y; }
并且它没有副作用,即对于相同的 x
和 y
结果完全相同,我们永远不需要再次调用它,除非其中一个值发生变化。
为了启用观察,你会想出一些像
这样的包装器
const state = reactive({x:1,y:2,z:3})
此包装器将创建一个观察者地图:
--- initial state ---
x -> []
y -> []
z -> []
(这张地图“存在”在哪里或以什么形式并不重要,有很多策略)
它还会创建一个结果缓存。
当你的函数第一次被调用时(又名“dry 运行”),每个 access 反应 state
对象被记住,观察者地图更新为:
--- after first run of getCurrentTotal() ---
x -> [getCurrentTotal]
y -> [getCurrentTotal]
z -> []
结果缓存将得到getCurrentTotal,{x:1, y:2} -> 3
(简化)。
现在,如果你做类似的事情
state.x++
state.x
的 setter 会发现它需要再次 运行 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。但是对于密集 table 的 100x100 单元格,您的树中将有 10k 个对象,作为 Vue 的用户,您将永远无法优化它。
虽然您的问题感觉像是发现错误,但它实际上是一种强大的机制,可让您精确控制更新的粒度。 Memory/speed 权衡之类的东西。
Test3(或 Test5)失败有更深层次的原因,但遵循相同的思路:每次迭代都创建新对象并在重新渲染期间对它们调用深度等于,这在现实生活中太昂贵了。将它们作为单独的道具传递,如 Test4,你会没事的。
如果您认为在干 运行 期间每个项目都必须 运行 整个项目集合,那么测试 6 很容易解释,因此,每个呈现的依赖关系图 RerenderNumberStoreById
由列表中的每一项组成。
这是我做的一个小测试,用于调查 vue3 中列表的不必要节点重新渲染(vue2 具有相同的行为):https://kasheftin.github.io/vue3-rerender/. That's the source code: https://github.com/Kasheftin/vue3-rerender/tree/master.
我试图理解为什么在某些情况下 vue 会重新渲染 v-for 中已经渲染过的节点。我知道(并将在下面提供)一些避免重新渲染的技术,但对我来说理解理论至关重要。
为了测试,我添加了一个虚拟的 v-test 指令,它只在触发 mounted/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 store。它工作正常 - 尽管 item prop 是一个对象,但没有不必要的重新渲染。
测试 5
<RerenderNumberStore v-for="item in items" :key="item.id" :item="{ id: item.id, name: item.name }" />
与测试 4 相同,但项目道具已重组 - 我们得到了不必要的重新渲染。
测试 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 不同的任何原因。这个对我来说不太清楚 - 当新项目添加到项目数组时,计算的项目不会以任何方式改变。它 returns 相同的对象。它必须被缓存,与以前的值匹配并且不触发 DOM.
中的任何更新Vue 是一个反应式系统,因此,要回答这个问题,应该了解可缓存的可观察对象是如何工作的以及它们的粒度是多少。所以,请耐心等待。
假设您有一个昂贵的功能,例如
getCurrentTotal() { return state.x + state.y; }
并且它没有副作用,即对于相同的 x
和 y
结果完全相同,我们永远不需要再次调用它,除非其中一个值发生变化。
为了启用观察,你会想出一些像
这样的包装器const state = reactive({x:1,y:2,z:3})
此包装器将创建一个观察者地图:
--- initial state ---
x -> []
y -> []
z -> []
(这张地图“存在”在哪里或以什么形式并不重要,有很多策略)
它还会创建一个结果缓存。
当你的函数第一次被调用时(又名“dry 运行”),每个 access 反应 state
对象被记住,观察者地图更新为:
--- after first run of getCurrentTotal() ---
x -> [getCurrentTotal]
y -> [getCurrentTotal]
z -> []
结果缓存将得到getCurrentTotal,{x:1, y:2} -> 3
(简化)。
现在,如果你做类似的事情
state.x++
state.x
的 setter 会发现它需要再次 运行 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。但是对于密集 table 的 100x100 单元格,您的树中将有 10k 个对象,作为 Vue 的用户,您将永远无法优化它。
虽然您的问题感觉像是发现错误,但它实际上是一种强大的机制,可让您精确控制更新的粒度。 Memory/speed 权衡之类的东西。
Test3(或 Test5)失败有更深层次的原因,但遵循相同的思路:每次迭代都创建新对象并在重新渲染期间对它们调用深度等于,这在现实生活中太昂贵了。将它们作为单独的道具传递,如 Test4,你会没事的。
如果您认为在干 运行 期间每个项目都必须 运行 整个项目集合,那么测试 6 很容易解释,因此,每个呈现的依赖关系图 RerenderNumberStoreById
由列表中的每一项组成。