Shulou(Shulou.com)05/31 Report--

In this article Xiaobian for you to introduce in detail the "Vue asynchronous update mechanism and $nextTick principle is what", the content is detailed, the steps are clear, the details are handled properly, I hope this "Vue asynchronous update mechanism and $nextTick principle is what" article can help you solve doubts, following the editor's ideas slowly in-depth, together to learn new knowledge.

Asynchronous updates of Vue

In case you haven't noticed, Vue performs DOM updates asynchronously. As soon as data changes are observed, Vue opens a queue and buffers all data changes that occur in the same event loop. If the same watcher is triggered multiple times, it will only be pushed into the queue once. This removal of duplicate data during buffering is important to avoid unnecessary calculations and DOM operations. Then, in the next event loop "tick", Vue refreshes the queue and performs the actual (deduplicated) work.

DOM updates are asynchronous

When we immediately get the content in DOM after updating the data, we will find that what we get is still the old content.

{{name}} export default {data () {return {name: 'front end Nanjiu'}}, mounted () {this.name = 'front end' console.log (' sync',this.$refs.title.innerText) this.$nextTick (() = > {console.log ('nextTick',this.$refs.title.innerText)})}}

From the figure, we can see that the content in the dom element is the old data synchronously after the data change, while the updated data is obtained in the nextTick. Why?

In fact, here you use micro tasks or macro tasks to get the updated data in the dom element, so we can try it:

Mounted () {this.name = 'front end' console.log (' sync',this.$refs.title.innerText) Promise.resolve (). Then () = > {console.log ('micro task', this.$refs.title.innerText)}) setTimeout () = > {console.log ('macro task', this.$refs.title.innerText)}, 0) this.$nextTick () = > {console.log ('nextTick',this.$refs.title.innerText)})}

Feel a little incredible, in fact, nothing strange, in the vue source code its implementation principle is the use of micro-tasks and macro tasks, slowly look down, will be explained one by one later.

DOM updates are still in batch

Yes, DOM updates in vue are processed in batches, and there is no doubt that this has the advantage of maximizing performance. OK, there's something interesting here. Don't worry.

Vue updates multiple data at the same time. Do you think dom is updated multiple times or once? Let's try it.

{{name}} {{verse}} export default {name: 'nextTick', data () {return {name:' front-end Nanjiu', verse:'if Dongshan can rise again Dapeng spread his wings on Jiuxiao', count:0}}, mounted () {this.name = 'front end' this.verse =' everything in the world is empty Fame and fortune seem like wind'/ / console.log ('sync',this.$refs.title.innerText) / / Promise.resolve (). Then () = > {/ / console.log (' micro task', this.$refs.title.innerText) / /}) / / setTimeout () = > {/ / console.log ('macro task', this.$refs.title.innerText) / /} 0) / / this.$nextTick (() = > {/ / console.log ('nextTick',this.$refs.title.innerText) / /})}, updated () {this.count++ console.log (' update:',this.count)}} .verse {font-size: (20/@rem) }

We can see that the updated hook is executed only once, which means that we have updated multiple data at the same time, and DOM will only update once.

Let's look at another situation. When synchronous and asynchronous are mixed, how many times will DOM be updated?

Mounted () {this.name = 'front end' this.verse =' everything in the world is empty, fame and wealth is like the wind 'Promise.resolve (). Then (() = > {this.name =' study...'}) setTimeout () = > {this.verse = 'half-body wind and rain, half-body cold / console.log ('sync',this.$refs.title.innerText) / / Promise.resolve (). Then () = > {/ / console.log (' micro task', this.$refs.title.innerText) / / setTimeout () = > {/ / console.log ('macro task', this.$refs.title.innerText) / /} 0) / / this.$nextTick (() = > {/ / console.log ('nextTick',this.$refs.title.innerText) / /})}, updated () {this.count++ console.log (' update:',this.count)}

From the figure, we can see that DOM will render three times, one for synchronization (two synchronizations are updated together), one for micro tasks, and one for macro tasks. And when you update the data with setTimeout, you will clearly see the process of the page data change. (this sentence is the point, remember the notebook.) this is why setTimeout is used as the last resort in the nextTick source code, giving priority to using micro-tasks.

Event cycle

Yes, it still has a lot to do with the event loop. I'll mention it here a little bit. For more details, you can take a look at exploring the JavaScript execution mechanism.

Because JavaScript is single-threaded, which determines that its tasks can not only be synchronous tasks, those time-consuming tasks if also executed according to synchronous tasks will lead to page blocking, so JavaScript tasks are generally divided into two types: synchronous tasks and asynchronous tasks, while asynchronous tasks are divided into macro tasks and micro tasks.

Macro tasks: script (overall code), setTimeout, setInterval, setImmediate, Icano, UI rendering

Micro tasks: promise.then, MutationObserver

Execution process

Synchronous tasks are directly put into the main thread for execution, while asynchronous tasks (click events, timers, ajax, etc.) are suspended in the background, waiting for the Ibig O event to complete or the behavior event to be triggered.

The system executes asynchronous tasks in the background, and if an asynchronous task event (or behavior event is triggered), the task is added to the task queue, and each task is processed with a callback function.

Here asynchronous tasks are divided into macro tasks and micro tasks. Macro tasks enter the macro task queue and micro tasks enter the micro task queue.

The tasks in the execution task queue are specifically completed in the execution stack. When all the tasks in the main thread are executed, read the micro-task queue. If there are any micro-tasks, they will all be executed, and then read the macro task queue.

The above process will be repeated over and over again, which is what we often call the "Event-Loop".

In general, in the event loop, the micro task is executed before the macro task. The micro task will enter the browser update rendering phase after the execution of the micro task, so using the micro task before the update rendering will be faster than the macro task, and one cycle is a tick.

In an event loop, microtask is fetched and fetched in this loop until the microtask queue is cleared, while macrotask is fetched one at a time.

If an asynchronous task is added to the execution of the event loop, if it is a macrotask, put it at the end of the macrotask and wait for the next loop to execute. If it is microtask, continue execution at the end of the microtask task in this event loop. Until the microtask queue is empty.

Source code goes deep into the asynchronous update queue

In Vue, DOM updates must be caused by data changes, so we can quickly find the entry to update DOM, that is, when set notifies watcher of updates through dep.notify

/ / watcher.js// when dependency changes, trigger update update () {if (this.lazy) {/ / lazy execution will go here, such as computed this.dirty = true} else if (this.sync) {/ / synchronous execution will go here, such as this.$watch () or watch option Pass a sync configuration {sync: true} this.run ()} else {/ / put the current watcher into the watcher queue, usually go here to queueWatcher (this)}

From here, we can find that vue defaults to the asynchronous update mechanism, which implements a queue to cache the watcher that needs to be updated.

/ / scheduler.js/* puts an observer object push into the observer queue. If the same id already exists in the queue, the observer object will be skipped unless it is pushed * / export function queueWatcher (watcher: Watcher) {/ * get the id*/ const id of watcher = watcher.id / * when the queue is refreshed to verify the existence of id. If it already exists, skip it directly. If it does not exist, it will be marked in has. For next verification * / if (has [id] = = null) {has [id] = true / / if flushing is false, indicating that the current watcher queue is not being refreshed, then the watcher directly enters the queue if (! flushing) {queue.push (watcher)} else {/ / if the watcher queue is already being refreshed At this point, if you want to insert a new watcher, you need special treatment / / to ensure that the new watcher refresh is still orderly. Let I = queue.length-1 while (I > = 0 & & queue [I] .id > watcher.id) {imurt -} queue.splice (Math.max (I, index) + 1, 0, watcher)} / / queue the flush if (! waiting) {/ / wating is false Indicates that there is no flushSchedulerQueue function waiting = true / / in the asynchronous task queue of the current browser. This is our common this.$nextTick nextTick (flushSchedulerQueue)}.

Ok, from which we can see that vue does not update the view immediately with data changes, but maintains a watcher queue, and id's repeated watcher only pushes the queue once, because we only care about the final data, not how many times it is updated. The watcher will not be removed from the queue until the next tick and the view will be updated.

NextTick

The purpose of nextTick is to generate a callback function to be added to task or microtask. After the execution of the current stack (there may be other functions in front of it), the callback function is called to trigger asynchronously (that is, when the next tick is triggered).

/ / next-tick.jsconst callbacks = [] let pending = false// batch function flushCallbacks () {pending = false const copies = callbacks.slice (0) callbacks.length = 0 / / execute the nextTick method for (let I = 0; I) sequentially

{if (cb) {try {cb.call (ctx)} catch (e) {handleError (e, ctx, 'nextTick')}} else if (_ resolve) {_ resolve (ctx)}}) / / because nextTick can be called internally, and users can also call nextTick But asynchronous if (! pending) {pending = true timerFunc ()} / / returns a promise instance after execution, which is why $nextTick can call the then method if (! cb & & typeof Promise! = = 'undefined') {return new Promise (resolve = > {_ resolve = resolve})}}

Compatibility handling, giving priority to promise.then elegant downgrade (compatibility processing is a process of constantly trying to use whoever can.

Vue internally tries to use native Promise.then, MutationObserver, and setImmediate for asynchronous queues, and uses setTimeout (fn, 0) instead if the execution environment does not support it.

/ / timerFunc / / promise.then-> MutationObserver-> setImmediate-> compatibility processing is no longer done in setTimeout// vue3 Promise.then wayward 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) | | / PhantomJS and iOS 7.x MutationObserver.toString () = ='[object MutationObserverConstructor]') {let counter = 1 const observer = new MutationObserver (flushCallbacks) / / can listen for DOM changes After listening, it is updated asynchronously / / but I don't want to use it for DOM snooping here. Instead, it takes advantage of the feature that 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 {/ / Fallback to setTimeout. TimerFunc = () = > {setTimeout (flushCallbacks, 0)}} $nextTick

The $nextTick we usually call is actually the above method, but it is convenient for us to use it by hanging it on the prototype of vue in the source code renderMixin.

Export function renderMixin (Vue) {/ / install runtime convenience helpers installRenderHelpers (Vue.prototype) Vue.prototype.$nextTick = function (fn) {return nextTick (fn, this)} Vue.prototype._render = function () {/ /...} / /.} summary general update DOM is synchronous

With all that has been said above, I believe you have a preliminary understanding of Vue's asynchronous update mechanism and the principle of $nextTick. There will be a page rendering at the end of each event cycle, and we know from the above that the rendering process is also a macro task. There may be a misunderstanding here, that is, the modification of DOM tree is synchronous, and only the rendering process is asynchronous, that is, we can get the updated DOM immediately after modifying the DOM. If you don't believe it, we can try it:

Document wants to try the world's fireworks, but how can he expect the vicissitudes of the world title.innerText = 'ten thousand volumes of poetry are useless, half-old ambition is left with madness' console.log ('updated',title)

Since updating DOM is a synchronous process, why does Vue need to borrow $nextTick to handle it?

The answer is obvious, because Vue is for performance considerations, Vue will cache the data modified synchronously by users, and wait for the synchronization code to be executed, which means that the data modification is over, and then the corresponding DOM will be updated. On the one hand, unnecessary DOM operations can be omitted, for example, if you modify a data multiple times at the same time, you only need to care about the last time. On the other hand, you can aggregate DOM operations to improve render performance.

It should be easier to understand if you look at the picture below.

Why give priority to microtasks?

There should be no need to say much about this, because micro tasks must have priority over macro tasks. If nextTick is a micro task, it will execute all micro tasks immediately after the execution of the current synchronization task, that is, the operation of modifying DOM will also be executed in the current tick. When the current round of tick tasks are completed, UI rendering execution will begin. If nextTick is a macro task, it will be pushed into the macro task queue and executed in a certain round after the current round of tick execution, note that it is not necessarily the next round, because you are not sure that there are fewer macro tasks waiting in the macro task queue. So in order to update the DOM,Vue as soon as possible, the priority is the micro task, and in Vue3, it does not have the compatibility judgment, it directly uses the microtask, no longer considering the macro task.

Read here, this article "Vue asynchronous update mechanism and what is the principle of $nextTick" article has been introduced, want to master the knowledge of this article still need to practice and use to understand, if you want to know more about the article, welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.