vue源码解析computed多次访问会有死循环原理

正文

在上一篇中，我们仿vue源码自己实现了一个computed。

写了如下的测试代码。

    const { reactive, effect, ref, computed } = Vue
      const obj = reactive({
        name: '张三'
      })
      // C1
      const computedObj = computed(() => {
        console.log('computed')
        return '姓名：' + obj.name
      })
      // e1
      effect(() => {
        document.querySelector('#app').innerHTML = computedObj.value
        document.querySelector('#app').innerHTML = computedObj.value
      })
      setTimeout(() => {
        obj.name = '李四'
      }, 2000)

我们发现computed多次访问的时候，会出现死循环。

为什么会有死循环

这个问题出在哪了呢？

我们先看一下这段代码的执行情况。（当时看源码，我也是理了好几遍，才理出头绪。有条件的话，还是建议clone代码自己调试一遍）

我们直接看effect。

1.先执行effect函数，设置activeEffect为传进来的参数，也就是挂载dom的这个函数，我们把这个函数就叫e1。

//叫e1
() => {
   document.querySelector('#app').innerHTML = computedObj.value
   document.querySelector('#app').innerHTML = computedObj.value
}

2.执行e1函数

第一次执行computedObj.value，此时会执行如下代码。

先是收集依赖，将e1收集起来；

【此时，key为computedObj， activeEffect为e1】

因为此时，_dirty是true，所以会执行computed计算函数。

执行effect.run,也就是下面这段逻辑，我们把这个函数叫做c1

// 叫c1
() => {
  console.log('con')
  return '姓名：' + obj.name
}

执行obj.name 触发reactive的get，将C1收集起来。

【此时，key为obj, activeEffect被改为C1】

3 第二次执行computedObj.value

依旧会触发一次依赖收集。

【此时，key为computedObj， activeEffect已经被改为为C1了】

此时_dirty为false,则不会执行计算。

effct执行完毕，此时computedObj有两个依赖，分别是e1和c1。obj上有一个依赖，为c1

4.在2秒后，触发obj.name的set事件，则触发obj上的依赖函数，开始遍历执行。

注意，因为computed中使用了scheduler,所以此时的c1。

所以会执行如下代码

    this.effect = new ReactiveEffect(getter, () => {
      // 判断当前脏的状态，如果为 false，表示需要《触发依赖》
      if (!this._dirty) {
        // 将脏置为 true，表示
        this._dirty = true
        triggerRefValue(this)
      }
    })

5.执行triggerRefValue(this)

triggerRefValue(this)会触发computedObj上的依赖。

此时dirty = true， 并遍历执行e1，c1依赖函数。

  for (const effect of effects) {
     triggerEffect(effect)
  }

6.当执行e1函数时，又会触发computed.get，并将e1加入依赖。

此时【key为computedObj， activeEffect为e1】

由于此时，_dirty是true，则又会执行run,重新计算。

此时【key为， activeEffect为c1】

7.当执行c1时，因为之前e1函数已经将_dirty改为false了，于是又会开始执行triggerRefValue(this)，遍历computedObj上的依赖c1和e1。

因为此时computedObj依旧是有e1和c1两个依赖，又会重新回到第5步，造成死循环。

如何解决死循环

那找到了问题，如何解决呢？

其实方法也很简单，在第6步的时候，我们只要确保让c1先执行，e1后执行就行，

先执行c1时，因为此时dirty是true,所以不会重复执行triggerRefValue(this)。

然后再执行e1,添加依赖。

vue源码也是这么实现的，先把computed的依赖执行完，然后再执行其他依赖。

这也就是为什么，vue源码中触发依赖，有两次遍历。

export function triggerEffects(
  dep: Dep | ReactiveEffect[],
  debuggerEventExtraInfo?: DebuggerEventExtraInfo
) {
  // spread into array for stabilization
  const effects = isArray(dep) ? dep : [...dep]
  for (const effect of effects) {
    if (effect.computed) {
      triggerEffect(effect, debuggerEventExtraInfo)
    }
  }
  for (const effect of effects) {
    if (!effect.computed) {
      triggerEffect(effect, debuggerEventExtraInfo)
    }
  }
}

总结

不管是数据的响应式，还是computed的实现，亦或是vue组件的更新。

本质都是通过effec侦听器来实现的。

对于effec有几点要理解清楚。

1.activeEffect是会不断变化的，这就导致，同样的代码，可能收集到的依赖函数是不一样的。

比如上文的computedObj对象，两次收集得依赖就是不同的，因为第二次没有计算函数的执行。

2.设置了scheduler，再次触发的时候，执行函数就变成了scheduler。

比如上文收集的依赖函数c1。

到这里，effet应该有比较深入的认识了，下一篇再讲讲如何通过effec侦听器来控制更新的时机，来实现组件更新。

以上就是vue源码解析computed多次访问会有死循环原理的详细内容，更多关于vue computed多次访问死循环的资料请关注脚本之家其它相关文章！