Write in front
Because I am very interested in it, and the technology stack I work in my daily life is the same. I have spent some time studying and learning the source code in the past few months, and have summarized and output it.
Original address of the article:/answershuto/learnVue。
During the learning process, Vue was added with Chinese annotations/answershuto/learnVue/tree/master/vue-src, I hope it can be helpful to other friends who want to learn Vue source code.
There may be some deviations in understanding. Please note that you should learn together and make progress together.
Operate DOM
When using it, sometimes you have to operate the DOM due to some specific business scenarios, such as this:
<template>
<div>
<div ref="test">{{test}}</div>
<button @click="handleClick">tet</button>
</div>
</template>
export default {
data () {
return {
test: 'begin'
};
},
methods () {
handleClick () {
= 'end';
(this.$);//Print "begin" }
}
}
The result of printing is begin. Why do we get the innerText of the real DOM node without getting the "end" we expected, but instead get the previous value "begin"?
Watcher queue
With doubts, we found the Watch implementation of the source code. When a certain responsive data changes, its setter function will notify Dep in the closure, and Dep will call all Watch objects it manages. Triggers the update implementation of the Watch object. Let's take a look at the implementation of update.
update () {
/* istanbul ignore else */
if () {
= true
} else if () {
/*Synchronously execute run to render the view directly*/
()
} else {
/*Pushed asynchronously to the observer queue and is called when the next tick is next. */
queueWatcher(this)
}
}
We found that the default is to useExecute DOM updates asynchronously。
When the update is executed asynchronously, the queueWatcher function will be called.
/*Push an observer object into the observer queue. If the same id already exists in the queue, the observer object will be skipped unless it is pushed when the queue is refreshed*/
export function queueWatcher (watcher: Watcher) {
/*Get the watcher's id*/
const id =
/* Check whether the id exists. If it already exists, it will be skipped directly. If it does not exist, it will be marked with the hash table has for the next check*/
if (has[id] == null) {
has[id] = true
if (!flushing) {
/*If there is no flush, just push it to the queue*/
(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 = - 1
while (i >= 0 && queue[i].id > ) {
i--
}
((i, index) + 1, 0, watcher)
}
// queue the flush
if (!waiting) {
waiting = true
nextTick(flushSchedulerQueue)
}
}
}
Looking at the source code of queueWatcher, we found that the Watch object does not update the view immediately, but is pushed into a queue queue. At this time, the state is in the waiting state. At this time, the Watch object will continue to be pushed into this queue queue. When waiting for the next tick, these Watch objects will be traversed and taken out to update the view. At the same time, the watcher with duplicate id will not be added to the queue multiple times, because when the final rendering is finally rendered, we only need to care about the final result of the data.
So, what is the next tick?
nextTick
Provides anextTickThe function is actually the nextTick called above.
The implementation of nextTick is relatively simple. The purpose of execution is to push a function into the microtask or task. After the current stack is executed (and there will be some tasks that need to be executed first), execute the function passed in nextTick. Take a look at the source code:
/**
* Defer a task to execute it asynchronously.
*/
/*
Delay a task to execute asynchronously, execute on the next tick, execute a function immediately, return a function
The function of this function is to push a timerFunc into the task or microtask, and execute it after the current call stack is executed until it is executed to timerFunc
The purpose is to delay execution until the current call stack has been executed.
*/
export const nextTick = (function () {
/*Storing callbacks executed asynchronously*/
const callbacks = []
/*A tag bit, if timerFunc is already pushed to the task queue, there is no need to push it repeatedly*/
let pending = false
/*A function pointer, pointer, will be pushed to the task queue, and when the main thread task is executed, the timerFunc in the task queue is called*/
let timerFunc
/*Callback at next tick*/
function nextTickHandler () {
/*A tag bit marks the waiting state (that is, the function has been pushed into the task queue or the main thread, and is already waiting for the current stack to be executed to be executed), so there is no need to push timerFunc into the task queue or the main thread multiple times when pushing multiple callbacks to callbacks*/
pending = false
/*Execute all callback*/
const copies = (0)
= 0
for (let i = 0; i < ; i++) {
copies[i]()
}
}
// the nextTick behavior leverages the microtask queue, which can be accessed
// via either native 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 */
/*
Here we explain, there are three methods to try to get timerFunc: Promise, MutationObserver and setTimeout
Promise is preferred. MutationObserver is used when Promise does not exist. Both methods will be executed in microtask and will be executed earlier than setTimeout, so they are preferred.
If the environment that neither of the above methods supports, setTimeout will be used, and this function will be pushed into the tail of the task, waiting for the call to execute.
*/
if (typeof Promise !== 'undefined' && isNative(Promise)) {
/*Use Promise*/
var p = ()
var logError = err => { (err) }
timerFunc = () => {
(nextTickHandler).catch(logError)
// in problematic UIWebViews, 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, . handle a timer. Therefore we can
// "force" the microtask queue to be flushed by adding an empty timer.
if (isIOS) setTimeout(noop)
}
} else if (typeof MutationObserver !== 'undefined' && (
isNative(MutationObserver) ||
// PhantomJS and iOS
() === '[object MutationObserverConstructor]'
)) {
// use MutationObserver where native Promise is not available,
// . PhantomJS IE11, iOS7, Android 4.4
/* Create a new textNode DOM object, bind the DOM with MutationObserver and specify the callback function. When the DOM changes, the callback will be triggered. The callback will enter the main thread (execute priority over the task queue), that is, the callback will be triggered when = String(counter)*/
var counter = 1
var observer = new MutationObserver(nextTickHandler)
var textNode = (String(counter))
(textNode, {
characterData: true
})
timerFunc = () => {
counter = (counter + 1) % 2
= String(counter)
}
} else {
// fallback to setTimeout
/* istanbul ignore next */
/* Use setTimeout to push the callback to the tail of the task queue*/
timerFunc = () => {
setTimeout(nextTickHandler, 0)
}
}
/*
Execute when pushing to the next tick in the queue
cb callback function
ctx context
*/
return function queueNextTick (cb?: Function, ctx?: Object) {
let _resolve
/*cb saved in callbacks*/
(() => {
if (cb) {
try {
(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
})
}
}
})()
It is an immediate execution function that returns a queueNextTick interface.
The passed cb will be pushed into callbacks and then executed timerFunc (pending is a status tag, ensuring that timerFunc will only be executed once before the next tick).
What is timerFunc?
After reading the source code, I found that timerFunc will detect the current environment and implement it differently. In fact, it is based on the priority of Promise, MutationObserver, setTimeout, which one exists and which one is used, and in the least effective environment, use setTimeout.
Let me explain here that there are three methods to try to get timerFunc: Promise, MutationObserver and setTimeout.
Promise is preferred, and MutationObserver is used when Promise does not exist. The callback functions of these two methods will be executed in microtask, and they will be executed earlier than setTimeout, so they will be used first.
If the environment that neither of the above methods supports, setTimeout will be used, and this function will be pushed into the tail of the task, waiting for the call to execute.
Why should we prioritize microtask? I learned from Gu Yiling’s answer:
When executing the event loop of JS, the task and microtask will be distinguished. After each task is executed, the engine will execute all microtasks in the microtask queue before taking a task from the queue to execute.
The setTimeout callback will be assigned to execute in a new task, and the Promise resolver and MutationObserver callbacks will be arranged to execute in a new microtask, which will be executed before the task generated by setTimeout.
To create a new microtask, use Promise first, and try MutationObserver if the browser does not support it.
If it really doesn't work, you can only create a task with setTimeout.
Why use microtask?
According to HTML Standard, after each task is run, the UI will be re-rendered, so the data update is completed in the microtask, and the latest UI can be obtained when the task is completed.
On the contrary, if a new task is created to update the data, the rendering will be performed twice.
Refer to Gu Yiling Zhihu's answer
First of all, Promise, (()).then() can add its callback in microtask.
MutationObserver creates a new DOM object of textNode, binds the DOM with MutationObserver and specifies the callback function. When the DOM changes, a callback will be triggered. The callback will enter microtask, that is, the callback will be added when = String(counter).
setTimeout is the last alternative, which adds the callback function to the task and waits until execution.
In summary, the purpose of nextTick is to generate a callback function to join the task or microtask. After the current stack is executed (there may be other functions in the middle) call the callback function, which serves the purpose of asynchronous triggering (that is, triggering when the next tick).
flushSchedulerQueue
/*Github:/answershuto*/
/**
* Flush both queues and run the watchers.
*/
/*nextTick's callback function, flush two queues when the next tick is running watchers at the same time*/
function flushSchedulerQueue () {
flushing = true
let watcher, id
// Sort queue before flush.
// This ensures that:
// 1. Components are updated from parent to child. (because parent is always
// created before the child)
// 2. A component's user watchers are run before its render watcher (because
// user watchers are created before the render watcher)
// 3. If a component is destroyed during a parent component's watcher run,
// its watchers can be skipped.
/*
Sorting the queue, doing this ensures:
1. The order of component updates is from parent component to child component, because parent components are always created before child components.
2. A component's user watchers run first than the render watcher, because user watchers are often created earlier than the render watcher
3. If a component is destroyed during the parent component watcher runs, its watcher execution will be skipped.
*/
((a, b) => - )
// do not cache length because more watchers might be pushed
// as we run existing watchers
/*There is no way to write index = ;index > 0; index-- because length is not cached, because during the execution of processing existing watcher objects, more watcher objects may be pushed into queue*/
for (index = 0; index < ; index++) {
watcher = queue[index]
id =
/*Delete the has tag*/
has[id] = null
/*Execute watcher*/
()
// in dev build, check and stop circular updates.
/*
In the test environment, check whether the watch is in a dead loop
For example, in this case
watch: {
test () {
++;
}
}
Continuously executing a watch for a hundred times means there may be a dead loop
*/
if (.NODE_ENV !== 'production' && has[id] != null) {
circular[id] = (circular[id] || 0) + 1
if (circular[id] > MAX_UPDATE_COUNT) {
warn(
'You may have an infinite update loop ' + (
? `in watcher with expression "${}"`
: `in a component render function.`
),
)
break
}
}
}
// keep copies of post queues before resetting state
/**/
/*Get the copy of the queue*/
const activatedQueue = ()
const updatedQueue = ()
/*Reset the scheduler's status*/
resetSchedulerState()
// call component updated and activated hooks
/*Adap the child component states to active and call the activated hook at the same time*/
callActivatedHooks(activatedQueue)
/*Calling updated hook*/
callUpdateHooks(updatedQueue)
// devtool hook
/* istanbul ignore if */
if (devtools && ) {
('flush')
}
}
flushSchedulerQueue is a callback function when the next tick. Its main purpose is to execute the Watcher run function to update the view
Why do you need to update views asynchronously
Take a look at the following code
<template>
<div>
<div>{{test}}</div>
</div>
</template>
export default {
data () {
return {
test: 0
};
},
created () {
for(let i = 0; i < 1000; i++) {
++;
}
}
}
Now there is a situation where the value of test will be executed 1000 times when created.
Every time ++, setter->Dep->Watcher->update->patch will be triggered according to the responsive method.
If the view is not updated asynchronously at this time, then every time ++, it will directly operate the DOM to update the view, which is very performance-consuming.
Therefore, a queue queue is implemented, and the run of the Watcher in the queue will be executed uniformly when the next tick is next. At the same time, a Watcher with the same id will not be added to the queue repeatedly, so the Watcher run will not be executed 1000 times. The final update view will only directly change the 0 of the DOM corresponding to the test to 1000.
The action of updating the view operation DOM is called when the next tick is completed after the current stack is executed, greatly optimizing performance.
Access the updated data of the real DOM node
So we need to access the updated data of the real DOM node after modifying the data in data. Just like this, we modify the first example of the article.
<template>
<div>
<div ref="test">{{test}}</div>
<button @click="handleClick">tet</button>
</div>
</template>
export default {
data () {
return {
test: 'begin'
};
},
methods () {
handleClick () {
= 'end';
this.$nextTick(() => {
(this.$);//Print "end" });
(this.$);//Print "begin" }
}
}
The $nextTick method of the global API used can obtain the updated DOM instance in the callback.
The above is all the content of this article. I hope it will be helpful to everyone's study and I hope everyone will support me more.