Dynamic node collection and patch flags
1. Problems with traditional diff algorithms
For a normal template file, if only the content in the tag has changed, the easiest way to update is obviously to directly replace the text content in the tag. But the diff algorithm obviously cannot do this, it will regenerate a virtual DOM tree and then compare the two virtual DOM trees. It is obvious that compared with directly replacing the content in the tag, the traditional diff algorithm requires a lot of meaningless operations. If these meaningless operations can be removed, it will save a lot of performance overhead. In fact, as long as the template is compiled, which nodes are dynamic and which are static, and then passed to the renderer through the virtual DOM, the renderer can directly modify the corresponding nodes based on this information, thereby improving runtime performance.
and PatchFlags
For a traditional template:
<div>
<div>
foo
</div>
<p>
{{ bar }}
</p>
</div>
In this template, use only {{ bar }} is dynamic content, so when the bar variable changes, you only need to modify the content in the p tag. Therefore, we add patchFlag attribute to the virtual DOM of this template to label the dynamic content in the template.
const vnode = {
tag: 'div',
children: [
{ tag: 'div', children: 'foo' },
{ tag: 'p', children: , patchFlag: 1 },
]
}
For different numerical bindings, we use different patch values to express them:
- The number 1 represents the dynamic textContent of the node.
- Number 2 represents dynamic class binding for nodes
- Number 3 represents the dynamic style binding of the node
- Number 4, other…
We can create a new enum type to represent these values:
enum PatchFlags {
TEXT: 1,
CLASS,
STYLE,
OTHER
}
In this way, we extract the dynamic nodes in the creation stage of the virtual DOM:
const vnode = {
tag: 'div',
children: [
{ tag: 'div', children: 'foo' },
{ tag: 'p', children: , patchFlag: },
],
dynamicChildren: [
{ tag: 'p', children: , patchFlag: },
]
}
3. Collect dynamic nodes
First we create logic that collects dynamic nodes.
const dynamicChildrenStack = []; // Dynamic node stacklet currentDynamicChildren = null; // Current dynamic node collectionfunction openBlock() {
// Create a new dynamic node stack ((currentDynamicChildren = []));
}
function closeBlock() {
// Dynamic node collection created by openBlock pops up currentDynamicChildren = ();
}
Then, when we create a virtual node, we collect dynamic nodes.
function createVNode(tag, props, children, flags) {
const key = props && ;
props && delete ;
const vnode = {
tag,
props,
children,
key,
patchFlags: flags
}
if(typeof flags !== 'undefined' && currentDynamicChildren) {
(vnode);
}
return vnode;
}
Then we modify the logic of the component rendering function.
render() {
return (openBlock(), createBlock('div', null, [
createVNode('p', { class: 'foo' }, null, 1),
createVNode('p', { class: 'bar' }, null)
]));
}
function createBlock(tag, props, children) {
const block = createVNode(tag, props, children);
= currentDynamicChildren;
closeBlock();
return block;
}
4. Renderer runtime support
function patchElement(n1, n2) {
const el = = ;
const oldProps = ;
const newProps = ;
// ...
if() {
// If there is a dynamic node array, directly update the dynamic node array patchBlockChildren(n1, n2);
} else {
patchChildren(n1, n2, el);
}
}
function pathcBlockChildren(n1, n2) {
for(let i = 0; i < ; i++) {
patchElement([i], [i]);
}
}
Since we tag different dynamic node types, we can complete targeted updates in a targeted manner.
function patchElement(n1, n2) {
const el = = ;
const oldProps = ;
const newProps = ;
if() {
if( === 1) {
// Update only content } else if( === 2) {
// Update class only } else if( === 3) {
// Only update style } else {
// Update all for(const k in newProps) {
if(newProps[key] !== oldProps[key]) {
patchProps(el, key, oldProps[k], newProps[k]);
}
}
for(const k in oldProps) {
if(!key in newProps) {
patchProps(el, key, oldProps[k], null);
}
}
}
}
patchChildren(n1, n2, el);
}
Tree
The root node of the component must be a Block role, so that all dynamic child nodes starting from the root node will be collected into the dynamicChildren array of the root node. In addition to the root node, nodes with structured instructions such as v-if and v-for are also used as Block roles, which together form a Block tree.
Static boost
Assume that the following template is
<div>
<p>
static text
</p>
<p>
{{ title }}
</p>
</div>
By default, the corresponding rendering function is:
function render() {
return (openBlock(), createBlock('div', null, [
createVNode('p', null, 'static text'),
createVNode('p', null, , 1 /* TEXT */)
]))
}
In this code, when the properties change, the p-tagged node with the content of static text will also be rendered once, which is obviously unnecessary. Therefore, we can use "static lifting", that is, extracting static nodes outside the rendering function, so that when the rendering function is executed, it only maintains a reference to the static node without recreating the virtual node.
const hoist1 = createVNode('p', null, 'static text');
function render() {
return (openBlock(), createBlock('div', null, [
hoist1,
createVNode('p', null, , 1 /* TEXT */)
]))
}
In addition to static nodes, we can also statically promote static props.
const hoistProps = { foo: 'bar', a: '1' };
function render() {
return (openBlock(), createBlock('div', null, [
hoist1,
createVNode('p', hoistProps, , 1 /* TEXT */)
]))
}
Pre-characterization
In addition to statically improving nodes, we can also pre-characterize purely static templates. For such a template:
<templete>
<p></p>
<p></p>
<p></p>
<p></p>
<p></p>
...
<p></p>
<p></p>
<p></p>
<p></p>
</templete>
We can completely preprocess it as:
const hoistStatic = createStaticVNode('<p></p><p></p><p></p><p></p>...<p></p><p></p><p></p><p></p>')；
render() {
return (openBlock(), createBlock('div', null, [
hoistStatic
]));
}
Advantages of doing this:
- Large chunks of static content can be directly set through innerHTML, which has certain performance advantages.
- Reduce the extra overhead of creating virtual nodes
- Reduce memory usage
Cache inline event handling functions
When adding inline events to a component, each time a new component is created, a new inline event function will be recreated and bound to the component. In order to avoid this meaningless overhead, we can cache the inline event handler function.
function render(ctx, cache) {
return h(Comp, {
onChange: cache[0] || cache[0] = ($event) => ( + );
})
}
v-once
The v-once directive can be that the component is rendered only once and will not be updated even if the component is bound to dynamic parameters. Like inline events, it also uses cache, and at the same time, it prevents the VNode from being collected by Block through setBlockTracking(-1).
Advantages of v-once:
- Avoid performance overhead of recreating virtual DOM when component updates
- Avoid useless Diff overhead
This is the end of this article about the detailed explanation of the implementation process of Vue compilation optimization. For more related content on Vue compilation optimization, please search for my previous articles or continue browsing the related articles below. I hope everyone will support me in the future!