源码学习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的生命周期图进行展示

clipboard.png

局部图:

clipboard.png

从局部图里可以看出,vue收集依赖的入口只有两个,一个是在加载之前处理$wacth方法,一个是render生成虚拟dom。
而对于computed,只有在使用到时才会收集依赖。如果我们在watch和render中都没有使用,而是在methods中使用,那么加载的过程中是不会计算这个computed的,只有在调用methods中方法时才会计算。

阅读 5.8k

前端成长之路
记录前端成长路上的心得体会。

诸事烦于心今日岂能浪迹天涯,

178 声望
15 粉丝
0 条评论
你知道吗?

诸事烦于心今日岂能浪迹天涯,

178 声望
15 粉丝
宣传栏