源码学习VUE之Watcher
我们在前面推导过程中实现了一个简单版的watcher。这里面还有一些问题
class Watcher {
constructors(component, getter, cb){
this.cb = cb // 对应的回调函数,callback
this.getter = getter;
this.component = component; //这就是执行上下文
}
//收集依赖
get(){
Dep.target = this;
this.getter.call(this.component)
if (this.deep) {
traverse(value)
}
Dep.target = null;
}
update(){
this.cb()
}
}同步异步更新
所谓的同步更新是指当观察的主体改变时立刻触发更新。而实际开发中这种需求并不多，同一事件循环中可能需要改变好几次state状态，但视图view只需要根据最后一次计算结果同步渲染就行（react中的setState就是典型）。如果一直做同步更新无疑是个很大的性能损耗。
这就要求watcher在接收到更新通知时不能全都立刻执行callback。我们对代码做出相应调整
constructors(component, getter, cb, options){
this.cb = cb // 对应的回调函数,callback
this.getter = getter;
this.id = UUID() // 生成一个唯一id
this.sync = options.sync; //默认一般为false
this.vm = component; //这就是执行上下文
this.value = this.getter() // 这边既收集了依赖，又保存了旧的值
}
update(){
if(this.sync){ //如果是同步那就立刻执行回调
this.run();
}else{
// 否则把这次更新缓存起来
//但是就像上面说的，异步更新往往是同一事件循环中多次修改同一个值，
// 那么一个wather就会被缓存多次。因为需要一个id来判断一下，
queueWatcher(this)
}
}
run: function(){
//获取新的值
var newValue = this.getter();
this.cb.call(this.vm, newValue, this.value)
}这里的一个要注意的地方是，考虑到极限情况，如果正在更新队列中wather时，又塞入进来该怎么处理。因此，加入一个flushing来表示队列的更新状态。
如果加入的时候队列正在更新状态，这时候分两种情况：
- 这个watcher已经更新过， 就把这个watcher再放到当前执行的下一位，当前watcher处理完，立即处理这个最新的。
- 这个watcher还没有处理，就找到这个wather在队列中现有的位置，并再把新的放在后面。
let flushing = false;
let has = {}; // 简单用个对象保存一下wather是否已存在
function queueWatcher (watcher) {
const id = watcher.id
if (has[id] == null) {
has[id] = true // 如果之前没有，那么就塞进去吧，如果有了就不用管了
if (!flushing) {
queue.push(watcher)
} else {
let i = queue.length - 1
while (i > index && queue[i].id > watcher.id) {
i--
}
queue.splice(i + 1, 0, watcher)
}
// ... 等同一事件循环结束后再依次处理队列里的watcher。具体代码放到后面nexttick部分再说
}
}
}这么设计不无道理。我们之所以为了将wather放入队列中，就是为了较少不必要的操作。考虑如下代码
data: {
a: 1
},
computed: {
b: function(){
this.a + 1
}
}
methods: {
act: function(){
this.a = 2;
// do someting
this.a = 1
}
}在act操作中，我们先改变a，再把它变回来。我们理想状况下是a没变，b也不重新计算。这就要求，b的wather执行update的时候要拿到a最新的值来计算。这里就是1。如果队列中a的watehr已经更新过，那么就应该把后面的a的wather放到当前更新的wather后面，立即更新。这样可以保证后面的wather用到a是可以拿到最新的值。
同理，如果a的wather还没有更新，那么把新的a的wather放的之前的a的wather的下一位，也是为了保证后面的wather用到a是可以拿到最新的值。
computed
之所以把计算属性拿出爱单独讲，是因为
- 计算属性存在按需加载的情况
- 与render和$watcher相比，计算属性a可能依赖另一个计算属性b。
按需加载
所谓的按需计算顾名思义就是用到了才会计算，即调用了某个计算属性的get方法。在前面的方法中，我们在class Watcher的constructor中直接调用了getter方法收集依赖，这显然是不符合按需加载的原则的。
依赖收集
实际开发中，我们发现一个计算属性往往由另一个计算属性得来。如，
computed: {
a: function(){
return this.name;
},
b: function(){
return this.a + "123";
}
}对于a而言，它是b的依赖，因此有必要在a的wather执行update操作时也更新b，也就意味着，a的watcher里需要收集着b的依赖。而收集的时机是执行b的回调时，this.a调用了a的get方法的时候
在computed部分，已经对计算属性的get方法进行了改写
function computedGetter () {
const watcher = this._computedWatchers && this._computedWatchers[key]
if (watcher) {
//调用一个计算属性的get方法时，会在watcher中收集依赖。
watcher.depend()
return watcher.evaluate()
}
}我们再修改一下wather代码：
class Watcher {
constructors(component, getter, cb, options){
this.cb = cb
this.getter = getter;
this.id = UUID()
this.sync = options.sync;
this.vm = component;
if(options){
this.computed = options.computed //由于是对计算属性特殊处理，那肯定要给个标识符以便判断
}
this.dirty = this.computed // for computed watchers
this.value = this.lazy ? undefined : this.get();
}
update(){
if (this.lazy) {
this.dirty = true
} else if (this.sync) {
this.run()
} else {
queueWatcher(this)
}
}
run: function(){
//拿到新值
const value = this.get()
if (value !== this.value || //基本类型的值直接比较
// 对象没办法直接比较，因此都进行计算
isObject(value)) {
// set new value
const oldValue = this.value
this.value = value
this.dirty = false
cb.call(this.vm, value, oldValue)
}
}
// 新增depend方法，收集计算属性的依赖
depend () {
if (this.dep && Dep.target) {
this.dep.depend()
}
}
}
//不要忘了还要返回当前computed的最新的值
//由于可能不是立即更新的，因此根据dirty再判断一下，如果数据脏了，调用get再获取一下
evaluate () {
if (this.dirty) {
this.value = this.get()
this.dirty = false
}
return this.value
}在绑定依赖之前(computed的get被触发一次)，computed用到的data数据改变是不会触发computed的重新计算的。
路径解析
对于render和computed想要收集依赖，我们只需要执行一遍回调函数就行，但是对于$watch方法，我们并不关心他的回调是什么，而更关心我们需要监听哪个值。
这里的需求多种多样，
比如单个值监听，监听对象的某个属性（.），比如多个值混合监听(&&, ||）等。这就需要对监听的路径进行解析。
constructors(component, expOrFn, cb, options){
this.cb = cb
this.id = UUID()
this.sync = options.sync;
this.vm = component;
if(options){
this.computed = options.computed
}
if(typeof expOrFn === "function"){
// render or computed
this.getter = expOrFn
}else{
this.getter = this.parsePath();
}
if(this.computed){
this.value = undefined
this.dep = new Dep()
}else{
this.value = this.get(); //非计算属性是通过调用getter方法收集依赖。
}
}
parsePath: function(){
// 简单的路径解析，如果都是字符串则不需要解析
if (/[^\w.$]/.test(path)) {
return
}
// 这边只是简单解析了子属性的情况
const segments = path.split('.')
return function (obj) {
for (let i = 0; i < segments.length; i++) {
if (!obj) return
obj = obj[segments[i]]
}
return obj
}
}总结
我们在watcher乞丐版的基础上，根据实际需求推导出了更健全的watcher版本。下面是完整代码
class Watcher {
constructors(component, getter, cb, options){
this.cb = cb
this.getter = getter;
this.id = UUID()
this.sync = options.sync;
this.vm = component;
if(options){
this.computed = options.computed //由于是对计算属性特殊处理，那肯定要给个标识符以便判断
}
if(typeof expOrFn === "function"){
// render or computed
this.getter = expOrFn
}else{
this.getter = this.parsePath();
}
this.dirty = this.computed // for computed watchers
if(this.computed){
// 对于计算属性computed而言，我们需要关心preValue吗？ *********************
this.value = undefined
// 如果是计算属性，就要收集依赖
//同时根据按需加载的原则，这边不会手机依赖，主动执行回调函数。
this.dep = new Dep()
}else{
this.value = this.get(); //非计算属性是通过调用getter方法收集依赖。
}
}
update(){
if (this.lazy) {
this.dirty = true
} else if (this.sync) {
this.run()
} else {
queueWatcher(this)
}
}
run: function(){
//拿到新值
const value = this.get()
if (value !== this.value || //基本类型的值直接比较
// 对象没办法直接比较，因此都进行计算
isObject(value)) {
// set new value
const oldValue = this.value
this.value = value
this.dirty = false
cb.call(this.vm, value, oldValue)
}
}
// 新增depend方法，收集计算属性的依赖
depend () {
if (this.dep && Dep.target) {
this.dep.depend()
}
}
}
//不要忘了还要返回当前computed的最新的值
//由于可能不是立即更新的，因此根据dirty再判断一下，如果数据脏了，调用get再获取一下
evaluate () {
if (this.dirty) {
this.value = this.get()
this.dirty = false
}
return this.value
}可以看到，基本vue的实现一样了。VUE中有些代码，比如teardown方法，清除自身的订阅信息我并没有加进来，因为没有想到合适的应用场景。
这种逆推的过程我觉得比直接读源码更有意思。直接读源码并不难，但很容易造成似是而非的情况。逻辑很容易理解，但是真正为什么这么写，一些细节原因很容易漏掉。但是不管什么框架都是为了解决实际问题的，从需求出发，才能更好的学习一个框架，并在自己的工作中加以借鉴。
借VUE的生命周期图进行展示
局部图：
从局部图里可以看出，vue收集依赖的入口只有两个，一个是在加载之前处理$wacth方法，一个是render生成虚拟dom。
而对于computed，只有在使用到时才会收集依赖。如果我们在watch和render中都没有使用，而是在methods中使用，那么加载的过程中是不会计算这个computed的，只有在调用methods中方法时才会计算。