Re: [csswg-drafts] [css-view-transitions-2] How should view transitions be wired up in frame-timed update loops? (#12125)

> 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?

-- 
GitHub Notification of comment by noamr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12125#issuecomment-2853430530 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 6 May 2025 06:35:37 UTC