fix(reactivity): allowRecurse effects's dirtyLevel unreliable

[johnsoncodehk]

This resolves the regression introduced by #10091 and re-fix #10082.

Also fix a test of #10085, #10090.

[github-actions]

Size Report

Bundles

File	Size	Gzip	Brotli
runtime-dom.global.prod.js	89.8 kB (+69 B)	34.2 kB (+26 B)	30.8 kB (+16 B)
vue.global.prod.js	147 kB (+69 B)	53.5 kB (+25 B)	47.7 kB

Usages

Name	Size	Gzip	Brotli
createApp	50.2 kB (+69 B)	19.6 kB (+16 B)	18 kB (+30 B)
createSSRApp	53.5 kB (+69 B)	20.9 kB (+16 B)	19.1 kB (-12 B)
defineCustomElement	52.5 kB (+69 B)	20.4 kB (+17 B)	18.6 kB (-2 B)
overall	63.9 kB (+69 B)	24.7 kB (+18 B)	22.4 kB (+9 B)

[johnsoncodehk]

/ecosystem-ci run

[vue-bot]

📝 Ran ecosystem CI: Open

suite	result	latest scheduled
language-tools	❌ failure	❌ failure
nuxt	✅ success	✅ success
pinia	✅ success	✅ success
quasar	❌ failure	✅ success
radix-vue	✅ success	undefined undefined
router	✅ success	✅ success
test-utils	✅ success	✅ success
vant	❌ failure	✅ success
vite-plugin-vue	✅ success	✅ success
vitepress	✅ success	✅ success
vue-i18n	✅ success	✅ success
vue-macros	✅ success	❌ failure
vuetify	❌ failure	✅ success
vueuse	✅ success	✅ success
vue-simple-compiler	✅ success	✅ success

[johnsoncodehk]

/ecosystem-ci run

[vue-bot]

📝 Ran ecosystem CI: Open

suite	result	latest scheduled
language-tools	❌ failure	❌ failure
nuxt	❌ failure	✅ success
pinia	✅ success	✅ success
quasar	❌ failure	✅ success
radix-vue	✅ success	undefined undefined
router	✅ success	✅ success
test-utils	✅ success	✅ success
vant	❌ failure	✅ success
vite-plugin-vue	✅ success	✅ success
vitepress	✅ success	✅ success
vue-i18n	✅ success	✅ success
vue-macros	✅ success	❌ failure
vuetify	❌ failure	✅ success
vueuse	✅ success	✅ success
vue-simple-compiler	✅ success	✅ success

[johnsoncodehk]

/ecosystem-ci run

[vue-bot]

📝 Ran ecosystem CI: Open

suite	result	latest scheduled
language-tools	❌ failure	❌ failure
nuxt	❌ failure	✅ success
pinia	✅ success	✅ success
quasar	✅ success	✅ success
radix-vue	✅ success	undefined undefined
router	✅ success	✅ success
test-utils	✅ success	✅ success
vant	✅ success	✅ success
vite-plugin-vue	✅ success	✅ success
vitepress	✅ success	✅ success
vue-i18n	✅ success	✅ success
vue-macros	✅ success	❌ failure
vuetify	❌ failure	✅ success
vueuse	✅ success	✅ success
vue-simple-compiler	✅ success	✅ success

[Doctor-wu]

Just gonna to do the same thing 😂

[rocifier]

Hi, this change causes our code base to get into a deadlock situation with two components which appear to be awaiting one another's resources, though it's not obvious. Is anyone able to explain more about this fix and what behaviour it affects? We aren't using allowRecurse explicitly anywhere. We're using SFCs and Pinia stores. Pinia stores load in the background and their values are injected into the setup of components which then receive updates via computed properties that depend on storeToRefs() to map the store state to the local component state.

The way that the Pinia stores are loaded in the background is that they return their initial (previously known) state when their computed properties are accessed and as a side-effect they asynchronously fetch from apis and then update their state values. The intention behind our modified stores is that the act of setting a store state value would mark a computed property as dirty and recompute it as needed. We are depending on Vue to allow side-effects, or more specifically to regard any side-effects such as asynchronous closures as non-dirty.

As far as I can tell we have built our stores to look similar to the new test case it should work when chained(ref+computed) previously returning a not dirty flag (since we took advantage of the fact vue doesn't care about computed side-effects), whereas now with this change it returns dirty. Would the way to implement something like this now be to make a customRef which does the asynchronous wait (and lock), and can return its value but not trigger - until the async call returns at which point it sets the value again and calls trigger()

EDIT: For those reading this later, I solved the above problem by following this pattern (can be added to Computed.spec.ts):

  it('should be able to cause ignorant developer side-effects', async () => {
    let val: number = 1
    const v = customRef<number>((_track, trigger) => ({
      get: (): number => {
        // in a real-world app this would be an api call or similar
        setTimeout(() => {
            v.value = 2
            trigger()
          }, 10)
        return val
      },
      set: (value: number) => {
        val = value
        trigger()
      },
    }))

    const sideEffectWatcher = computed(() => v.value)

    expect(v.value).toBe(1)
    await new Promise((resolve) => {
      setTimeout(() => resolve(true), 15)
    })
    expect(v.value).toBe(2)
    expect(sideEffectWatcher.effect._dirtyLevel).toBe(DirtyLevels.Dirty)
  })