Opting out of async dom updates

[SCLeoX]

We have recently updated preact/signals from 1.3.0 to 2.2.0 and noticed a lot of UI started to flickering. Upon close inspection, we determined this to be the cause: #604. Sorry I cannot share code, but for example:

We have a tooltip component whose layout (width, height, x, y) is controlled by signals. We update the signals on ResizeObserver trigger. However, since now DOM updates caused by signals are triggered one frame after, the component will now be rendered with incorrect dimensions for one frame, then immediately fixing itself to the correct size, resulting in a jarring experience.

This is just one example, and I am sure I can fix this specific case by switching out of signals, but we have a couple more complex components that are now flickering (mostly our own windowing UI framework), and it is not super easy to fix due to their complexity,

We really don't want stay outdated. Thus I am wondering, is this something that can possibly be opt-outed of? Or is it core to the preact signal and cannot be changed.

[JoviDeCroock]

Can we have a reproduction that shows this jank, it's hard to believe that a double micro-task can feel stuttery 😅 unless the task queue is extremely clogged it should be near instant. Are you updating a signal or are you updating a signal that leads to an effect, ....?

A deeper chain like that might lead to odd results but even then if it's

ResizeObserver trigger
--> update signal (double microtask)
--> trigger effect (animation-frame)

It shouldn't really be visible as this is still within the paint cycle of the browser

[SCLeoX]

Thanks for replying. I don't think requestAnimationFrame schedules a microtask. If it schedules a microtask, then I agree it should not be possible to witness the intermediary state.

Here is the reproduction: https://github.com/SCLeoX/async-dom-update-reproduction (mostly just extracted the related components.)

The reproduction shows a tooltip that has an changing height.

With 1.3.2, no flickering:

firefox_M6uAhQPp8c.mp4

With 2.2.0, yes flickering (my recording software drops frames. Thus in the video only the last two updates flickers. However, if you try it yourself, it consistently flickers every update).

firefox_6omZxvBcbG.mp4

Just be clear, I am not claiming this is a bug. I am just trying to figure out what is a good way to solve this issue for our use case. Again, thanks for reading this.

P.S. This is very old code. I think what we are doing is:

ResizeObserver -> Update Signal 1
  -> Computed Signal 2 updates based on Signal 1
  -> Signal effect based on signal 2 that updates the actual style

[JoviDeCroock]

Thanks for replying. I don't think requestAnimationFrame schedules a microtask. If it schedules a microtask, then I agree it should not be possible to witness the intermediary state.

As I said, an effect is raf aligned while a signal/computed update is microtask aligned. As you can see here.

Looking at the reproduction the visual thing is probably related to the signals updating after a micro-task while we then have a dependent effect for resizing.

Maybe the solution is to fork effects when we are running through signal updates and execute dependent effects immediately.

The following snippet could be used to have a synchronous useSignalEffect I will think about this issue more though, just giving you a workaround.

useEffect(() => {
  effect(() => {})
}, [])

[SCLeoX]

@JoviDeCroock This absolutely fixed it! Thank you.

[JoviDeCroock]

@SCLeoX Don't forget the [] as a second argument to useEffect, otherwise this effect will re-create on every render. Apart from that I'll think this through more, thank you for reporting this

[SCLeoX]

@JoviDeCroock Got it. Thanks.