Vue异步更新Dom和$nextTick

Vue异步更新Dom和$nextTick


$nextTick 的使用场景

虽然 Vue 是数据驱动的,但是有时候我们不得不去操作 DOM 去处理一些特殊的场景,而 Vue 更新 DOM 是异步执行的,所以我们不得不去使用 $nextTick 去异步获取 DOM。

<template>
  <div>
    <span ref="msg">{{ msg }}</span>
  </div>
</template>

<script>
export default {
  data() {
    return {
      msg: 'hello nextTick'
    }
  },
  methods: {
    changeMsg() {
      this.msg = 'hello world'
      console.log(this.$refs.msg.innerHTML, '同步获取')
      this.$nextTick(() => {
        console.log(this.$refs.msg.innerHTML, '异步获取')
      })
    }
  },
  mounted() {
    this.changeMsg()
  }
}
</script>

Vue异步更新Dom和$nextTick

我们可以看到,当我我们直接改变数据后,获取 DOM 的话,值是没有改变的,而在 $nextTick 中却可以看到数据发生了变化,为什么呢?下面我们通过源码看一看原因

Watcher 视图更新

update () {
  /* istanbul ignore else */
  if (this.lazy) {
    this.dirty = true
  } else if (this.sync) {
    /*同步则执行run直接渲染视图*/
    this.run()
  } else {
    /*异步推送到观察者队列中,由调度者调用。*/
    queueWatcher(this)
  }
}

如果你看过响应式原理的时候,在 Watcher 中会有一个 update 函数用来更新视图的,当 this.sync 为 false 的时候,就标志着是异步更新,所以会执行 queueWatcher 函数

 /*将一个观察者对象push进观察者队列,在队列中已经存在相同的id则该观察者对象将被跳过,除非它是在队列被刷新时推送*/
export function queueWatcher (watcher: Watcher) {
  const id = watcher.id
  /*检验id是否存在,已经存在则直接跳过,不存在则标记哈希表has,用于下次检验*/
  if (has[id] == null) {
    has[id] = true
    if (!flushing) {
      /*如果没有flush掉,直接push到队列中即可*/
      queue.push(watcher)
    } else {
      // if already flushing, splice the watcher based on its id
      // if already past its id, it will be run next immediately.
      // 如果刷新了,那就从队列中取出,立即执行即可
      let i = queue.length - 1
      while (i > index && queue[i].id > watcher.id) {
        i--
      }
      queue.splice(i + 1, 0, watcher)
    }
    // queue the flush
    if (!waiting) { // 没有 waiting,则直接执行 nextTick
      waiting = true

      if (process.env.NODE_ENV !== 'production' && !config.async) {
        flushSchedulerQueue()
        return
      }
      nextTick(flushSchedulerQueue)
    }
  }
}

通过 queueWatcher 函数,我们就能看出来了,Watcher 不是立即更新视图的,而是会放在一个队列中,此时是 waiting 等待状态,它会检查 id 是否重复,如果重复的话,就不会放进队列中;如果没有重复才会放入队列,而且当前 Watcher 是不能刷新的,如果刷新的话,就从队列中取出,没有刷新的 Watcher 才会被放入队列中。如果没有 waiting 等待状态了,那么就证明需要进入下一个 tick 了,会执行 nextTick 方法。

nextTick

讲了这么多,终于到 nextTick 了

export let isUsingMicroTask = false // 是否使用了微任务

const callbacks = [] /*存放异步执行的回调*/
let pending = false /*一个标记位,如果已经有timerFunc被推送到任务队列中去则不需要重复推送*/

function flushCallbacks () {
  pending = false
  const copies = callbacks.slice(0)
  callbacks.length = 0
  for (let i = 0; i < copies.length; i++) {
    copies[i]()
  }
}

// Here we have async deferring wrappers using microtasks.
// In 2.5 we used (macro) tasks (in combination with microtasks).
// However, it has subtle problems when state is changed right before repaint
// (e.g. #6813, out-in transitions).
// Also, using (macro) tasks in event handler would cause some weird behaviors
// that cannot be circumvented (e.g. #7109, #7153, #7546, #7834, #8109).
// So we now use microtasks everywhere, again.
// A major drawback of this tradeoff is that there are some scenarios
// where microtasks have too high a priority and fire in between supposedly
// sequential events (e.g. #4521, #6690, which have workarounds)
// or even between bubbling of the same event (#6566).
let timerFunc /*一个函数指针,指向函数将被推送到任务队列中,等到主线程任务执行完时,任务队列中的timerFunc被调用*/

// The nextTick behavior leverages the microtask queue, which can be accessed
// via either native Promise.then or MutationObserver.
// MutationObserver has wider support, however it is seriously bugged in
// UIWebView in iOS >= 9.3.3 when triggered in touch event handlers. It
// completely stops working after triggering a few times... so, if native
// Promise is available, we will use it:
/* istanbul ignore next, $flow-disable-line */
if (typeof Promise !== 'undefined' && isNative(Promise)) {
  const p = Promise.resolve()
  timerFunc = () => {
    p.then(flushCallbacks)
    // In problematic UIWebViews, Promise.then doesn't completely break, but
    // it can get stuck in a weird state where callbacks are pushed into the
    // microtask queue but the queue isn't being flushed, until the browser
    // needs to do some other work, e.g. handle a timer. Therefore we can
    // "force" the microtask queue to be flushed by adding an empty timer.
    if (isIOS) setTimeout(noop) // 如果是 isIOS 环境,则执行 setTimeout
  }
  isUsingMicroTask = true
} else if (!isIE && typeof MutationObserver !== 'undefined' && ( // MutationObserver 在 IE 下的兼容性有问题
  isNative(MutationObserver) ||
  // PhantomJS and iOS 7.x
  MutationObserver.toString() === '[object MutationObserverConstructor]'
)) {
  // Use MutationObserver where native Promise is not available,
  // e.g. PhantomJS, iOS7, Android 4.4
  // (#6466 MutationObserver is unreliable in IE11)
  let counter = 1
  const observer = new MutationObserver(flushCallbacks)
  const textNode = document.createTextNode(String(counter))
  observer.observe(textNode, {
    characterData: true
  })
  timerFunc = () => {
    counter = (counter + 1) % 2
    textNode.data = String(counter)
  }
  isUsingMicroTask = true
} else if (typeof setImmediate !== 'undefined' && isNative(setImmediate)) {
  // Fallback to setImmediate.
  // Technically it leverages the (macro) task queue,
  // but it is still a better choice than setTimeout.
  timerFunc = () => {
    setImmediate(flushCallbacks)
  }
} else {
  // Fallback to setTimeout.
  timerFunc = () => {
    setTimeout(flushCallbacks, 0)
  }
}

export function nextTick (cb?: Function, ctx?: Object) {
  let _resolve
  // 把 cb 加上异常处理存入 callbacks 数组中
  callbacks.push(() => {
    if (cb) {
      try {
        // 调用 cb()
        cb.call(ctx)
      } catch (e) {
        handleError(e, ctx, 'nextTick')
      }
    } else if (_resolve) {
      _resolve(ctx)
    }
  })
  if (!pending) {
    pending = true
    // 调用
    timerFunc()
  }
  // $flow-disable-line
  if (!cb && typeof Promise !== 'undefined') {
    // 返回 promise 对象
    return new Promise(resolve => {
      _resolve = resolve
    })
  }
}

nextTick 接收两个参数,一个是回调函数,一个是当前环境的上下文,执行 nextTick 会将回调函数放入 callbacks 回调队列中,然后通过 timerFunc 去执行。然后会判断当前执行环境是否有 Promise,如果有的话,通过 Promise.resolve().then 去执行回调函数中的内容,如果是 IOS 环境的话,则执行 setTimeout,因为 IOS 的某些版本对 Promise 的支持不太好;如果当前环境不支持 Promise,则降级使用微任务 MutationObserver,注释中也列举出了很多不支持 Promise 的环境,例如 e.g. PhantomJS, iOS7, Android 4.4;如果 MutationObserver 也不被支持的话,那么就使用宏任务 setImmediate 了;而最坏的情况就是使用 setTimeout 了,至于为什么不直接使用 setTimeout 而多一个 setImmediate,是因为 setImmediate 的执行速度要比 setTimeout,因为 setTimeout 即使将时间参数设为 0 的话,也还是会有 4 ms 的延迟。

为什么要异步更新视图

<template>
  <div>
    <div>{{value}}</div>
  </div>
</template>
export default {
    data () {
        return {
            value: 0
        };
    },
    mounted () {
      for(let i = 0; i < 1000; i++) {
        this.value++;
      }
    }
}

当我们在 mounted 钩子函数中,循环改变某一个值的时候,如果没有异步更新,那么 value 每一次 ++ 的时候,都会操作 DOM 去更新,但是这种更新又是没有意义的,这样就会非常消耗性能。但是有了异步 DOM 队列,它只会在下一个 tick 执行,这样就能保障 i 从 0 直接到 1000 才执行,这样大大优化了性能。

上一篇:自学javaee程序员之路--ssm的小项目(一)


下一篇:Yii2发送邮箱总结