Support for Chrome's Document Transitions

[ramiroaisen]

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

[dominikg]

@geoffrich did some exploration here https://github.com/geoffrich/sveltekit-shared-element-transitions

[Rich-Harris]

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 #5478 (comment); I think that would basically solve this issue at the same time. We just need to bikeshed naming

[geoffrich]

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?

[ramiroaisen]

Maybe beforeNavigationUpdate and afterNavigationUpdate

[muellercornelius]

or beforeNavigationDomUpdate and afterNavigationDomUpdate to make i even more clear?

[muellercornelius]

any news on this one?

[dummdidumm]

What news? This feature isn't even finalized from browsers yet, we won't add support before that happens.