用法:
在下次 DOM 更新迴圈結束之後執行延遲迴調。在修改資料之後立即使用這個方法,獲取更新後的 DOM。
疑惑:
怎麼實現的延遲迴調
原理:
- JavaScript語言的一大特點就是單執行緒,同一個時間只能做一件事
- JavaScript任務可以分為兩種,一種是同步任務,一種是非同步任務
- 非同步任務大致分為,巨集任務,和微任務
- 所有同步任務都在主執行緒上執行,形成一個執行棧
- 主執行緒之外,還存在一個"任務佇列"(task queue)。只要非同步任務有了執行結果,就在"任務佇列"之中放置一個事件。
- 一旦"執行棧"中的所有同步任務執行完畢,系統就會讀取"任務佇列"中的微任務,其次是巨集任務,看看裡面有哪些事件。那些對應的非同步任務,於是結束等待狀態,進入執行棧,開始執行。
- 主執行緒不斷重複上面的第6步。
vue實現:
vue 大多數情況下優先使用微任務, 很少的地方使用巨集任務
vue nextTick 巨集任務實現
- 優先檢測 setImmediate
if (typeof setImmediate !== 'undefined' && isNative(setImmediate)) {
macroTimerFunc = () => {
setImmediate(flushCallbacks)
}
}
複製程式碼
setImmediate 瀏覽器支援情況
- 其次檢測 MessageChannel 支援情況
else if (typeof MessageChannel !== 'undefined' && (
isNative(MessageChannel) ||
// PhantomJS
MessageChannel.toString() === '[object MessageChannelConstructor]'
)) {
const channel = new MessageChannel()
const port = channel.port2
channel.port1.onmessage = flushCallbacks
macroTimerFunc = () => {
port.postMessage(1)
}
}
複製程式碼
MessageChannel 瀏覽器支援情況
- 上面都不支援就使用最原始的setTimeout
else {
/* istanbul ignore next */
macroTimerFunc = () => {
setTimeout(flushCallbacks, 0)
}
}
複製程式碼
vue nextTick 微任務實現
- 優先檢測 Promise
if (typeof Promise !== 'undefined' && isNative(Promise)) {
const p = Promise.resolve()
microTimerFunc = () => {
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)
}
}
複製程式碼
Promise 瀏覽器支援情況
- 如果不支援Promise, 還是使用巨集任務
else {
// fallback to macro
microTimerFunc = macroTimerFunc
}
複製程式碼
vue中什麼地方用巨集任務,什麼地方用微任務?
從原始碼中可以看出,在DOM事件中使用Vue.nextTick 預設使用巨集任務, 其他地方使用Vue.nextTick預設使用微任務。
其實從原始碼中註釋中可以看出Vue最開始都是使用微任務方式,後面出現了bug,才引入了巨集任務方式
// Here we have async deferring wrappers using both microtasks and (macro) tasks.
// In < 2.4 we used microtasks everywhere, but there are some scenarios where
// microtasks have too high a priority and fire in between supposedly
// sequential events (e.g. #4521, #6690) or even between bubbling of the same
// event (#6566). However, using (macro) tasks everywhere also has subtle problems
// when state is changed right before repaint (e.g. #6813, out-in transitions).
// Here we use microtask by default, but expose a way to force (macro) task when
// needed (e.g. in event handlers attached by v-on).
複製程式碼