nextTick
- 下面了解下nextTick的主要应用的场景及原因。
在Vue生命周期的created()钩子函数进行的DOM操作一定要放在Vue.nextTick()的回调函数中
created()钩子函数执行的时候DOM 其实并未进行任何渲染，而此时进行DOM操作无异于徒劳，所以要将DOM操作的js代码放进Vue.nextTick()的回调函数中。与之对应的就是mounted()钩子函数，因为该钩子函数执行时所有的DOM挂载和渲染都已完成，此时在该钩子函数中进行任何DOM操作都不会有问题 。
在数据变化后要执行的某个操作，而这个操作需要使用随数据改变而改变的DOM结构的时候，这个操作都应该放进Vue.nextTick()的回调函数中。
https://zhuanlan.zhihu.com/p/69641232
- nextTick 按我的理解，就是设置一个回调，用于异步执行
异步执行，比如，就是把你设置的回调放在 setTimeout 中执行，这样就算异步了，等待当时同步代码执行完毕再执行
但是，每设置一个 nextTick 就新建一个 setTimeout 又不实际，
毕竟一个 setTimeout 是异步，两个setTimeout 也是异步，两个都要等在 同步代码执行完毕之后才执行
那我直接只设置一个 setTimeout 不就好了
-
那一个 setTimeout 怎么执行多个回调呢？
1 存在 回调数组 里。每次调用 nextTick，便往数组里面 push 设置的回调2 只注册一个 setTimeout，时间为0，用于遍历 回调数组，然后逐个执行子项
3 同步代码执行完毕，setTimeout 自然会执行
Vue 不止使用 setTimeout
Vue的 nextTick 也是只用setTimeout 吗，不是的，这里便会涉及到 javascript 的 宏微任务
关于宏微任务，简单说一下
1 两者区别在于执行权重的问题，微任务优先级要比宏任务高
2 宏任务 和 微任务 合作完成一个 Event Loop
3 执行一个 宏任务，便会执行一列微任务。接着执行另一个宏任务...（循环往复，比如一个setTimeout 就是一个宏任务）
Vue 2.4 以前，只使用 微任务，因为微任务执行优先级高
Vue 2.5.3 之后，分成了 宏任务 和 微任务，为了解决连续事件带来的问题，比如冒泡（至于为什么，会有一篇文章说明）
Vue 2.6 ，又只使用微任务，因为想到了其他办法解决连续事件的问题
Vue 的 宏微任务 并不算是严格意义上的宏微任务，是种兼容的写法。
- Vue 使用了 nextTick 进行统一更新
你应该知道，即使在 Vue 中多么频繁地修改数据，最后 Vue 页面只会更新一次
这是 Vue 和 nextTick 合作产生的结果，但又并不只是 nextTick 起作用
比如
数据 name 被 页面引用，name 会收集到 页面的 watcher
name 被修改时，会通知所有收集到的 watcher 进行更新（watcher.update）
this.name = 2
this.name = 3
this.name = 4
name 一时间被修改三次时，按道理应该会通知三次 watcher 更新，那么页面会更新三次
但是最后只会更新一次
就是因为他们的合作
设置 nextTick 回调 + 过滤 watcher
当数据变化后，把 watcher.update 函数存放进 nextTick 的 回调数组中，并且会做过滤。
通过 watcher.id 来判断 回调数组 中是否已经存在这个 watcher 的更新函数
不存在，才 push
之后 nextTick 遍历回调数组，便会执行了更新
所以
当三次修改数据的时候，会准备 push进 回调数组 三个 watcher.update，但是只有第一次是 push 成功的，其他的会被过滤掉
所以，不管你修改多少次数据，nextTick 的回调数组中只存在唯一一个 watcher.update，从而页面只会更新一次
源码
/**
* Defer a task to execute it asynchronously.
*/
export const nextTick = (function () {
const callbacks = []
let pending = false
let timerFunc
function nextTickHandler () {
pending = false
const copies = callbacks.slice(0)
callbacks.length = 0
for (let i = 0; i < copies.length; i++) {
copies[i]()
}
}
// 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 if */
if (typeof Promise !== 'undefined' && isNative(Promise)) {
var p = Promise.resolve()
var logError = err => { console.error(err) }
timerFunc = () => {
p.then(nextTickHandler).catch(logError)
// 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)
}
} else if (!isIE && typeof MutationObserver !== 'undefined' && (
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
var counter = 1
var observer = new MutationObserver(nextTickHandler)
var textNode = document.createTextNode(String(counter))
observer.observe(textNode, {
characterData: true
})
timerFunc = () => {
counter = (counter + 1) % 2
textNode.data = String(counter)
}
} else {
// fallback to setTimeout
/* istanbul ignore next */
timerFunc = () => {
setTimeout(nextTickHandler, 0)
}
}
return function queueNextTick (cb?: Function, ctx?: Object) {
let _resolve
callbacks.push(() => {
if (cb) {
try {
cb.call(ctx)
} catch (e) {
handleError(e, ctx, 'nextTick')
}
} else if (_resolve) {
_resolve(ctx)
}
})
if (!pending) {
pending = true
timerFunc()
}
if (!cb && typeof Promise !== 'undefined') {
return new Promise((resolve, reject) => {
_resolve = resolve
})
}
}
})()
