Vue3 Responsive System source code parsing – single test

A brush source code, a face meng

Looking at the reactivity entry file, you can see that it only exposes apis in six files. The values are: REF, reactive, computed, Effect, LOCK, and Operations. The lock file is an enumeration of the types of data operations, and the operations file is an enumeration of the types of data operations.

So the focus of reActivity is on the four files of REF, reactive, computed, and Effect, but these four files are not so simple. I spent half a day wanking from beginning to end, and found that I knew every letter; I know every word, thanks to Google; Almost all of these expressions are understandable to my half-baked TypeScript skills. But when it comes to functions, I’m a little confused….. Reactive in the ref, reactive in the ref, and then some weird operation inside the function, and then you get confused.

I just summed it up, largely because I don’t know what these key apis are for. Source CODE I do not understand, API meaning I do not understand. We know that you can’t solve a single binary equation.

So what do we do? There’s actually another equation, which is the single test. Reading from single test is an excellent way to read the source code. Not only can you quickly learn the meaning and usage of the API, but you can also learn many boundary cases. In the process of reading, will also think, if it is their own words, how to achieve, can deepen the understanding of the source code with learning.

Reactive

Reactive data, as its name suggests, means reactive data, which is the core of the library. So let’s see what it’s capable of.

First single test:

test('Object'.(a)= > {
  const original = { foo: 1 }
  const observed = reactive(original)
  expect(observed).not.toBe(original)
  expect(isReactive(observed)).toBe(true)
  expect(isReactive(original)).toBe(false)
  // get
  expect(observed.foo).toBe(1)
  // has
  expect('foo' in observed).toBe(true)
  // ownKeys
  expect(Object.keys(observed)).toEqual(['foo'])})Copy the code

If we pass an object to reactive, it will return a new object. The two objects have the same type, the same length of data, but different references. Then we immediately understand that this must be the use of Proxy! vue@3 The core of the responsive system core.

So let’s look at Reactive’s statement:

Reactive only accepts object data and returns an UnwrapNestedRefs data type. Reactive only accepts object data and returns an UnwrapNestedRefs data type.

Second single test:

test('Array'.(a)= > {
  const original: any[] = [{ foo: 1 }]
  const observed = reactive(original)
  expect(observed).not.toBe(original)
  expect(isReactive(observed)).toBe(true)
  expect(isReactive(original)).toBe(false)
  expect(isReactive(observed[0])).toBe(true)
  // get
  expect(observed[0].foo).toBe(1)
  // has
  expect(0 in observed).toBe(true)
  // ownKeys
  expect(Object.keys(observed)).toEqual(['0'])})Copy the code

Reactive receives an array and returns a new array, not exactly equal to the original array, but with the same data. This is the same as the case of the objects in Test one. But this single test doesn’t consider nesting, I might add

test('Array'.(a)= > {
  const original: any[] = [{ foo: 1, a: { b: { c: 1 } }, arr: [{ d: {} }] }]
  const observed = reactive(original)
  expect(observed).not.toBe(original)
  expect(isReactive(observed)).toBe(true)
  expect(isReactive(original)).toBe(false)
  expect(isReactive(observed[0])).toBe(true)
  / / observed. A. is reactive
  expect(isReactive(observed[0].a.b)).toBe(true)
  / / observed [0]. Arr [0]. D is reactive
  expect(isReactive(observed[0].arr[0].d)).toBe(true)
  // get
  expect(observed[0].foo).toBe(1)
  // has
  expect(0 in observed).toBe(true)
  // ownKeys
  expect(Object.keys(observed)).toEqual(['0'])})Copy the code

The new data returned is still isReactive as long as the value of the property is an object.

The third single test is nothing to talk about, and the fourth single test, which tests nested objects, is covered in my second single test supplement.

Fifth single test:

test('observed value should proxy mutations to original (Object)'.(a)= > {
  const original: any = { foo: 1 }
  const observed = reactive(original)
  // set
  observed.bar = 1
  expect(observed.bar).toBe(1)
  expect(original.bar).toBe(1)
  // delete
  delete observed.foo
  expect('foo' in observed).toBe(false)
  expect('foo' in original).toBe(false)})Copy the code

** In this single test, we finally saw responsiveness. Reactive response data is returned after execution. Any write or delete operations performed on it can be synchronized to the original data. What about going the other way and just changing the original data?

test('observed value should proxy mutations to original (Object)'.(a)= > {
  let original: any = { foo: 1 }
  const observed = reactive(original)
  // set
  original.bar = 1
  expect(observed.bar).toBe(1)
  expect(original.bar).toBe(1)
  // delete
  delete original.foo
  expect('foo' in observed).toBe(false)
  expect('foo' in original).toBe(false)})Copy the code

We found that by modifying the original data directly, the response data can also get the latest data.

The sixth single test

test('observed value should proxy mutations to original (Array)'.(a)= > {
  const original: any[] = [{ foo: 1 }, { bar: 2 }]
  const observed = reactive(original)
  // set
  const value = { baz: 3 }
  const reactiveValue = reactive(value)
  observed[0] = value
  expect(observed[0]).toBe(reactiveValue)
  expect(original[0]).toBe(value)
  // delete
  delete observed[0]
  expect(observed[0]).toBeUndefined()
  expect(original[0]).toBeUndefined()
  // mutating methods
  observed.push(value)
  expect(observed[2]).toBe(reactiveValue)
  expect(original[2]).toBe(value)
})
Copy the code

The sixth single test demonstrated one of the great benefits of implementing responsive data through a Proxy: the ability to hijack all data changes to an array. Remember in vue@2, you had to manually set the array? In vue@3, finally do not have to do some strange operation, the heart of the update array.

Seventh single test:

test('setting a property with an unobserved value should wrap with reactive'.(a)= > {
  const observed: any = reactive({})
  const raw = {}
  observed.foo = raw
  expect(observed.foo).not.toBe(raw)
  expect(isReactive(observed.foo)).toBe(true)})Copy the code

Again, this is the second big benefit of having responsive data through a Proxy. In vue@2, reactive data must have a key declared at the beginning, and a default value must be set if it does not exist at the beginning. With this technical solution, the attribute values of vue@3’s responsive data can finally be added and removed at any time.

Eighth and ninth single test

test('observing already observed value should return same Proxy'.(a)= > {
  const original = { foo: 1 }
  const observed = reactive(original)
  const observed2 = reactive(observed)
  expect(observed2).toBe(observed)
})

test('observing the same value multiple times should return same Proxy'.(a)= > {
  const original = { foo: 1 }
  const observed = reactive(original)
  const observed2 = reactive(original)
  expect(observed2).toBe(observed)
})
Copy the code

These two single tests show that for the same raw data, the result returned by executing reactive multiple times or executing reactive nested will be the same corresponding data. A cache is maintained in the reactive file. The original data is used as key and the response data is used as value. If the key already has a value, the value is directly returned. That JS basic OK students should know that such a result can be achieved by WeakMap.

The tenth single test

test('unwrap'.(a)= > {
  const original = { foo: 1 }
  const observed = reactive(original)
  expect(toRaw(observed)).toBe(original)
  expect(toRaw(original)).toBe(original)
})
Copy the code

Through this single test, we learned about the toRaw API, which can obtain raw data through response data. That indicates that another WeakMap needs to be maintained for reverse mapping in the reactive file.

The eleventh single test, do not post the code, this single test enumerates the data type that cannot become the response data, namely JS five basic data type + Symbol (by oneself test, function also does not support). When data of the built-in special types, such as Promise, RegExp and Date, is passed to reactive, the original data will be returned without any error.

One last single test

test('markNonReactive'.(a)= > {
  const obj = reactive({
    foo: { a: 1 },
    bar: markNonReactive({ b: 2 })
  })
  expect(isReactive(obj.foo)).toBe(true)
  expect(isReactive(obj.bar)).toBe(false)})Copy the code

This refers to an API called markNonReactive, which makes it impossible for object data to become reactive. This API should be used infrequently in real business and may be used for specific performance optimizations.

After seeing reactive in a single test, we know something about reactive: it can accept an object or array and return new response data. The response data is like the shadow of the original data, and any operation on either side can be synchronized to the other.

But this… I don’t think it’s any good. But from the single test performance, is based on Proxy, do some boundary and nesting processing. This leads to a very critical question: how does it notify the view to update at vue@3? Or how does it inform its users that something needs to be done when the data changes in response? ** This behavior must be wrapped in the Proxy’s set/get handler. We don’t know yet, but we’ll have to keep looking at the other single tests.

Since we know from the beginning that the return value of reactive is of type UnwrapNestedRefs, at first glance it’s a special type of Ref, so let’s move on and look at refs. (In fact, this UnwrapNestedRefs is used to get the type of the generic type nested in refs. Remember that Unwrap is a verb. This is a bit of a wrap, but I’ll talk about source parsing later.)

Effect

Effect’s behavior is already clear from the above test file. The main thing is to listen for changes in reactive data, triggering the execution of the listening function. The description is simple, but effect’s single measure is large, with 39 use cases, over 600 lines of code, and lots of boundary case considerations. So for effect, I won’t list them one by one. I’m going to go through it for you, and then I’m going to break it down into small points, and then I’m going to go straight to the key points, and then I’m going to post the corresponding test code if necessary.

Special logic

• ** can avoid infinite loops caused by implicit recursion, such as changes in the response data within the listening function or the interaction of multiple listening functions. It does not prevent explicit recursion, such as listening to function loop calls themselves.

it('should avoid implicit infinite recursive loops with itself'.(a)= > {
  const counter = reactive({ num: 0 })

  const counterSpy = jest.fn((a)= > counter.num++)
  effect(counterSpy)
  expect(counter.num).toBe(1)
  expect(counterSpy).toHaveBeenCalledTimes(1)
  counter.num = 4
  expect(counter.num).toBe(5)
  expect(counterSpy).toHaveBeenCalledTimes(2)
})

it('should allow explicitly recursive raw function loops'.(a)= > {
  const counter = reactive({ num: 0 })
  const numSpy = jest.fn((a)= > {
    counter.num++
    if (counter.num < 10) {
      numSpy()
    }
  })
  effect(numSpy)
  expect(counter.num).toEqual(10)
  expect(numSpy).toHaveBeenCalledTimes(10)})Copy the code

• ** If the dependencies within effect are logically branched, the listening function will update the dependencies after each execution. ** As shown in the following: Whenobj.run 为 falseWhen,conditionalSpyRe-execute after updating the listener dependency, subsequent regardlessobj.propThe listener function is no longer executed.

it('should not be triggered by mutating a property, which is used in an inactive branch'.(a)= > {
  let dummy
  const obj = reactive({ prop: 'value', run: true })

  const conditionalSpy = jest.fn((a)= > {
    dummy = obj.run ? obj.prop : 'other'
  })
  effect(conditionalSpy)

  expect(dummy).toBe('value')
  expect(conditionalSpy).toHaveBeenCalledTimes(1)
  obj.run = false
  expect(dummy).toBe('other')
  expect(conditionalSpy).toHaveBeenCalledTimes(2)
  obj.prop = 'value2'
  expect(dummy).toBe('other')
  expect(conditionalSpy).toHaveBeenCalledTimes(2)})Copy the code

Computed

Calculate the properties. Those of you who have written vue know what that means. Let’s see how that works in reactivity.

First single test

it('should return updated value'.(a)= > {
  constvalue = reactive<{ foo? :number} > ({})const cValue = computed((a)= > value.foo)
  expect(cValue.value).toBe(undefined)
  value.foo = 1
  expect(cValue.value).toBe(1)})Copy the code

A getter function is passed to the computed. The function internally relies on a Reactive data. After execution, the function returns a computed object whose value is the return value of the function. When its dependent Reactive data changes, the calculation data stays synchronized, like a Ref. In fact, in the REF test file we already know that computed results are also ref data.

ComputedRef inherits from Ref and has one more read-only effect attribute, of Type ReactiveEffect. As you can guess, the value of the effect property here is what effect returns when it executes on the computed function. In addition, the value is read-only, indicating that the value of the returned result of the computed is read-only.

Second single test

it('should compute lazily'.(a)= > {
  constvalue = reactive<{ foo? :number} > ({})const getter = jest.fn((a)= > value.foo)
  const cValue = computed(getter)

  // lazy
  expect(getter).not.toHaveBeenCalled()

  expect(cValue.value).toBe(undefined)
  expect(getter).toHaveBeenCalledTimes(1)

  // should not compute again
  cValue.value
  expect(getter).toHaveBeenCalledTimes(1)

  // should not compute until needed
  value.foo = 1
  expect(getter).toHaveBeenCalledTimes(1)

  // now it should compute
  expect(cValue.value).toBe(1)
  expect(getter).toHaveBeenCalledTimes(2)

  // should not compute again
  cValue.value
  expect(getter).toHaveBeenCalledTimes(2)})Copy the code

This single test tells us a lot about computed:

• Different from theeffecttocomputedThe passedgetterFunction is not executed immediately, but only when the data is actually used.
• Not every value needs to be recalledgetterFunction, andgetterIt is not retriggered when the data that the function depends on changes, but only when the computed data is used again after the dependent data has changedgetterFunction.

In the first single test, we assume that the effect property of ComputedRef is the listener generated by passing a getter function to the effect method. However, in the Effect single test, the listening function is executed as soon as the dependent data changes, which is not consistent with the computed performance here. There must be a catch!

At the end of the previous section Effect, we found that the second parameter to Effect is a configuration item, and one of the configurations, called computed, was not covered in the single test. It is estimated that this configuration item implements the delayed computation of the data calculated here.

The third single test

it('should trigger effect'.(a)= > {
  constvalue = reactive<{ foo? :number} > ({})const cValue = computed((a)= > value.foo)
  let dummy
  effect((a)= > {
    dummy = cValue.value
  })
  expect(dummy).toBe(undefined)
  value.foo = 1
  expect(dummy).toBe(1)})Copy the code

This single test proves the conjecture we made in the Ref chapter: if an effect is dependent on computed return data, the effect will execute when it changes.

What if computed returns haven’t changed, but the dependent data has changed? Does this result in effect execution? I assumed that for computed to stay the same, it would not cause the listener to re-execute, so I changed the order test:

it('should trigger effect'.(a)= > {
  constvalue = reactive<{ foo? :number} > ({})const cValue = computed((a)= > value.foo ? true : false)
  let dummy
  const reactiveEffect = jest.fn((a)= > {
    dummy = cValue.value
  })
  effect(reactiveEffect)
  expect(dummy).toBe(false)
  expect(reactiveEffect).toHaveBeenCalledTimes(1)
  value.foo = 1
  expect(dummy).toBe(true)
  expect(reactiveEffect).toHaveBeenCalledTimes(2)
  value.foo = 2
  expect(dummy).toBe(true)
  expect(reactiveEffect).toHaveBeenCalledTimes(2)})Copy the code

And then I realized I was wrong. The reactiveEffect depends on the cValue, and the cValue depends on the value. Whenever the value changes, the reactiveEffect will be triggered whether the cValue has changed or not. I feel that this can be optimized, and those who are interested in it can ask for PR.

The fourth single test

it('should work when chained'.(a)= > {
  const value = reactive({ foo: 0 })
  const c1 = computed((a)= > value.foo)
  const c2 = computed((a)= > c1.value + 1)
  expect(c2.value).toBe(1)
  expect(c1.value).toBe(0)
  value.foo++
  expect(c2.value).toBe(2)
  expect(c1.value).toBe(1)})Copy the code

This single test illustrates that a getter function for computed can depend on other computed data.

The fifth and sixth single tests belonged to changing flowers using computed. The idea is that using computed data is just as effective at triggering the execution of the listening function as using normal response data.

The seventh single test

it('should no longer update when stopped', () = > {constvalue = reactive<{ foo? : number }>({})const cValue = computed((a)= > value.foo)
  let dummy
  effect((a)= > {
    dummy = cValue.value
  })
  expect(dummy).toBe(undefined)
  value.foo = 1
  expect(dummy).toBe(1)
  stop(cValue.effect)
  value.foo = 2
  expect(dummy).toBe(1)})Copy the code

This single test also introduces the STOP API, which stops the response update of the computed data with stop(cvalue.effect).

The last two single tests

it('should support setter'.(a)= > {
  const n = ref(1)
  const plusOne = computed({
    get: (a)= > n.value + 1.set: val= > {
      n.value = val - 1
    }
  })
  expect(plusOne.value).toBe(2)
  n.value++
  expect(plusOne.value).toBe(3)
  plusOne.value = 0
  expect(n.value).toBe(- 1)
})
it('should trigger effect w/ setter'.(a)= > {
  const n = ref(1)
  const plusOne = computed({
    get: (a)= > n.value + 1.set: val= > {
      n.value = val - 1}})let dummy
  effect((a)= > {
    dummy = n.value
  })
  expect(dummy).toBe(1)
  plusOne.value = 0
  expect(dummy).toBe(- 1)})Copy the code

These two single tests are important. For computed, we just passed the getter function, and the value was read-only, so we couldn’t change the return value directly. Let’s see here that computed can also pass an object that contains both get and set methods. Get is the getter function, so it makes sense. The input to the setter function is the value of the data assigned to comptued Value. So in the above use case, plusone.value = 0, making n.value = 0-1, and triggering dummy to become -1.

At this point, we’re pretty much done with the concept of the ReActivity system. We’re left with readOnly and collections. Readonly is a read – only version of reactive. Reactive is a read – only version of reactive. Collections single test is to override the response updates of Map, Set, WeakMap, and WeakSet, so there should be little problem if we don’t look at it for the time being.