nextTick的实现原理是什么?

在下次DOM更新循环结束之后执行的延迟回调。

根据执行环境分别尝试采用 用微任务,再是宏任务

Promise的then -> MutationObserver的回调函数 -> setImmediate -> setTimeout 是否存在,找到存在的就调用他childrenRef

作用:
nextTick用于下次Dom更新循环结束之后执行延迟回调,在修改数据之后使用nextTick用于下次Dom更新循环结束之后执行延迟回调,在修改数据之后使用nextTick用于下次Dom更新循环结束之后执行延迟回调,在修改数据之后使用nextTick,则可以在回调中获取更新后的DOM。

应用场景:
需要在视图更新之后,基于新的视图进行操作。

实现原理:
nextTick方法主要是使用了宏任务和微任务,定义了一个异步方法,多次调用nextTick会将方法存入队列中,通过这个异步方法清空队列。


VUE中nextTick实现原理

在vue中有nextTick这个API,官方解释,它可以在DOM更新完毕之后执行一个回调。
一般使用

this.$nextTick(() => {
    ...
})

一般来说,在对于MVVM框架结构的技术栈是不推荐操作DOM的,但是很多情况下可能会需要操作DOM,特别是一些charts插件等。

所以nextTick就出现了,确保我们所操作的DOM是更新之后的。
那VUE是如何知道DOM什么时候更新完了呢?

VUE源码:(把里面的注释都删掉了)

if (typeof Promise !== 'undefined' && isNative(Promise)) {
  const p = Promise.resolve()
  timerFunc = () => {
    p.then(flushCallbacks)
    if (isIOS) setTimeout(noop)
  }
  isUsingMicroTask = true
} else if (!isIE && typeof MutationObserver !== 'undefined' && (
  isNative(MutationObserver) ||
  MutationObserver.toString() === '[object MutationObserverConstructor]'
)) {
  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)) {
  timerFunc = () => {
    setImmediate(flushCallbacks)
  }
} else {
  timerFunc = () => {
    setTimeout(flushCallbacks, 0)
  }
}

步骤:

先判断Promise

在判断MutationObserver

在判断setImmediate

最后setTimeout

整体流程涉及到事件的循环(Event Loop)[暂不在这说]

每次event loop的最后,会有一个UI render,也就是更新DOM

只要让nextTick里的代码放在UI render步骤后面执行,就能访问到更新后的DOM了。

又涉及到微任务(microtask)和宏任务(macrotask)

microtask有:Promise、MutationObserver,以及nodejs中的process.nextTick

macrotask有:setTimeout, setInterval, setImmediate, I/O, UI rendering

每一次事件循环都包含一个microtask队列,在循环结束后会依次执行队列中的microtask并移除,然后再开始下一次事件循环。

vue的nextTick方法的实现原理:

vue用异步队列的方式来控制DOM更新和nextTick回调先后执行

microtask因为其高优先级特性,能确保队列中的微任务在一次事件循环前被执行完毕

因为浏览器和移动端兼容问题,vue不得不做了microtask向macrotask的兼容(降级)方案

原文链接:https://blog.csdn.net/guoqiankunmiss/java/article/details/97808703

VUE中nextTick实现原理在vue中有nextTick这个API,官方解释,它可以在DOM更新完毕之后执行一个回调。一般使用
this.$nextTick(() => {...})123一般来说,在对于MVVM框架结构的技术栈是不推荐操作DOM的,但是很多情况下可能会需要操作DOM,特别是一些charts插件等。
所以nextTick就出现了,确保我们所操作的DOM是更新之后的。那VUE是如何知道DOM什么时候更新完了呢?
VUE源码:(把里面的注释都删掉了)
if (typeof Promise !== 'undefined' && isNative(Promise)) {  const p = Promise.resolve()  timerFunc = () => {    p.then(flushCallbacks)    if (isIOS) setTimeout(noop)  }  isUsingMicroTask = true} else if (!isIE && typeof MutationObserver !== 'undefined' && (  isNative(MutationObserver) ||  MutationObserver.toString() === '[object MutationObserverConstructor]')) {  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)) {  timerFunc = () => {    setImmediate(flushCallbacks)  }} else {  timerFunc = () => {    setTimeout(flushCallbacks, 0)  }}
1234567891011121314151617181920212223242526272829303132步骤:
先判断Promise在判断MutationObserver在判断setImmediate最后setTimeout整体流程涉及到事件的循环(Event Loop)[暂不在这说]
每次event loop的最后,会有一个UI render,也就是更新DOM只要让nextTick里的代码放在UI render步骤后面执行,就能访问到更新后的DOM了。
又涉及到微任务(microtask)和宏任务(macrotask)microtask有:Promise、MutationObserver,以及nodejs中的process.nextTickmacrotask有:setTimeout, setInterval, setImmediate, I/O, UI rendering每一次事件循环都包含一个microtask队列,在循环结束后会依次执行队列中的microtask并移除,然后再开始下一次事件循环。
vue的nextTick方法的实现原理:
vue用异步队列的方式来控制DOM更新和nextTick回调先后执行microtask因为其高优先级特性,能确保队列中的微任务在一次事件循环前被执行完毕因为浏览器和移动端兼容问题,vue不得不做了microtask向macrotask的兼容(降级)方案————————————————版权声明:本文为CSDN博主「gqkmiss」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。原文链接:https://blog.csdn.net/guoqiankunmiss/java/article/details/97808703

原文地址:https://www.cnblogs.com/qinglaoshi/p/13276585.html