源码学习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来表示队列的更新状态。
如果加入的时候队列正在更新状态，这时候分两种情况：

1. 这个watcher已经更新过， 就把这个watcher再放到当前执行的下一位，当前watcher处理完，立即处理这个最新的。
2. 这个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

之所以把计算属性拿出爱单独讲，是因为

1. 计算属性存在按需加载的情况
2. 与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中方法时才会计算。