• 派发更新
    • 过程分析
    • 总结

    派发更新

    通过上一节分析我们了解了响应式数据依赖收集过程，收集的目的就是为了当我们修改数据的时候，可以对相关的依赖派发更新，那么这一节我们来详细分析这个过程。

    我们先来回顾一下 setter 部分的逻辑：

    1. /**
    2.  * Define a reactive property on an Object.
    3.  */
    4. export function defineReactive (
    5.   obj: Object,
    6.   key: string,
    7.   val: any,
    8.   customSetter?: ?Function,
    9.   shallow?: boolean
    10. ) {
    11.   const dep = new Dep()
    13.   const property = Object.getOwnPropertyDescriptor(obj, key)
    14.   if (property && property.configurable === false) {
    15.     return
    16.   }
    18.   // cater for pre-defined getter/setters
    19.   const getter = property && property.get
    20.   const setter = property && property.set
    21.   if ((!getter || setter) && arguments.length === 2) {
    22.     val = obj[key]
    23.   }
    25.   let childOb = !shallow && observe(val)
    26.   Object.defineProperty(obj, key, {
    27.     enumerable: true,
    28.     configurable: true,
    29.     // ...
    30.     set: function reactiveSetter (newVal) {
    31.       const value = getter ? getter.call(obj) : val
    32.       /* eslint-disable no-self-compare */
    33.       if (newVal === value || (newVal !== newVal && value !== value)) {
    34.         return
    35.       }
    36.       /* eslint-enable no-self-compare */
    37.       if (process.env.NODE_ENV !== 'production' && customSetter) {
    38.         customSetter()
    39.       }
    40.       if (setter) {
    41.         setter.call(obj, newVal)
    42.       } else {
    43.         val = newVal
    44.       }
    45.       childOb = !shallow && observe(newVal)
    46.       dep.notify()
    47.     }
    48.   })
    49. }

    setter 的逻辑有 2 个关键的点，一个是 childOb = !shallow && observe(newVal)，如果 shallow 为 false 的情况，会对新设置的值变成一个响应式对象；另一个是 dep.notify()，通知所有的订阅者，这是本节的关键，接下来我会带大家完整的分析整个派发更新的过程。

    过程分析

    当我们在组件中对响应的数据做了修改，就会触发 setter 的逻辑，最后调用 dep.notify() 方法，它是 Dep 的一个实例方法，定义在 src/core/observer/dep.js 中：

    1. class Dep {
    2.   // ...
    3.   notify () {
    4.   // stabilize the subscriber list first
    5.     const subs = this.subs.slice()
    6.     for (let i = 0, l = subs.length; i < l; i++) {
    7.       subs[i].update()
    8.     }
    9.   }
    10. }

    这里的逻辑非常简单，遍历所有的 subs，也就是 Watcher 的实例数组，然后调用每一个 watcher 的 update 方法，它的定义在 src/core/observer/watcher.js 中：

    1. class Watcher {
    2.   // ...
    3.   update () {
    4.     /* istanbul ignore else */
    5.     if (this.computed) {
    6.       // A computed property watcher has two modes: lazy and activated.
    7.       // It initializes as lazy by default, and only becomes activated when
    8.       // it is depended on by at least one subscriber, which is typically
    9.       // another computed property or a component's render function.
    10.       if (this.dep.subs.length === 0) {
    11.         // In lazy mode, we don't want to perform computations until necessary,
    12.         // so we simply mark the watcher as dirty. The actual computation is
    13.         // performed just-in-time in this.evaluate() when the computed property
    14.         // is accessed.
    15.         this.dirty = true
    16.       } else {
    17.         // In activated mode, we want to proactively perform the computation
    18.         // but only notify our subscribers when the value has indeed changed.
    19.         this.getAndInvoke(() => {
    20.           this.dep.notify()
    21.         })
    22.       }
    23.     } else if (this.sync) {
    24.       this.run()
    25.     } else {
    26.       queueWatcher(this)
    27.     }
    28.   }
    29. }

    这里对于 Watcher 的不同状态，会执行不同的逻辑，computed 和 sync 等状态的分析我会之后抽一小节详细介绍，在一般组件数据更新的场景，会走到最后一个 queueWatcher(this) 的逻辑，queueWatcher 的定义在 src/core/observer/scheduler.js 中：

    1. const queue: Array<Watcher> = []
    2. let has: { [key: number]: ?true } = {}
    3. let waiting = false
    4. let flushing = false
    5. /**
    6.  * Push a watcher into the watcher queue.
    7.  * Jobs with duplicate IDs will be skipped unless it's
    8.  * pushed when the queue is being flushed.
    9.  */
    10. export function queueWatcher (watcher: Watcher) {
    11.   const id = watcher.id
    12.   if (has[id] == null) {
    13.     has[id] = true
    14.     if (!flushing) {
    15.       queue.push(watcher)
    16.     } else {
    17.       // if already flushing, splice the watcher based on its id
    18.       // if already past its id, it will be run next immediately.
    19.       let i = queue.length - 1
    20.       while (i > index && queue[i].id > watcher.id) {
    21.         i--
    22.       }
    23.       queue.splice(i + 1, 0, watcher)
    24.     }
    25.     // queue the flush
    26.     if (!waiting) {
    27.       waiting = true
    28.       nextTick(flushSchedulerQueue)
    29.     }
    30.   }
    31. }

    这里引入了一个队列的概念，这也是 Vue 在做派发更新的时候的一个优化的点，它并不会每次数据改变都触发 watcher 的回调，而是把这些 watcher 先添加到一个队列里，然后在 nextTick 后执行 flushSchedulerQueue。

    这里有几个细节要注意一下，首先用 has 对象保证同一个 Watcher 只添加一次；接着对 flushing 的判断，else 部分的逻辑稍后我会讲；最后通过 wating 保证对 nextTick(flushSchedulerQueue) 的调用逻辑只有一次，另外 nextTick 的实现我之后会抽一小节专门去讲，目前就可以理解它是在下一个 tick，也就是异步的去执行 flushSchedulerQueue。

    接下来我们来看 flushSchedulerQueue 的实现，它的定义在 src/core/observer/scheduler.js 中。

    1. let flushing = false
    2. let index = 0
    3. /**
    4.  * Flush both queues and run the watchers.
    5.  */
    6. function flushSchedulerQueue () {
    7.   flushing = true
    8.   let watcher, id
    10.   // Sort queue before flush.
    11.   // This ensures that:
    12.   // 1. Components are updated from parent to child. (because parent is always
    13.   //    created before the child)
    14.   // 2. A component's user watchers are run before its render watcher (because
    15.   //    user watchers are created before the render watcher)
    16.   // 3. If a component is destroyed during a parent component's watcher run,
    17.   //    its watchers can be skipped.
    18.   queue.sort((a, b) => a.id - b.id)
    20.   // do not cache length because more watchers might be pushed
    21.   // as we run existing watchers
    22.   for (index = 0; index < queue.length; index++) {
    23.     watcher = queue[index]
    24.     if (watcher.before) {
    25.       watcher.before()
    26.     }
    27.     id = watcher.id
    28.     has[id] = null
    29.     watcher.run()
    30.     // in dev build, check and stop circular updates.
    31.     if (process.env.NODE_ENV !== 'production' && has[id] != null) {
    32.       circular[id] = (circular[id] || 0) + 1
    33.       if (circular[id] > MAX_UPDATE_COUNT) {
    34.         warn(
    35.           'You may have an infinite update loop ' + (
    36.             watcher.user
    37.               ? `in watcher with expression "${watcher.expression}"`
    38.               : `in a component render function.`
    39.           ),
    40.           watcher.vm
    41.         )
    42.         break
    43.       }
    44.     }
    45.   }
    47.   // keep copies of post queues before resetting state
    48.   const activatedQueue = activatedChildren.slice()
    49.   const updatedQueue = queue.slice()
    51.   resetSchedulerState()
    53.   // call component updated and activated hooks
    54.   callActivatedHooks(activatedQueue)
    55.   callUpdatedHooks(updatedQueue)
    57.   // devtool hook
    58.   /* istanbul ignore if */
    59.   if (devtools && config.devtools) {
    60.     devtools.emit('flush')
    61.   }
    62. }

    这里有几个重要的逻辑要梳理一下，对于一些分支逻辑如 keep-alive 组件相关和之前提到过的 updated 钩子函数的执行会略过。

    • 队列排序
      queue.sort((a, b) => a.id - b.id) 对队列做了从小到大的排序，这么做主要有以下要确保以下几点：

    1.组件的更新由父到子；因为父组件的创建过程是先于子的，所以 watcher 的创建也是先父后子，执行顺序也应该保持先父后子。

    2.用户的自定义 watcher 要优先于渲染 watcher 执行；因为用户自定义 watcher 是在渲染 watcher 之前创建的。

    3.如果一个组件在父组件的 watcher 执行期间被销毁，那么它对应的 watcher 执行都可以被跳过，所以父组件的 watcher 应该先执行。

    • 队列遍历
      在对 queue 排序后，接着就是要对它做遍历，拿到对应的 watcher，执行 watcher.run()。这里需要注意一个细节，在遍历的时候每次都会对 queue.length 求值，因为在 watcher.run() 的时候，很可能用户会再次添加新的 watcher，这样会再次执行到 queueWatcher，如下：
    1. export function queueWatcher (watcher: Watcher) {
    2.   const id = watcher.id
    3.   if (has[id] == null) {
    4.     has[id] = true
    5.     if (!flushing) {
    6.       queue.push(watcher)
    7.     } else {
    8.       // if already flushing, splice the watcher based on its id
    9.       // if already past its id, it will be run next immediately.
    10.       let i = queue.length - 1
    11.       while (i > index && queue[i].id > watcher.id) {
    12.         i--
    13.       }
    14.       queue.splice(i + 1, 0, watcher)
    15.     }
    16.     // ...
    17.   }
    18. }

    可以看到，这时候 flushing 为 true，就会执行到 else 的逻辑，然后就会从后往前找，找到第一个待插入 watcher 的 id 比当前队列中 watcher 的 id 大的位置。把 watcher 按照 id的插入到队列中，因此 queue 的长度发送了变化。

    • 状态恢复
      这个过程就是执行 resetSchedulerState 函数，它的定义在 src/core/observer/scheduler.js 中。
    1. const queue: Array<Watcher> = []
    2. let has: { [key: number]: ?true } = {}
    3. let circular: { [key: number]: number } = {}
    4. let waiting = false
    5. let flushing = false
    6. let index = 0
    7. /**
    8.  * Reset the scheduler's state.
    9.  */
    10. function resetSchedulerState () {
    11.   index = queue.length = activatedChildren.length = 0
    12.   has = {}
    13.   if (process.env.NODE_ENV !== 'production') {
    14.     circular = {}
    15.   }
    16.   waiting = flushing = false
    17. }

    逻辑非常简单，就是把这些控制流程状态的一些变量恢复到初始值，把 watcher 队列清空。

    接下来我们继续分析 watcher.run() 的逻辑，它的定义在 src/core/observer/watcher.js 中。

    1. class Watcher {
    2.   /**
    3.    * Scheduler job interface.
    4.    * Will be called by the scheduler.
    5.    */
    6.   run () {
    7.     if (this.active) {
    8.       this.getAndInvoke(this.cb)
    9.     }
    10.   }
    12.   getAndInvoke (cb: Function) {
    13.     const value = this.get()
    14.     if (
    15.       value !== this.value ||
    16.       // Deep watchers and watchers on Object/Arrays should fire even
    17.       // when the value is the same, because the value may
    18.       // have mutated.
    19.       isObject(value) ||
    20.       this.deep
    21.     ) {
    22.       // set new value
    23.       const oldValue = this.value
    24.       this.value = value
    25.       this.dirty = false
    26.       if (this.user) {
    27.         try {
    28.           cb.call(this.vm, value, oldValue)
    29.         } catch (e) {
    30.           handleError(e, this.vm, `callback for watcher "${this.expression}"`)
    31.         }
    32.       } else {
    33.         cb.call(this.vm, value, oldValue)
    34.       }
    35.     }
    36.   }
    37. }

    run 函数实际上就是执行 this.getAndInvoke 方法，并传入 watcher 的回调函数。getAndInvoke 函数逻辑也很简单，先通过 this.get() 得到它当前的值，然后做判断，如果满足新旧值不等、新值是对象类型、deep 模式任何一个条件，则执行 watcher 的回调，注意回调函数执行的时候会把第一个和第二个参数传入新值 value 和旧值 oldValue，这就是当我们添加自定义 watcher 的时候能在回调函数的参数中拿到新旧值的原因。

    那么对于渲染 watcher 而言，它在执行 this.get() 方法求值的时候，会执行 getter 方法：

    1. updateComponent = () => {
    2.   vm._update(vm._render(), hydrating)
    3. }

    所以这就是当我们去修改组件相关的响应式数据的时候，会触发组件重新渲染的原因，接着就会重新执行 patch 的过程，但它和首次渲染有所不同，之后我们会花一小节去详细介绍。

    总结

    通过这一节的分析，我们对 Vue 数据修改派发更新的过程也有了认识，实际上就是当数据发生变化的时候，触发 setter 逻辑，把在依赖过程中订阅的的所有观察者，也就是 watcher，都触发它们的 update 过程，这个过程又利用了队列做了进一步优化，在 nextTick 后执行所有 watcher 的 run，最后执行它们的回调函数。nextTick 是 Vue 一个比较核心的实现了，下一节我们来重点分析它的实现。

    原文: https://ustbhuangyi.github.io/vue-analysis/reactive/setters.html