This article only from the theoretical point of view to elaborate the response in vue. js, does not involve the specific source code.

preface

We all know that vue.js has the characteristics of data response.

Common scenarios include the following:

  • Data change → The view that uses the data changes
  • Data change → computing properties using data change → views using computing properties change
  • Data change → developer actively registered watch callback function execution

Three scenarios, corresponding to the three watcher:

  • The render-watcher who urges view updates
  • Perform computed-watcher that urges update of computed properties
  • User registered normal Watcher (watch-API or Watch properties)

Here are three articles to look at what each watcher is, what it does, and how it works.

This is the first in a series of watcher articles

  • Tell me about Vue’s watcher (1) — Render watcher
  • Talk about Vue’s watcher (2) — computed Watcher
  • What about Vue’s Watcher (2) — Regular Watcher (to be continued…)

render watcher

new Vue({
  template: `<div>My name is {{name}}<div>`.data: {
    name: 'FooBar'.gender: 'male'}})Copy the code

Taken together with the code above, reactive means that when the value of the name property changes, the rendered content should also change.

Establish contact

How can I establish a connection between view rendering and property values? Let’s get two things straight

  • Who used this data
  • What happens when the data changes

In the case of view rendering, the answers to these two questions are:

  • The Render function that generates the view uses this data
  • Render function is executed for data change

The data was hijacked

Use and change can be known by setting the access descriptor (GET /set) on the value of the property.

Therefore, you need to iterate through all the data property values and set the access descriptor (GET /set) with object.defineProperty.

  • Who used this data? What triggers the property value get should be used, and the user should be recorded in the getter.

  • What if the data changes? A change in the data will trigger a set of property values, which should be notified to the consumer in the setter.

Subscription-publish

As you can see from the above description, this scenario is typical publish & subscribe.

In a view-rendered scene, render-watcher is the subscriber. Each attribute value has a dependency manager, the DEP, who is responsible for logging and notifying subscribers.

Collection and notification of dependencies

A process for collecting subscribers (dependencies)

  1. The subscriber performs the callback (render function)
  2. Fires the getter for the property value
  3. Add to the subscriber queue
  4. Repeat 2 and 3 until all getters have been executed

The process of notifying subscribers

  1. The property change
  2. Triggers the setter for the property value
  3. Dep informs subscribers (Render Watcher)
  4. The subscriber performs the callback (render function)

unsubscribe

When certain property values are no longer used by the view, you should unsubscribe those properties.

How do you know which attribute values are no longer referenced? Here’s what we can do:

The subscriber (Render -watcher) also maintains a dependency collection where the DEP of the dependent property value is stored.

Each time the Render function executes, triggering getters for property values, the subscriber (render-watcher) stores a new set of dependencies. Compare the set of old and new dependencies, find the old DEP that is no longer dependent on, and remove render-watcher from the subscriber queue of this old DEP. This will not notify the current subscriber (render-watcher).