Vue源码实现之watcher拾遗
目录
1. Watcher构造函数参数options和渲染watcher标志位
2. watcher收集的新老依赖deps和newDeps的作用
3. watcher中getter的目的就是去touch目标数据以触发依赖收集
4. Watcher设置依赖收集标志时为什么要pushTarget和popTarget
这篇文章是紧跟着《Vue源码分析基础之响应式原理》的一篇文章。如果刚开始接触vue源码的童鞋，推荐先看完上面一篇文章，这样理解起来可能会轻松点。
1. Watcher构造函数参数options和渲染watcher标志位
vue源码的watcher实现和我们《Vue源码分析基础之响应式原理》分析的思路大致差不多，但是具体实现细节上会有不少的差异，所以下面会做一些补充性的分析。
这里我们先看下watcher类的构造函数
export default class Watcher {
constructor(
vm: Component,
expOrFn: string | Function,
cb: Function,
options?: ?Object,
isRenderWatcher?: boolean
) {
this.vm = vm;
if (isRenderWatcher) {
vm._watcher = this;
}
vm._watchers.push(this);
// options
if (options) {
this.deep = !!options.deep;
this.lazy = !!options.lazy;
this.sync = !!options.sync;
...
}
// options
...
this.cb = cb;
this.deps = [];
this.newDeps = [];
this.depIds = new Set();
this.newDepIds = new Set();
// parse expression for getter
if (typeof expOrFn === "function") {
this.getter = expOrFn;
} else {
this.getter = parsePath(expOrFn);
if (!this.getter) {
this.getter = noop;
}
}
this.value = this.lazy ? undefined : this.get();
}
}
首先，我们来分析下构造函数的参数参数比我们《Vue源码分析基础之响应式原理》构建的watcher多了两个：
- options：一些控制选项，比如我们写vue组件代码的watch时，可以额外提供deep选项来对监控对象的深层属性的修改进行监控
- isRenderWatcher: 渲染watcher标志位。什么是渲染watcher？它是我们vue系统中用到的三种watcher(计算属性watcher，渲染watcher，组件watch钩子开启的watcher，我会在后面的文章对这些watchers进行分析)中的其中一种，它会在组件挂载时进行创建并将getter设置为组件更新函数updateComponent，且每个组件都会有且只有一个渲染watcher，该watcher创建开始收集依赖时，data中所有属性的dep.subs都会存入这个watcher订阅，一旦我们写的data里面的数据状态发生变化，即会触发watcher的update->run->get->getter->updateComponent->render|patch来更新真实DOM。同时，我们会将每个组件的渲染watcher放到vm._watcher上，以便forceUpdate组件时可以直接触发watcher的更新。
2. watcher收集的新老依赖deps和newDeps的作用
这里跟着需要提一提的是deps和newDeps，因为每次数据更新时vue都会触发渲染watcher进而调用到render来重新构建虚拟dom，构建虚拟dom时需要解析模板中绑定的数据的变化，从而为模板中用到的这些data中的属性建立起watcher的依赖订阅。但是新的页面因为已经发生了变化，很有可能在之前我们模板中用到了某个data中的属性，但更新后的模板不再用这个属性了，那么我们就需要将渲染watcher从该属性的dep.subs中删除，否则就会造成修改该属性时依然触发页面重新渲染的bug。
比如下面的模板代码
<template>
<div>
<div v-if="show">Hello world</div>
<div @click="show = !show">toggle</div>
</div>
</template>
假如当前show为true，那么在点击toggle的时候，show会被改成false，从而导致了依赖show变量的渲染watcher的update方法的运行来重新构建虚拟DOM和更新真实DOM，期间show自身的dep.subs原来是有watcher的订阅在里面的，这时我们就需要将其移除掉了。
而watcher上面的deps和newDeps要做的就是这些事情。
- deps：上一次通过这个watcher进行依赖收集时所收集到的所有依赖集合。以渲染watcher为例，比如你这个页面现在用到了两个data中的属性，那么这两个属性对应的dep都会被这个watcher订阅，同时，这个两个dep都会放到watcher.deps下面
- newDeps：本次这个watcher记性依赖收集时收集到的所有依赖集合。沿用上面的举例，比如这一次你的页面通过v-if之类的指令取消掉了对其中一个data的属性的引用，这时你的watcher.newDeps就只会有其中个属性的dep
- 结果：那么通过对上面的deps和newDeps一比较，我们就知道应该将取消页面引用的那个data属性的dep.subs的watcher给移除掉，以便产生前面说的bug了
那么newDeps是什么时候产生的呢？当然是在依赖收集的时候了。
在watcher收集依赖的时候，会触发自身的get方法，关键的代码如下
// observer/watcher.js文件
get() {
pushTarget(this)
let value = this.getter.call(vm, vm)
popTarget()
this.cleanupDeps()
return value
}
// observer/dep.js文件
export function pushTarget(target: ?Watcher) {
targetStack.push(target)
Dep.target = target
}
get方法首先做的就是调用pushTarget来将watcher自身推入到targetStack里面，然后和以前分析的那样设置全局的Dep.target为watcher自身。这里为什么要用pushTarget，我们下面会另外起个小节来分析，这里我们就认为它仅仅是设置了Dep.target就行了。
跟着调用getter去触发依赖的收集，这样当某个被obeserved的data的属性被读取(touch)的时候，就会触发该属性自身对应的依赖对象dep的depend方法来进行依赖收集。
// observer/index.js文件
function defineReactive(data, key, val = data[key]) {
const dep = new Dep()
let childOb = observe(val)
Object.defineProperty(data, key, {
// getter
get() {
if (Dep.target) {
dep.depend()
}
return val
},
});
}
// observer/dep.js文件
depend() {
if (Dep.target) {
Dep.target.addDep(this)
}
}
最终进入到watcher的addDep中
addDep(dep: Dep) {
const id = dep.id
if (!this.newDepIds.has(id)) {
this.newDepIds.add(id)
this.newDeps.push(dep)
if (!this.depIds.has(id)) {
dep.addSub(this)
}
}
}
从中我们将上面defineReactive中对应属性的dep加入到了这个watcher的newDeps，同时将自己加入了该dep的subs中，实现了依赖的收集。
但这并没有完。这里还只是走完了get方法的getter调用，get方法后面还调用了一个cleanupDeps的方法，而该方法的作用，就是我们上面说的将以前依赖某个data属性的watcher，从该属性的dep.subs中移除，然后形成该watcher所依赖的所有属性的dep组成的最新的deps，并保存到watcher.deps中
cleanupDeps() {
let i = this.deps.length
while (i--) {
const dep = this.deps[i]
if (!this.newDepIds.has(dep.id)) {
dep.removeSub(this)
}
}
let tmp = this.depIds
this.depIds = this.newDepIds
this.newDepIds = tmp
this.newDepIds.clear()
tmp = this.deps
this.deps = this.newDeps
this.newDeps = tmp
this.newDeps.length = 0
}
3. watcher中getter的目的就是去touch目标数据以触发依赖收集
跟着要看下的就是构造函数中对getter的操作。
// parse expression for getter
if (typeof expOrFn === "function") {
this.getter = expOrFn;
} else {
this.getter = parsePath(expOrFn);
if (!this.getter) {
this.getter = noop;
}
}
我们知道watcher中的getter的作用是去取得被监控数据具体的属性，通常是在构造函数调用get方法时去调用下getter，从而读取下这个属性，因为此前对这个对象进行了observe(data)，所以一旦我们读取了这个属性，那么get方法设置了Dep.target的标识位的情况下就会触发依赖收集。
这就是构造函数传入的expOrFn是"count.total"这种形式的数据的情况。
但是expOrFn也可能是个函数，比如我们刚才说的渲染watcher初始化时传入的就是updateComponent这个方法。
这个时候构造函数发现你传入的是个函数，它就会直接将这个方法赋值给getter。这样在跟着调用的get，然后触发getter时，就是直接调用到这个函数。比如updateComponent方法，开始去调用渲染函数从新生成虚拟DOM，期间touch到所有页面引用的data数据，触发依赖收集。
所以本质上来说，该getter的作用和上面的情况是一致的，也就是说，getter存在的目的就是为了去touch下目标监控数据，从而触发对这些数据的依赖的收集！
4. Watcher设置依赖收集标志时为什么要pushTarget和popTarget
正如我们前面看到的，在vue的源代码中，开启依赖收集标志和关闭依赖收集标志并不是直接操作Dep.target的赋值，而是通过pushTarget和popTarget来做的
// observer/dep.js文件
export function pushTarget(target: ?Watcher) {
targetStack.push(target)
Dep.target = target
}
export function popTarget() {
targetStack.pop()
Dep.target = targetStack[targetStack.length - 1]
}
首先，代码字面意义没有什么不好理解的，就是pushTarget的时候将当前watcher推入到栈中，并将该watcher设置成Dep.target。popTarget的时候从栈顶pop一个watcher出来并将其设置到Dep.target。
问题是why？
其实这里主要是要解决依赖收集的嵌套的问题。
这里我能想到的一个应用场景是在计算属性watcher中，计算属性初始话时会调用initComputed方法。关键代码如下:
const computedWatcherOptions = { lazy: true }
function initComputed(vm: Component, computed: Object) {
...
const watchers = vm._computedWatchers = Object.create(null)
for (const key in computed) {
const userDef = computed[key];
watchers[key] = new Watcher(
vm,
getter || noop,
noop,
computedWatcherOptions
);
if (!(key in vm)) {
defineComputed(vm, key, userDef);
}
}
}
首先以用户自定义的computed函数作为getter创建watcher并放到vm的_computedWatchers数组下。但因为设置了lazy为tru，所以watcher构造时默认不会自动调用getter来立刻更新计算属性，而是等到如页面{{计算属性}}使用时再触发下面的computeGetter来触发更新，可以参考上面watcher的构造函数对lazy的判断部分：
this.value = this.lazy ? undefined : this.get();
跟着为我们定义的每个计算属性调用defineComputed方法
export function defineComputed(
target: any,
key: string,
userDef: Object | Function
) {
const shouldCache = !isServerRendering()
if (typeof userDef === 'function') {
sharedPropertyDefinition.get = shouldCache
? createComputedGetter(key)
: createGetterInvoker(userDef)
sharedPropertyDefinition.set = noop
} else {
sharedPropertyDefinition.get = userDef.get
? shouldCache && userDef.cache !== false
? createComputedGetter(key)
: createGetterInvoker(userDef.get)
: noop
sharedPropertyDefinition.set = userDef.set || noop
}
if (process.env.NODE_ENV !== 'production' &&
sharedPropertyDefinition.set === noop) {
sharedPropertyDefinition.set = function () {
warn(
`Computed property "${key}" was assigned to but it has no setter.`,
this
)
}
}
Object.defineProperty(target, key, sharedPropertyDefinition)
}
这个方法主要的目的是将用户自定义计算属性挂到vm上面，以便页面通过{{计算属性}}直接访问。然后将该计算属性的getter定义为computedGetter，这样一来，在页面等访问{{计算属性}}时该函数将调用_computedWatchers对应的watcher的getter来重新计算属性并触发所依赖属性的依赖收集。
该computedGetter会在什么时候被触发呢？
在组件渲染watcher执行updateComponent时。因为render渲染函数需要读取页面引用到的data属性和computed计算属性来生成虚拟dom。
此时Dep.target是该组件的渲染watcher，栈顶也是该渲染watcher。这个需要记一下，我们下面需要用。
跟着，我们看下计算属性被访问时触发的computedGetter具体是怎么实现的:
function createComputedGetter(key) {
return function computedGetter() {
const watcher = this._computedWatchers && this._computedWatchers[key]
...
watcher.evaluate()
...
watcher.depend()
return watcher.value
}
}
首先从vm中拿到我们上面创建的这个计算属性对应的watcher，然后执行evaludate
evaluate() {
this.value = this.get()
this.dirty = false
}
很明显，evaluate就是执行下watcher的get方法，进而触发我们自定义的计算属性方法，如果该方法使用了data属性，则会针对这个watcher开始对这些属性进行依赖收集。比如下面的自定义计算属性就依赖了data中的属性counter，所以counter的dep.subs会收集这个计算属性watcher到其囊中。
computed: {
twiceCounter: function() {
return this.counter * 2
}
}
但是，这里要注意了，在执行get方法时，里面首先会做一个pushTarget。
记得此前Dep.target是谁吧？本组件的渲染watcher。这时你要对计算属性watcher做依赖收集（即看下我们自定义计算属性的方法体里面用了哪些data属性，将watcher自身加入到这些属性的dep.subs中），所以就会将计算属性watcher压栈，将Dep.target设置成自身，这样所依赖的属性的dep.subs收集到的才是计算属性watcher，好让该属性改变时自动触发计算属性的更新。
完了后，popTarget，计算属性watcher出栈，此时栈顶又变为组件的渲染watcher，同时设置为Dep.target。
为什么呢？因为createComputedGetter紧跟着执行的watcher.depend()需要用到本组件的渲染watcher。
// observer/watcher.js文件
depend() {
let i = this.deps.length
while (i--) {
this.deps[i].depend()
}
}
注意这里的this是计算属性watcher，而this.deps指的是该计算属性watcher所有收集到的依赖，比如由data多个属性的dep所组成，同时，这时Dep.target是组件的渲染watcher而非计算属性watcher。
那么这个方法所实现的逻辑就是，让组件渲染watcher订阅所有该计算属性watcher收集到的依赖。
也就是说，一旦这个计算属性所依赖的某个data属性修改了，将首先会通知计算属性watcher来将计算属性进行更新，然后通知渲染watcher来重新渲染整个组件。
而这，也就是为什么需要pushTarget/popTarget以及targetStack的原因，如前面所说，主要为了解决依赖收集过程中的嵌套问题。即在收集渲染watcher得依赖过程中，发现需要先收集计算属性watcher的依赖，这时就要将渲染watcher先压栈，把栈顶和Dep.target留给计算属性watcher，等计算属性watcher收集完依赖后，再恢复现场，把组件渲染watcher置顶，并设置Dep.target，以完成渲染watcher后续的依赖收集动作。
我是@天地会珠海分舵，「青葱日历」和「三日清单」 作者。能力一般，水平有限，觉得我说的还有那么点道理的不妨点个赞关注下！