为啥 vue3 不必要地重新渲染 v-for 中的节点？

Posted 2023-02-22

【中文标题】为啥 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。我没有看到任何这样的指南，有吗？