How to implement responsiveness in Vue source code learning

Preface
1. Key Elements of a Responsive System

1. How to monitor data changes
2. How to collect dependencies - implement Dep class
3. How to update when data changes - Implementing the Watcher class

2. Virtual DOM and diff

1. What is Virtual DOM?
2. Diff algorithm - comparison between new and old nodes

3. nextTick

IV. Conclusion

Preface

As front-end developers, our daily work is to render data to the page and handle user interactions. In Vue, the page will be re-rendered when the data changes. For example, we display a number on the page with a click button next to it. Every time we click the button, the number displayed on the page will increase by one. How can we achieve this?
According to the logic of native JS, we should do three things: listen to click events, modify data in the event processing function, and then manually modify the DOM to re-render. The biggest difference between this and our use of Vue is that there is one more step [manually modify the DOM to re-render]. This step seems simple, but we have to consider several issues:

Which DOM needs to be modified?
Do I need to modify the DOM every time the data changes?
How to ensure the performance of modifying DOM?

So it is not easy to implement a responsive system. Let's learn the excellent ideas in Vue by combining Vue source code~

1. Key Elements of a Responsive System

1. How to monitor data changes

Obviously, it is very cumbersome to obtain data changes by monitoring all user interaction events, and some data changes may not be triggered by users. So how does Vue monitor data changes? ——Object.defineProperty

Why can the Object.defineProperty method monitor data changes? This method can directly define a new property on an object, or modify an existing property of an object, and return the object. Let's take a look at its syntax first:

Object.defineProperty(obj, prop, descriptor)
// obj is the object passed in, prop is the property to be defined or modified, descriptor is the property descriptor

The core here is the descriptor, which has many optional key values. What we are most concerned about here are get and set. Get is a getter method provided for a property. When we access the property, the getter method will be triggered; set is a setter method provided for a property. When we modify the property, the setter method will be triggered.

In short, once a data object has getters and setters, we can easily monitor its changes and call it a responsive object. How to do it specifically?

function observe(data) {
  if (isObject(data)) {
    Object.keys(data).forEach(key => {
      defineReactive(data, key)
    })
  }
}

function defineReactive(obj, prop) {
  let val = obj[prop]
  let dep = new Dep() // Used to collect dependenciesObject.defineProperty(obj, prop, {
    get() {
      // Accessing object properties indicates that the current object properties are dependent and the dependencies are collected dep.depend()
      return val
    }
    set(newVal) {
      if (newVal === val) return
      // The data has been modified, it's time to notify relevant personnel to update the corresponding views val = newVal
      dep.notify()     
    }
  }) 
  // Deep monitoring if (isObject(val)) {
    observe(val)
  }
  return obj
}

Here we need a Dep class (dependency) to do dependency collection🎭

PS: Object.defineProperty can only monitor existing properties, but it is powerless for newly added properties. It also cannot monitor changes in arrays (this problem is solved in Vue2 by rewriting the method on the array prototype), so it is replaced with a more powerful Proxy in Vue3.

2. How to collect dependencies - implement Dep class

Based on the constructor implementation:

function Dep() {
  // Use the deps array to store various dependencies this.deps = []
}
// Dep.target is used to record the running watcher instance, which is a globally unique Watcher 
// This is a very clever design, because JS is single-threaded, only one global Watcher can be calculated at the same time Dep.target = null

// Define the depend method on the prototype, and each instance can access it Dep.prototype.depend = function() {
  if (Dep.target) {
    this.deps.push(Dep.target)
  }
}
// Define the notify method on the prototype to notify the watcher to update Dep.prototype.notify = function() {
  this.deps.forEach(watcher => {
    watcher.update()
  })
}
// There will be nested logic in Vue, such as component nesting, so use the stack to record the nested watcher 
// Stack, first in, last out const targetStack = [] 
function pushTarget(_target) { 
  if (Dep.target) targetStack.push(Dep.target) 
  Dep.target = _target 
} 
function popTarget() { 
  Dep.target = targetStack.pop() 
}

Here we mainly understand two methods on the prototype: depend and notify, one for adding dependencies and the other for notifying updates. We talk about collecting "dependencies", so what exactly is stored in the this.deps array? Vue sets up the concept of Watcher for dependency representation, that is, what is collected in this.deps are Watchers.

3. How to update when data changes - Implementing the Watcher class

There are three types of Watcher in Vue, which are used for page rendering and the two APIs computed and watch. In order to distinguish them, Watchers with different uses are called renderWatcher, computedWatcher and watchWatcher respectively.

Implement it with class:

class Watcher {
  constructor(expOrFn) {
    // When the parameter passed in here is not a function, it needs to be parsed, parsePath is omitted this.getter = typeof expOrFn === 'function' ? expOrFn : parsePath(expOrFn)
    this.get()
  }
  // There is no need to write function when defining functions in class
  get() {
    // At this point in the execution, this is the current watcher instance and also Dep.target
    pushTarget(this)
    this.value = this.getter()
    popTarget()
  }
  update() {
    this.get()
  }
}

At this point, a simple responsive system has taken shape. In summary: Object.defineProperty allows us to know who accesses the data and when the data changes, Dep can record which DOMs are related to a certain data, and Watcher can notify the DOM to update when the data changes.
Watcher and Dep are an implementation of a very classic observer design pattern.

2. Virtual DOM and diff

1. What is Virtual DOM?

Virtual DOM uses objects in JS to represent the real DOM. If there is a data change, change it on the virtual DOM first, and then change the real DOM. Good idea! 💡

Regarding the advantages of virtual DOM, it is better to listen to Youda:

In my opinion, the real value of Virtual DOM has never been performance, but that it 1) opens the door to functional UI programming; 2) can render to a backend other than DOM.

For example:

<template>
  <div id="app" class="container">
    <h1>HELLO WORLD! </h1>
  </div>
</template>

// Corresponding vnode 
{ 
  tag: 'div', 
  props: { id: 'app', class: 'container' }, 
  children: { tag: 'h1', children: 'HELLO WORLD! ' } 
}

We can define it like this:

function VNode(tag, data, childern, text, elm) { 
  this.tag = tag 
  this.data = data 
  this.childern = childern 
  this.text = text 
  this.elm = elm // reference to the real node}

2. Diff algorithm - comparison between new and old nodes

When the data changes, the rendering watcher callback is triggered and the view is updated. In the Vue source code, the patch method is used to compare the similarities and differences between new and old nodes when updating the view.

(1) Determine whether the new and old nodes are the same nodes

function sameVNode()
function sameVnode(a, b) { 
  return a.key === b.key && 
  ( a.tag === b.tag && 
    a.isComment === b.isComment && 
    isDef(a.data) === isDef(b.data) && 
    sameInputType(a, b) 
  ) 
 }

(2) If the new and old nodes are different

Replace the old node: create a new node --> delete the old node

(3) If the new and old nodes are the same

There are no child nodes, so it's easy to say
One has child nodes and the other does not. It's easy to say, either delete the child node or add a new child node.
All have child nodes, which is a bit complicated. Execute updateChildren:

function updateChildren (parentElm, oldCh, newCh, insertedVnodeQueue, removeOnly) {
  let oldStartIdx = 0
  let newStartIdx = 0
  let oldEndIdx = oldCh.length - 1
  let oldStartVnode = oldCh[0]
  let oldEndVnode = oldCh[oldEndIdx]
  let newEndIdx = newCh.length - 1
  let newStartVnode = newCh[0]
  let newEndVnode = newCh[newEndIdx]
  let oldKeyToIdx, idxInOld, vnodeToMove, refElm
  // The above are the head and tail pointers of the new and old Vnodes, the head and tail nodes of the new and old Vnodes while (oldStartIdx <= oldEndIdx && newStartIdx <= newEndIdx) {
    // If the while condition is not met, it means that at least one of the old and new Vnodes has been traversed once, and then exit the loop if (isUndef(oldStartVnode)) {
      oldStartVnode = oldCh[++oldStartIdx] // Vnode has been moved left
    } else if (isUndef(oldEndVnode)) {
      oldEndVnode = oldCh[--oldEndIdx]
    } else if (sameVnode(oldStartVnode, newStartVnode)) {
      // Compare the old start and the new start to see if they are the same node patchVnode(oldStartVnode, newStartVnode, insertedVnodeQueue)
      oldStartVnode = oldCh[++oldStartIdx]
      newStartVnode = newCh[++newStartIdx]
    } else if (sameVnode(oldEndVnode, newEndVnode)) {
      // Compare the old and new ends to see if they are the same node patchVnode(oldEndVnode, newEndVnode, insertedVnodeQueue)
      oldEndVnode = oldCh[--oldEndIdx]
      newEndVnode = newCh[--newEndIdx]
    } else if (sameVnode(oldStartVnode, newEndVnode)) { // Vnode moved right
      // Compare the old start and the new end to see if they are the same node patchVnode(oldStartVnode, newEndVnode, insertedVnodeQueue)
      canMove && nodeOps.insertBefore(parentElm, oldStartVnode.elm, nodeOps.nextSibling(oldEndVnode.elm))
      oldStartVnode = oldCh[++oldStartIdx]
      newEndVnode = newCh[--newEndIdx]
    } else if (sameVnode(oldEndVnode, newStartVnode)) { // Vnode moved left
      // Compare the old end and the new beginning to see if they are the same node patchVnode(oldEndVnode, newStartVnode, insertedVnodeQueue)
      canMove && nodeOps.insertBefore(parentElm, oldEndVnode.elm, oldStartVnode.elm)
      oldEndVnode = oldCh[--oldEndIdx]
      newStartVnode = newCh[++newStartIdx]
    } else {
      // The difference between setting a key and not setting a key:
      // Without setting the key, newCh and oldCh will only compare the head and tail. After setting the key, in addition to the comparison between the head and tail, the matching node will be found from the object oldKeyToIdx generated by the key. Therefore, setting keys for nodes can make more efficient use of DOM.
      if (isUndef(oldKeyToIdx)) oldKeyToIdx = createKeyToOldIdx(oldCh, oldStartIdx, oldEndIdx)
      idxInOld = isDef(newStartVnode.key)
        ? oldKeyToIdx[newStartVnode.key]
        : findIdxInOld(newStartVnode, oldCh, oldStartIdx, oldEndIdx)
      // Extract the nodes with keys from the oldVnode sequence and put them in the map, then traverse the new vnode sequence // Determine whether the key of the vnode is in the map. If so, find the oldVnode corresponding to the key. If the oldVnode is the same as the traversed vnode, reuse the dom and move the dom node position if (isUndef(idxInOld)) { // New element
        createElm(newStartVnode, insertedVnodeQueue, parentElm, oldStartVnode.elm, false, newCh, newStartIdx)
      } else {
        vnodeToMove = oldCh[idxInOld]
        if (sameVnode(vnodeToMove, newStartVnode)) {
          patchVnode(vnodeToMove, newStartVnode, insertedVnodeQueue)
          oldCh[idxInOld] = undefined
          canMove && nodeOps.insertBefore(parentElm, vnodeToMove.elm, oldStartVnode.elm)
        } else {
          // same key but different element. treat as new element
          createElm(newStartVnode, insertedVnodeQueue, parentElm, oldStartVnode.elm, false, newCh, newStartIdx)
        }
      }
      newStartVnode = newCh[++newStartIdx]
    }
  }
  if (oldStartIdx > oldEndIdx) {
    refElm = isUndef(newCh[newEndIdx + 1]) ? null : newCh[newEndIdx + 1].elm
    addVnodes(parentElm, refElm, newCh, newStartIdx, newEndIdx, insertedVnodeQueue)
  } else if (newStartIdx > newEndIdx) {
    removeVnodes(parentElm, oldCh, oldStartIdx, oldEndIdx)
  }
}

The main logic here is: compare the head and tail of the new node with the head and tail of the old node to see if they are the same nodes. If they are, patch Vnode directly; otherwise, use a Map to store the keys of the old nodes, and then traverse the keys of the new nodes to see if they exist in the old nodes. If they are the same, reuse them; the time complexity here is O(n), and the space complexity is also O(n), using space to trade time~

The diff algorithm is mainly used to reduce the amount of updates, find the DOM with the smallest difference, and only update the difference.

3. nextTick

The so-called nextTick means the next tick, so what is a tick?

We know that JS execution is single-threaded. It handles asynchronous logic based on the event loop, which is mainly divided into the following steps:

All synchronous tasks are executed on the main thread, forming an execution context stack;
In addition to the main thread, there is also a "task queue". As long as the asynchronous task has a running result, an event is placed in the "task queue";
Once all synchronous tasks in the "execution stack" have been executed, the system will read the "task queue" to see what events are in it. Those corresponding asynchronous tasks then end the waiting state, enter the execution stack, and start execution;
The main thread keeps repeating step 3 above.

The execution process of the main thread is a tick, and all asynchronous results are scheduled through the "task queue". The message queue stores tasks one by one. The specification stipulates that tasks are divided into two categories, namely macro tasks and micro tasks, and all micro tasks must be cleared after each macro task is completed.

for (macroTask of macroTaskQueue) { 
  // 1. Handle current MACRO-TASK 
  handleMacroTask()
  // 2. Handle all MICRO-TASK 
  for (microTask of microTaskQueue) { 
    handleMicroTask(microTask)
  } 
}

In the browser environment, common macro tasks include setTimeout, MessageChannel, postMessage, setImmediate, and setInterval; common micro tasks include MutationObsever and Promise.then.

We know that the re-rendering of DOM from data changes is an asynchronous process that occurs in the next tick. For example, during the development process, when we get data from the server interface, the data is modified. If some of our methods rely on DOM changes after the data is modified, we must execute them after nextTick. For example, the following pseudo code:

getData(res).then(() => { 
  this.xxx = res.data 
  this.$nextTick(() => { // Here we can get the changed DOM }) 
})

IV. Conclusion

This is the end of this article about how to implement responsiveness in Vue source code learning. For more relevant Vue responsiveness implementation content, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!

You may also be interested in: