Watch not triggered by changes during rendering

[skirtles-code]

Version

3.0.4

Reproduction link

• https://jsfiddle.net/skirtle/5mn349Lp/
• https://jsfiddle.net/skirtle/p51kfg7v/

Steps to reproduce

I've provided two examples but I believe they're both effectively the same problem. In both cases you just need to click the button and then check the logging.

Notice that the logging from the watch gets behind. The new value isn't logged until the following button click.

The first example uses ref attributes to update a reactive ref. The second example uses an updated hook to achieve a similar effect.

The workaround in both cases is to set flush: 'post'. However, that shouldn't be necessary. Any watchers with flush: 'pre' that are still in the queue at the end of rendering should be processed immediately. I haven't checked the code but it may just be a case of going through another rendering cycle when there are outstanding watchers rather than specifically flushing the pre-watchers.

What is expected?

All remaining watchers should be called by the time the rendering loop completes.

What is actually happening?

The watcher isn't called until the next time rendering is triggered.

[asv7c2]

Looks like it by design. doc

[skirtles-code]

@Asv1 I don't see anything in the docs to suggest that this is by design.

Triggering a flush: 'pre' watcher during rendering is an awkward case. There is some wiggle room for deciding what the 'correct' behaviour should be but I don't think it makes sense to leave unflushed items in the queue.

[asv7c2]

When a user effect is queued, it is by default invoked before all component update effects

With template refs you always must use flush post because refs assigned after rendering.

[xinchao-zhang]

@Asv1 I don't see anything in the docs to suggest that this is by design.

Triggering a flush: 'pre' watcher during rendering is an awkward case. There is some wiggle room for deciding what the 'correct' behaviour should be but I don't think it makes sense to leave unflushed items in the queue

Absolutely, and I don't think there is anything awkward in triggering a flush: 'pre' watcher during rendering. After all, you are not directly triggering a watcher, you are just mutating reactive data and expect the reactive system to do its job.

To me, whether a watch effect should be executed is the definition/contract of watchEffect - it should be, and mostly is, very simple: the effect will run whenever the reactive data it depends on changes.

However, when and in what order effects are actually executed is an implementation detail. It is totally fine for the scheduler to queue an effect to an later (post or next pre) stage, but it still needs to execute the effect eventually.

When a user effect is queued, it is by default invoked before all component update effects

With template refs you always must use flush post because refs assigned after rendering.

I don't think the document is suggesting it is the golden rule for template ref watchers to always be post flush. Without flush: 'post' the watchEffect normally triggers fine (the abnormal cases are this issue and the issues it links to). You only need flush: 'post' when your effect needs to access the updated DOM as I understand. In other words, flush: 'post' is not to influence whether an effect will be triggered, but when it is triggered.

[skirtles-code]

I think this will be fixed by b57e995, which is available in 3.1.0-beta.5.

[HcySunYang]

Fixed in b57e995