kit
kit copied to clipboard
sveltejs
Support for Chrome's Document Transitions
Describe the problem
This issue is to track support for Chrome's Document Transitions API AKA Shared Element Transitions on navigations inside sveltekit
More info about Chrome's feature and status can be found here:
https://github.com/WICG/shared-element-transitions/blob/main/developer-guide.md https://github.com/WICG/shared-element-transitions/blob/main/explainer.md https://chromestatus.com/feature/5193009714954240
The only reason this is hard to implement in userland is because the time between beforeNavigate and afterNavigate could be considerable considering sveltekit may have to make an http request in the middle of it or importing other modules.
Describe the proposed solution
Provide hooks like afterNavigate and beforeNavigate but that triggers just before and after the dom updates.
That way the user can call document.createDocumentTransition on their own
Alternatives considered
Provide a property in the sveltekit.config.js file to optionally enable this feature.
This way is the simple one, sveltekit just have to call document.createDocumentTransition before new navigations updates the dom, update the dom and then resolve the promise.
Importance
nice to have
Additional Information
No response
@geoffrich did some exploration here https://github.com/geoffrich/sveltekit-shared-element-transitions
I think we need to add a lifecycle function that runs immediately before the DOM updates that are followed by afterNavigate for the purposes of https://github.com/sveltejs/kit/issues/5478#issuecomment-1189562537; I think that would basically solve this issue at the same time. We just need to bikeshed naming
May I suggest: beforeAfterNavigate? And then we could have a counterpart, afterBeforeNavigate (mostly kidding)
But yes, this would be super helpful for integrating with shared element transitions. My demo currently starts the transition in beforeNavigate, which has the downside of waiting for a network call to complete the transition. It would be better to start the transition after the network call but before the DOM is updated so the page can still be interactive while the network call happens -- once you call transition.start, the page is basically a static screenshot.
From the explainer:
The API supports asynchronous DOM updates, which are common in most frameworks. To make this work, callback should return a promise that resolves once the DOM update is complete. However, remember that the user is left with a non-interactive screenshot between callback being called and its promise resolving, so this should happen as fast as possible. Specifically, avoid things like network activity – do those before creating the transition, like this:
As for bikeshedding: if we're going after your previous comment, perhaps beforeNavigateCommit? Though that's a little obtuse. beforePageUpdate?
or beforeNavigationDomUpdate and afterNavigationDomUpdate to make i even more clear?
What news? This feature isn't even finalized from browsers yet, we won't add support before that happens.
Revisiting this now that the View Transitions API (as it's now called) is in Chrome stable. Opened a PR, would be glad for feedback from anyone who has played around with this stuff: https://github.com/sveltejs/kit/pull/9605