Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

watchEffect not triggered sometimes when ref mutation happens inside onMounted #3806

Closed
xinchao-zhang opened this issue May 20, 2021 · 1 comment
Labels
❗ p4-important Priority 4: this fixes bugs that violate documented behavior, or significantly improves perf. 🐞 bug Something isn't working

Comments

@xinchao-zhang
Copy link

Version

3.1.0-beta.3

Reproduction link

reproduce at SFC Playground

Steps to reproduce

Open the included SFC Playground reproduce link, and open the browser dev tool console to check the log

What the code does:

  1. The App renders a Parent component.
  2. The Parent conditionally renders a Child once the "showChild" flag is toggled (async toggled after one second).
  3. The Child component defines a ref (initialized), and registers a watchEffect for it. The ref is set when the Child component is mounted through onMounted hook.

What is expected?

On the console I am expecting to see watchEffect in the Child component to be triggered twice: once immediately, and once when the initialized ref is set. Specifically, I am expecting to see

watchEffect triggered with initialized = true

at the end of the console log

What is actually happening?

watchEffect in the Child is NOT triggered when the initialized is set inside onMounted. Console log indicates watchEffect is only triggered once:

setting state.showChild
watchEffect triggered with initialized = undefined
Child onMounted
@HcySunYang HcySunYang added 🐞 bug Something isn't working 🔨 p3-minor-bug Priority 3: this fixes a bug, but is an edge case that only affects very specific usage. labels May 21, 2021
@HcySunYang
Copy link
Member

HcySunYang commented May 21, 2021

Hint: the root cause is that when jobs in PostFlushCbs are executed, the new pre-flush job may still be queued to PreFlushCbs. This issue may have the same reason as #2730

@HcySunYang HcySunYang added ❗ p4-important Priority 4: this fixes bugs that violate documented behavior, or significantly improves perf. and removed 🔨 p3-minor-bug Priority 3: this fixes a bug, but is an edge case that only affects very specific usage. labels May 21, 2021
@github-actions github-actions bot locked and limited conversation to collaborators Oct 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
❗ p4-important Priority 4: this fixes bugs that violate documented behavior, or significantly improves perf. 🐞 bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants