💡 RFC: Improve the page transition experience

[diegoleme]

Background & Motivation

When we are in a SPA we have some options to make a smooth page transition.

• https://developer.chrome.com/blog/shared-element-transitions-for-spas/
• https://router.vuejs.org/guide/advanced/transitions.html

There are initial discussions on how to do this for multi-page applications

• Cross-origin MPA transitions WICG/view-transitions#44

And there are js libraries that apply solutions on how to make these transitions:

• Turbolinks: Please note that Turbolinks is no longer under active development. It has been superseded by a new framework called Turbo, which is part of the Hotwire umbrella.

Proposed Solution

Possible solutions

Integration with Turbo Drive and Turbo Frame

• Turbo Drive accelerates links and form submissions by negating the need for full page reloads.
• Turbo Frame decompose pages into independent contexts, which scope navigation and can be lazily loaded.

Risks, downsides, and/or tradeoffs

• Impact performance by adding more js

Open Questions

• Is it possible to do this as an extension?

Detailed Design

No response

Help make it happen!

• I am willing to submit a PR to implement this change.
• I am willing to submit a PR to implement this change, but would need some guidance.
• I am not willing to submit a PR to implement this change.

[gabrielgrant]

Agree that something like this is becoming important for a good MPA experience. There is an extension that does some of this: https://github.com/RafidMuhymin/astro-spa

Curious to hear how what you're proposing with Turbo would compare to that?

[jasikpark]

I feel like this is more complicated than #1511 b/c it requires a bit of coordination around making sure that scripts and CSS are all setup correctly when preventing page reloads, whereas #1511 is just prefetching pages + a full page reload

[tony-sull]

https://swup.js.org/ Swup.js is a good option for an add-on package that adds animated page transitions, they have some really handy plugins as well for things like accessibility and Google Tag Manager

[okikio]

I think this relates to PJAX and barbajs, imo it should wait until the appHistory API is better supported.

[FredKSchott]

Discussion:

• Similar to 💡 RFC: Speed up subsequent page-loads by prefetching in-viewport links during idle time #1511
• some features in Astro might be missing to make this easier / support more userland libraries
• some docs might be missing to help guide users to integrate those 3rd party things
• focus/prioritize bugs with 3rd party libraries (!!!)
• focus/prioritize understanding 3rd party libraries so that we can design the best one possible, if we do go to build

Consensus:

• Lets explore this in user-land first (components, scripts, etc.) and revisit later if there's anything worth bringing into Astro builtin

[okikio]

What type of metadata is Astro currently missing that would go a long way to making this RFC easier to implement.

[jonathantneal]

What type of metadata is Astro currently missing that would go a long way to making this RFC easier to implement.

Possibly dependencies (JS, CSS), but possibly something like hashes (for caching, just some kind of flag for the frontend to leverage).

[delucis]

I have a related use case: a site with a media player. Media playback should persist across page navigations, but the bulk of the page is just static content, so Astro’s islands approach makes sense. I’ve had success using Swup to make this work, reloading most of the page and just preserving the media player across navigations.

So, next challenge and the one where I wonder whether an Astro API may be needed: some pages render inline components that need hydrating. Because a page transition library removes the page load, we need to handle this ourselves. In Astro 0.20.x, I had a working if slightly hacky model based on @RafidMuhymin’s approach from astro-spa: components and component hydration scripts were colocated in the page source:

<div id="swapped-on-navigation">
  <!-- static stuff -->
  <astro-root ... />
  <script that hydrates the above astro-root></script>
  <!-- static stuff -->
</div>

<div id="persisted-across-navigations">
  <astro-root ... />
  <script that hydrates the above astro-root></script>
</div>

So it was possible to grab the swapped content and retrigger each script block hydrating only the replaced content.

In 0.21.0, Vite does a nice job of bundling everything up so we just get a tidy little script tag in <head> that loads the hydration logic. Generally that seems like a good idea, but it breaks the (hacky) hydration approach I describe.

Would it be possible to have some kind of API like:

Astro.requestHydration(['component-id', 'component-id', ...]);

// or even better
Astro.requestHydration('#container-selector');

That way when managing page transitions, you can 1) handle loading new content, 2) insert it into the page, 3) request a hydration that would be consistent with the usual hydration.

Given the zero JS by default approach, I’m not sure what would be ideal in terms of deciding when the bundle needs this requestHydration logic. Maybe something like <Component client:load|request />? That part I’m not sure of.

[FredKSchott]

Hey everyone! Our current RFC process is beginning to break down at this size, with over 50 open RFCs currently in the "discussing" stage. A growing community is a great problem to have, but our ability to give you RFC feedback has suffered as a result. In an effort to improve our RFC process, we are making some changes to better organize things.

From now on, all RFCs will live in a standalone repo: https://github.com/withastro/rfcs

This allows us to do three things: 1) Use threaded discussions for high-level ideas and improvements, without necessarily requiring an implementation for every idea. 2) Improve the quality of our RFC template and the speed/quality of all feedback. 3) Support inline comments and explicit approvals on RFCs, via a new Pull Request review process.

We hope that this new process leads to better RFC weekly calls and faster feedback on your RFCs from maintainers. More detail can be found in the new RFC repo README.

---

We can't automatically convert this issue to an RFC in the new repo because new RFC template is more detailed that this one. But, you can still continue this discussion in the new repo by creating a new Discussion in the RFC repo and copy-and-pasting this post (and any relevant follow-up comments) into it. Discussions are available for high-level ideas and suggestions without the requirement of a full implementation proposal.

Then, when you are ready to propose (or re-propose) an implementation for feedback and approval, you can create a new RFC using the new RFC template. More detail about how to do this can be found in the new RFC repo README.

Thanks for your patience as we attempt to improve things for both authors and reviewers. If you have any questions, don't hesitate to reach out on Discord. https://astro.build/chat

[RobbieTheWagner]

Did this get ported over to the new RFCS? Very interested in page transitions!