关于vue.js:了解Vue中computed的缓存实现原理

本文围绕上面这个例子，解说一下computed初始化及更新时的流程，来看看计算属性是怎么实现的缓存，及依赖是怎么被收集的。

<div id="app">  <span @click="change">{{sum}}</span></div><script src="./vue2.6.js"></script><script>  new Vue({    el: "#app",    data() {      return {        count: 1,      }    },    methods: {      change() {        this.count = 2      },    },    computed: {      sum() {        return this.count + 1      },    },  })</script>

初始化 computed

vue初始化时先执行init办法，外面的initState会进行计算属性的初始化

if (opts.computed) {initComputed(vm, opts.computed);}

上面是initComputed的代码

var watchers = vm._computedWatchers = Object.create(null); // 顺次为每个 computed 属性定义一个计算watcherfor (const key in computed) {  const userDef = computed[key]  watchers[key] = new Watcher(      vm, // 实例      getter, // 用户传入的求值函数 sum      noop, // 回调函数 能够先漠视      { lazy: true } // 申明 lazy 属性 标记 computed watcher  )  // 用户在调用 this.sum 的时候，会产生的事件  defineComputed(vm, key, userDef)}

每个计算属性对应的计算watcher的初始状态如下：

{    deps: [],    dirty: true,    getter: ƒ sum(),    lazy: true,    value: undefined}

能够看到它的 value 刚开始是 undefined，lazy 是 true，阐明它的值是惰性计算的，只有到真正在模板里去读取它的值后才会计算。

这个 dirty 属性其实是缓存的要害，先记住它。

接下来看看比拟要害的 defineComputed，它决定了用户在读取 this.sum 这个计算属性的值后会产生什么，持续简化，排除掉一些不影响流程的逻辑。

Object.defineProperty(target, key, {     get() {        // 从刚刚说过的组件实例上拿到 computed watcher        const watcher = this._computedWatchers && this._computedWatchers[key]        if (watcher) {          // 只有dirty了才会从新求值          if (watcher.dirty) {            // 这里会求值，会调用get，会设置Dep.target            watcher.evaluate()          }          // 这里也是个要害 等会细讲          if (Dep.target) {            watcher.depend()          }          // 最初返回计算出来的值          return watcher.value        }    }})

这个函数须要认真看看，它做了好几件事，咱们以初始化的流程来解说它：

首先 dirty 这个概念代表脏数据，阐明这个数据须要从新调用用户传入的 sum 函数来求值了。咱们暂且不论更新时候的逻辑，第一次在模板中读取到 {{sum}} 的时候它肯定是 true，所以初始化就会经验一次求值。

evaluate () {  // 调用 get 函数求值  this.value = this.get()  // 把 dirty 标记为 false  this.dirty = false}

这个函数其实很清晰，它先求值，而后把 dirty 置为 false。

再回头看看咱们刚刚那段 Object.defineProperty 的逻辑，

下次没有非凡状况再读取到 sum 的时候，发现 dirty是false了，是不是间接就返回 watcher.value 这个值就能够了，这其实就是计算属性缓存的概念。

更新

初始化的流程讲完了，置信大家也对 dirty 和缓存有了个大略的概念（如果没有，再认真回头看一看）。

接下来就讲更新的流程，细化到本文的例子中，也就是 count 的更新到底是怎么触发 sum 在页面上的变更。

首先回到刚刚提到的 evalute 函数里，也就是读取 sum 时发现是脏数据的时候做的求值操作。

evaluate () {  // 调用 get 函数求值  this.value = this.get()  // 把 dirty 标记为 false  this.dirty = false}

Dep.target

computed初始化求值执行this.get()时，此时全局的 Dep.target 应该是渲染watcher，targetStack 是 [渲染watcher]，进去就 pushTarget，也就是把计算watcher 本身置为 Dep.target，期待收集依赖。
执行完 pushTarget(this) 后，此时的 Dep.target是计算watcher，targetStack 是[渲染watcher，计算watcher]。

getter函数执行时，会读取this.count的值，留神它是一个响应式的属性，会触发count的getter。

// 在闭包中，会保留对于 count 这个 key 所定义的 depconst dep = new Dep() // 闭包中也会保留上一次 set 函数所设置的 vallet val Object.defineProperty(obj, key, {  get: function reactiveGetter () {    const value = val    // Dep.target 此时就是计算watcher    if (Dep.target) {      // 收集依赖      dep.depend()    }    return value  },})

此时，count会收集计算watcher作为依赖。

// dep.depend()depend () {  if (Dep.target) {    Dep.target.addDep(this)  }}

// watcher 的 addDep函数addDep (dep: Dep) {  // 这里做了一系列的去重操作 简化掉     // 这里会把 count 的 dep 也存在本身的 deps 上  this.deps.push(dep)  // 又带着 watcher 本身作为参数  // 回到 dep 的 addSub 函数了  dep.addSub(this)}

class Dep {  subs = []   addSub (sub: Watcher) {    this.subs.push(sub)  }}

通过这两段代码，计算watcher就被属性所绑定dep所收集。watcher依赖dep，dep同时也依赖watcher，它们之间的这种相互依赖的数据结构，能够不便晓得一个watcher被哪些dep依赖和一个dep依赖了哪些watcher。

经验了这样的一个收集的流程后，此时的一些状态：

{    deps: [ count的dep ],    dirty: false, // 求值完了 所以是false    value: 2, // 1 + 1 = 2    getter: ƒ sum(),    lazy: true}

count的dep:

{    subs: [ sum的计算watcher ]}

此时求值完结，回到计算watcher 的 getter 函数，继续执行popTarget()，计算watcher出栈，Dep.target 变更为渲染watcher，接着执行watcher.depend()

// watcher.dependdepend () {  let i = this.deps.length  while (i--) {    this.deps[i].depend()  }}

还记得刚刚的计算watcher 的状态吗？它的 deps 里保留了 count 的 dep。

也就是说，又会调用 count 上的 dep.depend()

class Dep {  subs = []    depend () {    if (Dep.target) {      Dep.target.addDep(this)    }  }}

这次的 Dep.target 曾经是渲染watcher 了，所以这个 count 的 dep 又会把渲染watcher 寄存进本身的 subs 中。

count的dep:

{    subs: [ sum的计算watcher，渲染watcher ]}

那么来到了此题的重点，这时候 count 更新了，是如何去触发视图更新的呢？

再回到 count 的响应式劫持逻辑里去：

// 在闭包中，会保留对于 count 这个 key 所定义的 depconst dep = new Dep() // 闭包中也会保留上一次 set 函数所设置的 vallet val Object.defineProperty(obj, key, {  set: function reactiveSetter (newVal) {      val = newVal      // 触发 count 的 dep 的 notify      dep.notify()    }  })})

好，这里触发了咱们刚刚精心筹备的 count 的 dep 的 notify 函数，感觉离胜利越来越近了。

class Dep {  subs = []    notify () {    for (let i = 0, l = subs.length; i < l; i++) {      subs[i].update()    }  }}

这里的逻辑就很简略了，把 subs 里保留的 watcher 顺次去调用它们的 update 办法，也就是

调用计算watcher 的 update
调用渲染watcher 的 update

计算watcher 的 update

update () {  if (this.lazy) {    this.dirty = true  }}

wtf，就这么一句话…… 没错，就仅仅是把计算watcher 的 dirty 属性置为 true，静静的期待下次读取即可。

渲染watcher 的 update

这里其实就是调用 vm._update(vm._render()) 这个函数，从新依据 render 函数生成的 vnode 去渲染视图了。

而在 render 的过程中，肯定会拜访到 sum 这个值，那么又回回到 sum 定义的 get 上：

Object.defineProperty(target, key, {     get() {        const watcher = this._computedWatchers && this._computedWatchers[key]        if (watcher) {          // 上一步中 dirty 曾经置为 true, 所以会从新求值          if (watcher.dirty) {            watcher.evaluate()          }          if (Dep.target) {            watcher.depend()          }          // 最初返回计算出来的值          return watcher.value        }    }})

因为上一步中的响应式属性更新，触发了计算 watcher 的 dirty 更新为 true。所以又会从新调用用户传入的 sum 函数计算出最新的值，页面上天然也就显示出了最新的值。

至此为止，整个计算属性更新的流程就完结了。