[css-view-transitions-2] How should view transitions be wired up in frame-timed update loops?

[dead-claudia]

I got a question about how to integrate view transitions with Mithril, and it's very awkward to integrate. In fact, in the face of frame-timed updates, it ends up actively causing glitchiness, and that very thread ran into such a real-world integration problem.

Mithril, like many frameworks, batches its DOM updates to run all at once within animation frame callbacks for performance.

One of the cause of problems I suspect is exactly that animation frame batching. Microtasks scheduled within renders are delayed until after the DOM is consumed for paint. And I could see this causing timing delays and other glitches during update.

Update: even the "obvious" way to integrate doesn't work:

1. Kick off the transition, save the update callback's promise resolver.
2. Wait for next animation frame.
3. Update the page via new render.
4. Resolve the update promise in the post-update callback (oncreate/onupdate for Mithril, onLayoutEffect for React, etc.).

The API really needs to tolerate this kind of batching and scheduling. It should not be doing its own scheduling and replacing requestAnimationFrame.

Mithril is not alone. Even React and Svelte are almost certainly impacted as they batch renders very similarly.

[dead-claudia]

Okay, I have a proposal:

• Add a controlled: true option to the view transaction factory to start it suspended and delegate update scheduling control to the caller.
• Add a transaction.beginCapture() method to begin DOM update capture. Frameworks and their users would call this upon entering new routes and such.
  • This mirrors the calling of the update callback.
• Add a transaction.endCapture() method to end DOM update capture and enable animations to start. Frameworks and their users would call this after layout completes.
  • This mirrors the resolution or rejection of the update callback.

Frameworks need a single owner of update scheduling. They can't deal with browsers owning some and the framework owning others without significant changes. My proposal removes the scheduling aspect to ease use with frameworks.

[dead-claudia]

Updated the title to reflect the most recent version (and the fact my proposal depends on object options).

[dead-claudia]

cc @DellZHackintosh so you can track updates to this (if you aren't already subscribed).

[astearns]

Tagging editors @tabatkins @noamr @khushalsagar @vmpstr

[noamr]

Doesn't mithril have an "update now" sort of function, like React's flushSync? That would be my first place to look if I was to integrate view transitions with a framework I'm not familiar with (and the way to integrate view transitions with React before the built-in support was en-route).

[dead-claudia]

Edit: clarity, expand on React impact.

Doesn't mithril have an "update now" sort of function, like React's flushSync? That would be my first place to look if I was to integrate view transitions with a framework I'm not familiar with (and the way to integrate view transitions with React before the built-in support was en-route).

We do allow synchronous renders with m.redraw.sync(). However, the popstate handler updates the router's state asynchronously, so you can't just do m.route.set("/path"); document.startViewTransition(m.redraw.sync) and call it a day. Also, with React, there's a non-zero chance that the animation frame callback runs before the view transition callback runs, and so the browser fails to capture state changes correctly.

Also, neither us nor React Router provide hooks to generically intercept route changes to manually schedule the sync update. This not only complicates the state update even for React users, it also causes the whole thing to not even be usable at all with the back and forward buttons.

[noamr]

We do allow synchronous renders with m.redraw.sync(). However, the popstate handler updates the router's state asynchronously, so you can't just do m.route.set("/path"); document.startViewTransition(m.redraw.sync) and call it a day. >

Yea, popstate's sync nature is a bit clunky. the navigation API is a better fit here and is being worked on for interop 2025. Have you considered switching to that?

Also, with React, there's a non-zero chance that the animation frame callback runs before the view transition callback runs, and so the browser fails to capture state changes correctly.

Rendering is suppressed when there is a pending update callback, so this should be impossible.
The update callback, by design, is guaranteed to be called before any subsequent frame updates.

Also, neither us nor React Router provide hooks to generically intercept route changes to manually schedule the sync update. This not only complicates the state update even for React users, it also causes the whole thing to not even be usable at all with the back and forward buttons.

Yea, that's unfortunate and requires integration of view transitions into the framework. I think that's a less error prone design than adding lower level knobs to the platform and expecting app developers to tweak all of them correctly. What stops you from integrating view transitions into mithril in this way rather than expecting devleopers to integrate it from the outside?

[noamr]

#9400 is also a relevant discussion to this.
I do see how the async design of the API makes it difficult to integrate with sync APIs like popstate, and others like popover close events.

The latter is more important in a way because it doesn't have an async equivalent like the navigation API.

We generally try to be careful not to introduce too many low level APIs as it delegates the complexity to callers, but this nonetheless needs to be addressed.

[dead-claudia]

Yea, popstate's sync nature is a bit clunky. the navigation API is a better fit here and is being worked on for interop 2025. Have you considered switching to that?

Yes, I've looked into it. It's way too new for us to be depending on it right now, and I'd prefer to wait for broader compatibility before doing it. (We prioritize stability and compatibility over features - it's one of our selling points. For instance, we only dropped support for IE after Microsoft did.)

Worth noting that React Router updates synchronously, why it can just do that update(); flushSync() sequence. Switching to the Navigation API would break that and cause React Router to be in the very situation Mithril is in right now with respect to view transitions (had they not had native support for them).

Rendering is suppressed when there is a pending update callback, so this should be impossible.
The update callback, by design, is guaranteed to be called before any subsequent frame updates.

Oh, okay. That explains the behavior that was being reported.

Question: are updates held until after the callback resolves or until after the promise resolves?

Yea, that's unfortunate and requires integration of view transitions into the framework. I think that's a less error prone design than adding lower level knobs to the platform and expecting app developers to tweak all of them correctly.

IMHO this should've been communicated from the start, that this needed routers to integrate support for it on their end. I would've strongly preferred to receive a feature request citing a blog post saying it needed router integration than to be in this current situation.

What stops you from integrating view transitions into mithril in this way rather than expecting devleopers to integrate it from the outside?

Ignorance. The Chromium team's blog post made this seem like something users should be able to just integrate themselves, so it seemed like I didn't need to do anything on my end.

[dead-claudia]

#9400 is also a relevant discussion to this.
I do see how the async design of the API makes it difficult to integrate with sync APIs like popstate, and others like popover close events.

For what it's worth, we'd be able to cope with this by exposing an m.redraw.viewTransition() (returning the ViewTransition instance) and just exposing a global router option to use it.

If anything, it's simpler (and less leaky) for a renderer to integrate the current API into its scheduler. Renderers need to potentially call cancelAnimationFrame anyways to avoid double-redrawing, so unless you do #9400, this somewhat needs framework integration in practice anyways. As an example, consider our (relatively compact) redraw scheduler - it's pretty obvious how such a method would be implemented.

[noamr]

Yea, popstate's sync nature is a bit clunky. the navigation API is a better fit here and is being worked on for interop 2025. Have you considered switching to that?

Yes, I've looked into it. It's way too new for us to be depending on it right now, and I'd prefer to wait for broader compatibility before doing it. (We prioritize stability and compatibility over features - it's one of our selling points. For instance, we only dropped support for IE after Microsoft did.)

Understood. As I said, it's in interop 2025 so it's likely to be implemented in Gecko and WebKit before any other change we propose here.

Question: are updates held until after the callback resolves or until after the promise resolves?

Until after the promise returned by the update callback resolves.

Yea, that's unfortunate and requires integration of view transitions into the framework. I think that's a less error prone design than adding lower level knobs to the platform and expecting app developers to tweak all of them correctly.

IMHO this should've been communicated from the start, that this needed routers to integrate support for it on their end. I would've strongly preferred to receive a feature request citing a blog post saying it needed router integration than to be in this current situation.

I don't think this was well understood at the time of designing this API. Note that at the time, frameworks like NextJS had lower level events so integration was easier (this was before "app router"). The blog post you've mentioned was targeted at UI frameworks (React) rather than routers/meta-frameworks (NextJS etc). As the usage evolved we found that there is indeed an integration issue with routers, which usually requires frameworks at that level to integrate view transitions in a built-in way.

What stops you from integrating view transitions into mithril in this way rather than expecting devleopers to integrate it from the outside?

Ignorance. The Chromium team's blog post made this seem like something users should be able to just integrate themselves, so it seemed like I didn't need to do anything on my end.

OK, what's stopping you now? :)
Designing a low level API that would satisfy all of this is definitely possible but there might not be enough energy behind it yet given the complexity it would entail and differences between browser engines. To clarify: the synchronous snapshot idea in #9400, while theoretically possible, is very complex to implement.

[dead-claudia]

Question: are updates held until after the callback resolves or until after the promise resolves?
Until after the promise returned by the update callback resolves.

Okay, good. Means I don't need to add some bolded warnings about knock-on effects in the docs as part of it.

(Sorry for the sloppy wording there, I meant "until after the callback resolves or until after the transition completes".)

OK, what's stopping you now? :)

Just a bit of design work. 😉

Understood. As I said, it's in interop 2025 so it's likely to be implemented in Gecko and WebKit before any other change we propose here.

Yeah, that translates to us probably not going to be able to switch to window.navigation.* until around 2030, unfortunately. Async generators only just recently got enough browser support for me to feel comfortable depending on them, to give you an idea about lead times. (I'm planning, for the next major iteration of Mithril, to build on a baseline of 2020.)