共计 4339 个字符,预计需要花费 11 分钟才能阅读完成。
本文围绕上面这个例子,解说一下 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 属性定义一个计算 watcher
for (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 所定义的 dep
const dep = new Dep()
// 闭包中也会保留上一次 set 函数所设置的 val
let 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.depend
depend () {
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 所定义的 dep
const dep = new Dep()
// 闭包中也会保留上一次 set 函数所设置的 val
let 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 函数计算出最新的值,页面上天然也就显示出了最新的值。
至此为止,整个计算属性更新的流程就完结了。