preface

“What’s the advantage of Virtual Dom?” This is a common interview question, but is the answer really simply “direct dom manipulation versus frequent DOM manipulation has poor performance”? If so, go ahead and ask a few more questions:

  • Why does direct Dom manipulation have poor performance?

  • What exactly does the Virtual Dom stand for? How is it implemented?

  • Why does Virtual Dom avoid the problems caused by direct Dom manipulation?

If you find yourself lian and meng unsure about these questions, read on.

The body of the

The Virtual Dom, also known as the Virtual Dom, is useful in React and Vue. It is not in itself a design unique to any technology stack, but rather a design idea, or design pattern.

DOM

Before introducing the virtual DOM, let’s first look at its real counterpart:

DOM(Document Object Model) has two meanings:

  1. Object-based document model (the object-based representation);
  2. Apis for manipulating these objects;

This HTML code looks like the following,

<! DOCTYPEhtml>
<html lang="en">
<head>
    <title>Document</title>
</head>
<body>
    <h1>Learning Virtual Dom</h1>
    <ul class="list">
        <li class="list-item">List item</li>
    </ul>
</body>
</html>
Copy the code

According to the DOM, it is represented as a tree: each branch of the tree ends in a node, and each node contains objects, including some node attributes. This is representing documents based on objects.

Second, DOM allows us to manipulate documents through a number of apis, such as:

const listItemOne = document.getElementsByClassName("list-item") [0]; // Get the node
listItemOne.textContent = "List item one"; // Modify the corresponding text content
const listItemTwo = document.createElement("li"); // Create an element object
listItemTwo.classList.add("list-item"); // Add child elements
listItemTwo.textContent = "List item two";
list.appendChild(listItemTwo);
Copy the code

In a nutshell. The DOM’s job is to associate a Web page with ascript (usually Javascript).

Performance issues associated with DOM manipulation

So what are the problems with native DOM manipulation? There are also some steps you need to take to understand how the browser works. Generally speaking, a page is generated through the following steps:

  1. Parsing HTML to produce the corresponding DOM tree;
  2. Parse the CSS and generate the corresponding CSS tree.
  3. Combine results 1 and 2 to generate a render tree;
  4. Generate page layout arrangement (flow)
  5. Draw the layout to the display device (Paint)

In fact, the fourth and fifth steps are often referred to as page rendering. In addition to the process of rendering, DOM operations will also cause rearrangement and redrawing in the subsequent interaction process. Rendering requires high performance costs, especially the process of rearrangement.

So common optimization ideas will mention a point: To minimize the number of redraws and rearrangements, try to keep dom changes together because writes trigger redraws or rearrangements, ** and the browser’s rendering queue mechanism is: When an action triggers a reorder or redraw, the action is placed in the render queue, and when the number of actions in the queue reaches a certain amount of time, the browser executes them in batches. ** So centralized DOM manipulation can reduce the number of redraws and rearrangements.

On the other hand, regarding the scope of DOM operations: Because the browser is based on the current layout, so once an element rearrangement, its internal node will be affected, and external node (brother nodes and the parent node, etc.) it is possible to not affected, the effect of the local rearrangement cause is small, so also need a time as possible changes need most node element.

An overview of the Virtual DOM

The Virtual DOM was created to solve this problem by giving us a new way to manipulate the DOM.

The virtual DOM is essentially a copy of the real DOM,This copy can be manipulated and updated frequently without using the DOM API. After all the updates to the virtual DOM are made, we can see what specific changes need to be made to the original DOM and make them in a targeted and optimized way.

This idea can be referenced to the sand table during marching. One of the functions of the sand table is to simulate the arrangement and distribution of troops. Imagine the scene without the sand table:

General 1: I think the soldiers of the third company should move 200 meters to the east, flank the ambush, and then the herald ran to inform the soldiers of the third company.

General 2: I think the soldiers of Company 4 should move 200 meters to the west and form a close circle with Company 3. Then the herald will continue to announce and the soldiers of company 4 will continue to run.

General 3: I think the distance of ambush is too far. It’s better to be closer. Let’s move both teams 100 meters to the center.

Then the poor soldiers kept running back and forth….

In this process, every move on the march will bring a lot of expense, and every time the direct implementation of the instructions that are still being discussed with actual actions, the cost is very high. As a matter of fact, while the generals discuss their arrangements, yes

  • We’re going to do a simulated arrangement on the sand table,
  • When the ideal phalanx is reached, the soldiers under his command are informed to adjust accordingly.

That’s what the Virtual DOM does.

Simplified implementation of the Virtual DOM

So what does the Virtual DOM look like? The corresponding Virtual DOM looks something like this (it does not represent the implementation of the actual technology stack, just the core idea) :

const vdom = {
    tagName: "html"./ / the root node
    children: [{tagName: "head" },
        {
            tagName: "body".children: [{tagName: "ul".attributes: { "class": "list" },
                    children: [{tagName: "li".attributes: { "class": "list-item" },
                            textContent: "List item"
                        } // end li]}// end ul]}// end body]}// end html
Copy the code

We use a NESTED object tree of JS to represent the hierarchy of dom tree and some core attributes, and children represents the child node. We made some updates to ul using the native DOM in the previous section, and now use the Virtual DOM to implement this process:

  1. A copy of the virtual DOM for the current real DOM and the desired virtual DOM;
const originalDom = {
   tagName: "html"./ / the root node
   children: [
   // omit the intermediate node
     {
        tagName: "ul".attributes: { "class": "list" },
        children: [{tagName: "li".attributes: { "class": "list-item" },
                textContent: "List item"}]}],}const newDom = {
   tagName: "html"./ / the root node
   children: [
     // omit the intermediate node
      {
        tagName: "ul".attributes: { "class": "list" },
        children: [{tagName: "li".attributes: { "class": "list-item" },
                textContent: "List item one" // Change 1, the text of the first child node
            },
            {// Change 2, add a second node
                tagName: "li".attributes: { "class": "list-item" },
                textContent: "List item two"}]}],};Copy the code
  1. The comparison difference
const diffRes = [
    {
      newNode: {/* corresponds to the child node 1*/ of ul above},oldNode: {/* Corresponds to originalUl's child node 1*/ above}, {},newNode: {/* corresponds to the child node 2*/ of ul above},// This is a new node, so there is no oldNode},]Copy the code
  1. After collecting the difference results, it is found that as long as the list node is updated, the pseudo-code is roughly as follows:
const domElement = document.getElementsByClassName("list") [0];
diffRes.forEach((diff) = > {
    const newElement = document.createElement(diff.newNode.tagName);
    /* Add attributes ... * /
    
    if (diff.oldNode) {
        // Replace oldNode if it exists
        domElement.replaceChild(diff.newNode, diff.index);
    } else {
        // If it does not exist, add it directlydomElement.appendChild(diff.newNode); }})Copy the code

Of course, the actual diff processes in frameworks like Vue and React are much more sophisticated than that. For example:

For ul with multiple items, adding a new node to append may cause changes to all ul nodes. This change cost is too high. If encountered in the diff process, it may be implemented in another way, directly using JS to generate a new UL object, and then replace the original UL. These will (probably) be covered in more detail in a future article on the individual technology stacks.

As you can see, the core idea of the Virtual DOM is to make the expected changes in the Virtual DOM node first, and finally apply them to the real DOM. This operation reduces the probability of redrawing and rearranging to some extent, because it does:

  1. Put the actual DOM changes after the diff process, which can be calculated to reduce unnecessary changes (as in the previous general 3 command, the actual movement of soldiers is actually less);
  2. For the last necessary DOM operations, they are also processed together to fit the browser rendering mechanism and reduce the number of rearrangements.

Summary: Answer the first question

Now let’s return to our opening question — “What are the advantages of Virtual Dom?”

Before we answer this question, we also need to know:

  1. First, the BROWSER’s DOM engine and JS engine are independent of each other, but share the main thread.
  2. JS code calling DOM API must suspend JS engine, activate DOM engine, DOM redraw and rearrange, then activate JS engine and continue execution;
  3. If there are frequent DOM API calls, browser vendors do not do “batch processing” optimization, so switching overhead and redrawing overhead will be large;

The key point of Virtual Dom is to put the Dom changes that need to be made in the JS engine for calculation. When all Dom changes are collected during a certain period, the benefits of this method are as follows:

  1. Reduce the overhead caused by frequent switching between DOM engine and JS engine;
  2. Maybe after calculation and comparison, only local changes are needed in the end, and many unnecessary redrawing and rearrangement can be reduced.
  3. Do necessary Dom operations together as much as possible to reduce the number of rearrangements

conclusion

Starting from a common interview question, this article introduces the concept of Dom and Virtual Dom, as well as the possible problems of directly operating Dom, and illustrates the advantages of Virtual Dom by comparison. For the Virtual Dom diff process in the specific technology stack and the way of optimization processing, there is no more explanation, more focus on the concept of Virtual Dom itself.

Welcome everyone to pay attention to the column, but also hope that everyone for the favorite article, can not hesitate to like and collect, for the writing style and content of any opinion, welcome private communication.