Shulou(Shulou.com)05/31 Report--

Today, I would like to share with you the relevant knowledge of how the Vue3 computing properties are realized. The content is detailed and the logic is clear. I believe most people still know too much about this knowledge, so share this article for your reference. I hope you can get something after reading this article. Let's take a look.

Calculation property is a very practical API in Vue.js development, which allows the user to define a calculation method, then calculate the new value based on some dependent response data and return it. When the dependency changes, the calculated property can be automatically recalculated to get the new value, so it is very convenient to use.

In Vue.js 2.x, it is believed that your application of computational properties is already well known, and we can define the computed property in the component object. With Vue.js 3.0, we can also use Vue.js 2.x in our components, but we can also use the calculation property API alone.

Computational attributes are essentially dependent calculations, so why don't we just use functions? How is the API for computing attributes implemented in Vue.js 3.0? This paper analyzes the implementation principle of computational attributes.

Calculation property API:computed

Vue.js 3.0 provides a computed function as the evaluation property API. Let's take a look at how it is used.

Let's take a simple example:

Const count = ref (1) const plusOne = computed (() = > count.value+ 1) console.log (plusOne.value) / / 2 plusOne.value++ / / error count.value++ console.log (plusOne.value) / / 3

As you can see from the code, we first use ref API to create a responsive object count, and then use computed API to create another responsive object plusOne, whose value is count.value + 1. When we modify count.value, plusOne.value changes automatically.

Note that here we directly modify plusOne.value will report an error, because if what we pass to computed is a function, then this is a getter function, and we can only get its value, not modify it directly.

In the getter function, we recalculate the new value based on the responsive object, which is why it is called the computational property, and this responsive object is the dependency of the computational property.

Of course, sometimes we also want to be able to directly modify the return value of computed, so we can pass an object to computed:

Const count = ref (1) const plusOne = computed ({get: () = > count.value + 1, set: val = > {count.value = val-1}}) plusOne.value = 1 console.log (count.value) / / 0

In this example, combined with the above code, we can see that we pass an object with the getter function and the setter function to the computed function, and the getter function returns count.value + 1 as before. As for the setter function, please note that here we modify the value of plusOne.value to trigger the setter function. In fact, the setter function actually modifies the dependent value count.value of the calculation attribute based on the passed parameters, because once the dependent value is modified, the getter will be executed again when we get the calculation attribute, so the value obtained in this way has changed.

Well, now that we know two ways to use computed API, let's take a look at how it is implemented:

Function computed (getterOrOptions) {/ / getter function let getter / / setter function let setter / / Standardization parameter if (isFunction (getterOrOptions)) {/ / the surface passes in the getter function Cannot modify the value of the calculation attribute getter = getterOrOptions setter = (process.env.NODE_ENV! = = 'production')? () = > {console.warn (' Write operation failed: computed value is readonly')}: NOOP} else {getter = getterOrOptions.get setter = getterOrOptions.set} / / let dirty = true / / calculation result let Value let computed / / create the side effect function const runner = effect (getter {/ / delay execution of lazy: true, / / Mark this is a computed effect used to prioritize computed: true, / / schedule execution in the trigger phase scheduler: () = > {if (! dirty) {dirty = true / / dispatch notifications Notify the run to run the activeEffect trigger (computed, "set" / * SET * /, 'value')}) / / create the computed object computed = {_ _ v_isRef: true, / / expose the effect object so that the calculation property can stop calculating effect: runner Get value () {/ / calculate attribute getter if (dirty) {/ / recalculate value = runner () dirty = false} / / dependency collection only if the data is dirty Collect activeEffect track (computed, "get" / * GET * /, 'value') return value}, set value (newValue) {/ / setter setter (newValue)}} return computed} that access the calculation attribute

As you can see from the code, the flow of the computed function does three main things: standardizing parameters, creating side-effect functions, and creating computed objects. Let's analyze these steps in detail.

The first is the standardization of parameters. The computed function accepts two types of parameters, one is the getter function, and the other is the object with getter and setter functions. By judging the type of parameters, we initialize the getter and setter functions defined within the function.

The next step is to create the side effect function runner. Computed internally creates a side effect function through effect, which is a layer of encapsulation of the getter function. In addition, we should pay attention to the second parameter here, that is, the configuration object of the effect function. Where lazy is true means that the runner returned by the effect function will not be executed immediately; computed is true to indicate that this is a computed effect, which is used for prioritization in the trigger phase, which we will analyze later; and scheduler indicates how it is scheduled to run, which we will analyze later.

Finally, the computed object is created and returned, which also has getter and setter functions. Getter will be triggered when the computed object is accessed, and then it will determine whether to dirty. If so, execute runner, and then do dependency collection; when we set the computed object directly, it will trigger setter, that is, execute the setter function defined inside the computed function.

The operating mechanism of computing properties

The logic of the computed function will twist a little bit, but never mind, we can use an example of applying computed to evaluate properties to understand how the entire calculation properties work. Before analyzing, we need to remember two important variables inside the computed. The first dirty indicates whether the value of a calculated attribute is "dirty" to determine whether it needs to be recalculated, and the second value represents the result of each calculation of the calculated attribute.

Now, let's look at this example:

{{plusOne}} plus import {ref, computed} from 'vue' export default {setup () {const count = ref (0) const plusOne = computed (() = > {return count.value+ 1}) function plus () {count.value++} return {plusOne, plus}

As you can see, in this example, we use computed API to create the computed property object plusOne, which is passed in a getter function, which we call computed getter in order to distinguish it from the later getter function of the computed property object. In addition, plusOne variables and plus functions are referenced in the component template.

During the component rendering phase, the plusOne is accessed, which triggers the getter function of the plusOne object:

Get value () {/ / getter if (dirty) of the calculation attribute {/ / recalculates value = runner () dirty = false} / / dependency collection only when the data is dirty, and collects the activeEffect track (computed, "get" / * GET * /, 'value') return value} that runs to access the calculation attribute.

Because the default dirty is true, the runner function is executed at this time, and the computed getter, that is, count.value + 1, is further executed, because the value of count is accessed, and because count is also a responsive object, the dependency collection process of the count object is triggered.

Note that since you are accessing count during runner execution, the activeEffect at this time is the runner function. After the execution of the runner function, dirty is set to false, and the track (computed, "get", 'value') function is further executed to collect dependencies. By this time, runner is finished, so activeEffect is a component side-effect rendering function.

So you should pay special attention to the two dependency collection processes: for plusOne, it collects dependencies on component side effects rendering functions; for count, it collects dependencies on runner functions within plusOne.

Then when we click the button, the plus function is executed, the value of count is modified through count.value++ inside the function, and a notification is sent. Note that instead of calling the runner function directly, the scheduler function is executed with runner as an argument. Let's review how the effect function is executed within the trigger function:

Const run = (effect) = > {/ / schedule execution if (effect.options.scheduler) {effect.options.scheduler (effect)} else {/ / directly run effect ()}}

When creating a side effect function within computed API, the scheduler function has been configured, as follows:

Scheduler: () = > {if (! dirty) {dirty = true / / dispatch notification to run activeEffect trigger (computed, "set" / * SET * /, 'value')}}

Instead of looking for a new value for the calculation property, it simply sets dirty to true and then executes trigger (computed, "set", 'value') to notify the rendering side effect function of the component that plusOne depends on, that is, to trigger the component's re-rendering.

When the component re-renders, it accesses plusOne again. We find that dirty is true at this time, and then execute computed getter again, and then execute count.value + 1 to get the new value. This is why the component will still re-render when we change the value of count, even though the component does not directly access the count.

The above process can be shown visually through the following figure:

From the above analysis, we can see that the computed calculation attribute has two characteristics:

Deferred calculation, which actually runs the computed getter function calculation only when we access the calculation property

Cache, which internally caches the last calculation result value and is recalculated only if dirty is true. If the dirty is false when accessing the computed property, the value is returned directly.

Now we can answer the questions raised at the beginning. Compared with simply using ordinary functions, the advantage of computing attributes is that as long as the dependency remains unchanged, you can use the cached value instead of executing functions to calculate every time you render the component, which is a typical optimization idea of space-for-time.

Nested calculation attributes

Calculation attributes also support nesting. We can make a small modification to the above example, that is, instead of accessing plusOne in the rendering function, we can access it in another calculation attribute:

Const count = ref (0) const plusOne = computed (() = > {return count.value + 1}) const plusTwo = computed (() = > {return plusOne.value + 1}) console.log (plusTwo.value)

As you can see from the code, when we access plusTwo, the process is the same as before, and it is also two processes that rely on collection. For plusOne, the dependencies it collects are the runner functions within plusTwo; for count, the dependencies it collects are runner functions within plusOne.

Then, when we modify the value of count, it will send a notification, first run the scheduler function inside plusOne, change the dirty inside plusOne into true, then execute the trigger function to dispatch the notification again, and then run the scheduler function inside plusTwo to set the dirty inside plusTwo to true.

Then when we visit the value of plusTwo again and find that dirty is true, we execute the computed getter function of plusTwo to execute plusOne.value + 1, and then execute the computed gette of plusOne, that is, count.value + 1 + 1, to get the final new value 2.

Thanks to the ingenious design of computed, it works no matter how many layers of computing properties are nested.

Calculate the order in which attributes are executed

We mentioned that when you create a side effect function inside a calculated property, you configure computed to true, identifying that this is a computed effect for prioritization during the trigger phase. Let's review how the trigger function executes effects:

Const add = (effectsToAdd) = > {if (effectsToAdd) {effectsToAdd.forEach (effect = > {if (effect! = = activeEffect | |! shouldTrack) {if (effect.options.computed) {computedRunners.add (effect)} else {effects.add (effect)})} const run = (effect) = > {if (effect) .options.organizer) {effect.options.scheduler (effect)} else {effect ()}} computedRunners.forEach (run) effects.forEach (run)

When adding an effects to be run, we will determine whether each effect is a computed effect, if so, it will be added to the computedRunners, and the computedRunners will be executed first in the later run, and then the normal effects will be executed.

So why design it this way? In fact, taking into account some special scenarios, we use an example to illustrate:

Import {ref, computed} from 'vue' import {effect} from' @ vue/reactivity' const count = ref (0) const plusOne = computed (() = > {return count.value+ 1}) effect (() = > {console.log (plusOne.value + count.value)}) function plus () {count.value++} plus ()

The output of the result after this example is run:

1 3 3

Run console.log (plusOne.value + count.value) when the effect function is executed, so output 1 for the first time, when count.value is 0 and plusOne. value is 1.

Output 3 twice in a row because both plusOne and count depend on this effect function, so when we execute the plus function to modify the value of count, we will trigger and execute this effect function, because the runner of plusOne is also a dependency of count, and the modification of count value will also execute the runner of plusOne, which will execute the effect function of plusOne again, so it will be output twice.

So why output 3 both times? This has something to do with executing computed runner first. First of all, since both runner and effect of plusOne are dependent on count, when we modify the count value, both runner and effect of plusOne will be executed, so the order of execution is important.

Here, first execute the runner of plusOne, set the dirty of plusOne to true, and then tell its dependent effect to execute plusOne.value + count.value. At this point, because dirty is true, plusOne's getter calculation of the new value will be performed again, with a new value of 2, plus 1 for 3. After performing the runner of plusOne and the dependency update, then execute the normal effect dependency of count to execute plusOne.value + count.value. In this case, plusOne dirty is false, and directly return the last calculation result 2, and then add 1 to get 3.

What if we change the execution order of computed runner and effect? Let me tell you, the following results will be output:

1 2 3

The first output of 1 is easy to understand because the process is the same. Why did you output 2 the second time? Let's analyze that when we execute the plus function to modify the value of count, the execution of runner and effect of plusOne will be triggered. This time, we first let effect execute plusOne.value + count.value, then we will access plusOne.value, but because the runner of plusOne has not been executed, dirty is false at this time, the value is still the result of the previous calculation, and then add 1 to get 2.

Then execute plusOne's runner, set plusOne's dirty to true, and then notify its dependent effect to execute plusOne.value + count.value. At this time, because dirty is true, it will execute plusOne's getter to calculate the new value again, get 2, and then add 1 to get 3.

After knowing the reason, let's go back to the example. Because effect functions rely on plusOne and count, it makes more sense for plusOne to calculate first, which is why we need to make computed runner execution take precedence over normal effect functions.

These are all the contents of the article "how Vue3 Computing Properties are implemented". Thank you for reading! I believe you will gain a lot after reading this article. The editor will update different knowledge for you every day. If you want to learn more knowledge, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.