Reactivity regression in 3.14.15

[basvanmeurs]

Vue version

3.14.15

Link to minimal reproduction

https://play.vuejs.org/#eNqdVE1z0zAQ/StbX5IMiU0pHJqmpcB0hnIApjDTiy6uvbHVypJHkp12Mv7vrOSPuGlggBwy1r79ePtWq23woSzDusJgGaxMonlpwaCtygsmeVEqbWELGtdzMHkshNrcuO9EFWVlMYUG1loVMKEEEyaZTJQ0FgqTwbmLmk4+IwXBrdIiPZrMvIuIjYFriwVsmQT61Z3z69kZk80uDScfQ9iu8tR59DCh5RuCezLT6QzOL/qkUQQ3mGk0hisJeWzAKkgVbLjNweo4eeAyA5ujpBPPMtR0nsMdJnFlEBKNsXUenqiqrOEpglq7iF37Bbc8iy1ScjKXWt0JLMKWgEALCdHzXYR1LCok8g7ha5geJbOeqfs5R4kbX8032QOjaNdqh3iR3IemUWkJSVgPFZqxRkLFKfFs9V3HwuBzBenvsICeYxvdZp71tVggFQvOnMC3pCVJQ81zMyc8TiyvuX2CjdIPxuvQBflZdW28pxRPaFgAyz7ZHmuaWiUOMHN8Ozbem+7ZIA0LRjVcYnjV5RmUYXLcEMVY3dn/OdHugr6YsDv14yDw9PT0/0qsonYdaRHp4AIE3TQ6Aazy44vt1q9Z06wiOnkrlyQW1ItCpSjOWUA4pY4IXEWj+GAetJu9KOIyvDdK0u77obMOoNks+9vJAtptd2ZBbm1pllGUpJLCqAavdSjRRrIsoktyi3QlLS9wkari8iR8Gx6/i1Ju7NgeoikWd1ptDGrKwoL5qE5Exhr1QqNMUaP+27p7Yc9q72Ev6rvytE8NyWINzXXNsz1R3C3kAvW30tJb8lwc/zJ98TZ3m4ZmkhyThwP2e/PYNvWdBu6YjQSwsc7QtvDVj6/4SN8DSEOtRDeI34A3aJSoHMfW7WMlU6I98vNsr/2M6W37aa4eLUr3QA5EvRre3w/k0x9a39E9CU8GFZtfULwgAQ==

Steps to reproduce

1. Run the link

What is expected?

Input should show temp2.value: yes because item.v.value is updated which should trigger temp2, test and the watcher.

What is actually happening?

Input shows temp2.value: no

System Info

No response

Any additional comments?

In vue 3.14.12 a similar problem was introduced, which was fixed in 3.14.13. Then in 3.14.15 the same problem was re-introduced but for a more narrow edge case. Faulty commit: c2b274a

[Doctor-wu]

That's the expected behavior, because computed are now only re-calculate and trigger effects when their return values changed.
In your reproduction, the test returned value never changed, so the test didn't trigger effects are desirable behavior.
You can refer to Evan's explaination in the earlier issue.

[basvanmeurs]

Thanks but I think that the refered issue (and explanation) refers to returning an object.

test returned value changes from "no" to "yes", which are both primitive values.

I think that this is a regression caused by multiple levels of reactivity and tracking/triggering from within the same computed. Note that this worked up to version 3.4.14.

As a sidenote, I implemented a good part of the original reactivity system before the 3.4 refactoring.

[Doctor-wu]

I got you now, sry for my misunderstanding. But I still think this is the desirable behavior.

There's a similar test case in this @johnsoncodehk's PR
As a sidenote, I fixed a regression issue which was released in 3.4.14 and Johnson re-fix it in 3.4.15.

[Doctor-wu]

And the dirtyLevel are indeed correct

[basvanmeurs]

I agree that the computed is dirty immediately after getting it. And I did notice the dirtyLevel still being on 2. But this did usually lead to a re-evaluation when accessing it.

But these are just internals.

A computed should always produce the latest valid value, and trigger its dependencies whenever it changes. This is how it always worked up to now. Imho anything different should be regarded as a regression. Just like #10114 was regarded as a regression. The fix just didn't handle this more complex edge case.

The problem lies in the fact that temp2 was evaluated within test. When loaded was enabled, this caused temp2 to be evaluated. After evaluation, it ended up dirty while the 'outer' computed test did not. This end result is undesirable as updates to the inner computed will not trigger the outer computed. I think that a computed, after ending up dirty after evaluation, should automatically re-trigger its dependencies.

[basvanmeurs]

Or alternative solution: re evaluate computeds until they end up not dirty.

[Doctor-wu]

Wait... I think maybe this should work like this case?
The difference is the c2 is MaybeDirty.

[Doctor-wu]

I agree with @basvanmeurs that this is a reactivity regression now.

[basvanmeurs]

Thanks @Doctor-wu

You made me realize that this is an anti-pattern in my code. But it would be nice if we could support recursive triggering and fix this one.

The reactivity refactoring in 3.4 could actually work in favor of this. If a computed retriggers itself we now have the chance to immediately re-evaluate as part of the value getter, before even triggering deps! Of course we needto watch out for infinite recursion and console.warn in case it happens..

[johnsoncodehk]

It should be fixed by #10187. It would be helpful if you could provide a minimal test case.

[Doctor-wu]

It should be fixed by #10187. It would be helpful if you could provide a minimal test case.

I can provide a minimal test later Already done

[basvanmeurs]

The reactivity refactoring in 3.4 could actually work in favor of this. If a computed retriggers itself we now have the chance to immediately re-evaluate as part of the value getter, before even triggering deps! Of course we needto watch out for infinite recursion and console.warn in case it happens..

A PR that explores this opportunity: #10189