Kas*_*tin 4 rendering vue.js virtual-dom vuejs3
这是我为了调查 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>
Run Code Online (Sandbox Code Playgroud)
结果:当n增加时,所有节点都重新渲染。为什么?如何避免这种情况?
测试2
Test2.vue:
<RerenderNumber v-for="i in n" :key="i" :i="i" />
RerenderNumber.vue:
<template>
<div v-test="log2">{{ log() }}</div>
</template>
Run Code Online (Sandbox Code Playgroud)
结果:工作正常。将内部内容从 test1 移动到单独的组件可以解决此问题。为什么?
测试3
<RerenderObject v-for="i in n" :key="i" :test="{ i: { i: { i } } }" />
Run Code Online (Sandbox Code Playgroud)
结果:不必要的重新渲染。似乎不允许在将对象发送到某个子组件之前在循环中动态构造对象,可能是因为{} != {}在 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>
Run Code Online (Sandbox Code Playgroud)
这里使用的是最简单的vuex store。它工作正常 - 尽管 item prop 是一个对象,但没有不必要的重新渲染。
测试5
<RerenderNumberStore v-for="item in items" :key="item.id" :item="{ id: item.id, name: item.name }" />
Run Code Online (Sandbox Code Playgroud)
与测试 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>
Run Code Online (Sandbox Code Playgroud)
结果:不必要的重新渲染。为什么?我找不到行为与测试 4 不同的任何原因。这对我来说不太清楚 - 当新项目添加到项目数组时,计算的项目不会以任何方式更改。它返回相同的对象。它必须被缓存,与之前的值匹配,并且不会触发 DOM 中的任何更新。
Vue 是一个反应式系统,因此,要回答这个问题,我们应该了解可缓存可观察量的工作原理以及它们的粒度是什么。所以,请耐心听我说。
\n想象一下你有一个昂贵的功能,例如
\ngetCurrentTotal() { return state.x + state.y; }\nRun Code Online (Sandbox Code Playgroud)\n并且它没有副作用,即相同的x结果y是完全相同的,并且我们永远不需要再次调用它,除非任何一个值发生变化。
为了能够观察,你会想出一些包装器,比如
\nconst state = reactive({x:1,y:2,z:3})\nRun Code Online (Sandbox Code Playgroud)\n该包装器将创建观察者地图:
\n--- initial state ---\nx -> []\ny -> []\nz -> []\nRun Code Online (Sandbox Code Playgroud)\n(这张地图“生活”在哪里或者以什么形式存在并不重要,有很多策略)
\n它还将创建结果缓存。
\n当你的函数第一次被调用时(又名“空运行”),每次访问反应式state都会被记住,并且观察者的映射会更新为:
--- after first run of getCurrentTotal() ---\nx -> [getCurrentTotal]\ny -> [getCurrentTotal]\nz -> []\nRun Code Online (Sandbox Code Playgroud)\n结果的缓存将得到getCurrentTotal,{x:1, y:2} -> 3(简化)。
现在,如果你做类似的事情
\nstate.x++\nRun Code Online (Sandbox Code Playgroud)\nsetter forstate.x会发现它需要getCurrentTotal()再次运行,因为{x:2, y:2}不在缓存中,et voil\xc3\xa0,你有一个更新。
现在,TLDR:
\n在第一个示例 Test1 中,可观察函数是整个 for 循环:
\nobservedRenderer1() {\n for i in n: \n add or modify (if :key exists) a div and inside put all the stuff\n} \nRun Code Online (Sandbox Code Playgroud)\n请注意,它将在任何更改时被调用n,并将经历整个循环。这里没有捷径。
在你的第二个示例 Test2 中,
\nobservedRenderer2() {\n for i in n: \n callSomeOtherRenderer(i)\n} \nRun Code Online (Sandbox Code Playgroud)\n啊哈!循环仍然存在。但现在我们的工作单元更加细化。反应式系统检查其缓存,并且不会调用渲染器RerenderNumber(1),或者RenderNumber(2)是否已经有这些结果。
现实情况有点复杂,Vue 在 Virtual DOM 中保留所有结果的副本(不要与 Shadow DOM 混淆!),其中保留了足够的信息来判断shouldComponentUpdate是否知道。是的,可以在虚拟树中为循环迭代中的每个 div 创建一个 VNode。但是,对于 100x100 单元格的密集表,您的树中将有 10k 个对象,并且作为 Vue 用户,您将永远无法优化它。
虽然您的问题感觉像是发现了错误,但它实际上是一种强大的机制,可以让您精确控制更新的粒度。内存/速度权衡之类的事情。
\nTest3(或 Test5)由于更深层次的原因而失败,但同样的思路:每次迭代都创建新对象,并在重新渲染期间对它们调用深度 equals 在现实生活中代价太高。像 Test4 一样将它们作为单独的 props 传递,你会没事的。
\n如果您认为在试运行期间每个项目必须运行整个项目集合,则测试 6 很容易解释,因此,每个渲染的依赖关系图RerenderNumberStoreById由列表中的每个项目组成。
| 归档时间: |
|
| 查看次数: |
1497 次 |
| 最近记录: |