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]

Above all the discussions between us are based on one thing you are not supposed to trigger some effects in computed which is explicitly documented as a bad practice: https://vuejs.org/guide/essentials/computed.html#getters-should-be-side-effect-free
In theoretical perspective, your words make great sense. And in the long term, I think this behavior should be implemented in the codebase, maybe in a better way.

[Doctor-wu]

What I really want to referred about Evan's explaination is this

I think this might be better off in the long run that the new behavior is revealing problematic / incorrect usage of computed and force users to move away from such patterns.

[Doctor-wu]

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

This might be a solution, didn't know if it would impact other behaviors out of our expected.
Maybe we can do it in the DEV env and throw an error when there exceeds the limit if it doesn't impact a lot.

[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.