Trying out the Page Transition API

We tried out the Page Transition API at the HyväCamp 2022 Hackathon

Last week, a tweet from Jake Archibald of Google shared some a exciting new API.

I've been dying to share this for weeks now… Introducing the page transition API!

It's still in-development, but you can play with it today. I'm really happy with where this API is heading. I hope you like it too!https://t.co/R0ssmYgeKC

— Jake Archibald (@jaffathecake) May 12, 2022

The video linked from Jake's message looked promising, so we decided to give it a try during the hackathon.
New tech is always fun, and this looked like it might be a useful progressive enhancement for stores.

Page transitions are also sometimes mentioned as one of the last remaining argument to justify the overhead of creating a SPA (single page application, often confused with PWA), even though they are rarely implemented in practice.
With this new API proposal page transitions would be simple to build in multi page websites.

The Plan

We started on a fresh new Mage-OS 2.4.4 instance with Hyvä 1.1.14 and a simple plan:

1. Re-watch the video
2. Install Chrome Canary
3. Change pagination on the product list page to use JavaScript
4. Implement Page Transitions, first for pagination in the list, and then - if there is time - to the transition to a product page.

Step one: re-watch the video

It is an entertaining, well-made 12 minutes, so that was easy to do:

Step two: install Chrome Canary

Since the Page Transition API is so new, it is only available in Chrome Canary.
After installing the browser, we enabled the required Prerender2 and documentTransition API feature flags.

Step three: change pagination to client side

This was quickly done by adding this script to the Magento_Catalog/templates/product/list.phtml file:

The .page selector matches any pagination link.

Please note that `hyva.replaceDomElement` was added to Hyvä in version 1.1.14

After this was done we where ready for step three - but first it was time for some excellent lunch (thanks Integer_net!).

Step four: implement the Page Transitions

We decided to skip the codelab and dive straight in only with the info from the intro video.

To start we wanted to have the default fade transition for the product listing, then change that to a slide effect, and finally add a zoom effect to the product image when transitioning to the product detail page.

We started by adding defining some keyframes and styles inline, close to how it was as described in the video:

Then we added the JavaScript to trigger the transition API. This is the example code given in the developer guide:

This is what it looked like in our template:

The results where bit quirky. We got a strange blend effect on the page logo, and the products on the page where "jiggling", but certainly not blending.
So we started tweaking the styles, trying to understand what we needed to do.
The feature wasn't exactly stable yet, probably to be expected for a new feature in a nightly build.

After some time we managed to isolate the transition effect to the slice of the page we were interested in, and also added the slide effect.
Looking at the styles of the demo app referenced the codelab was very helpful.

It turns out, some resets needs to be declared before being able to apply transitions properly. I hope this step will become obsolete when the API matures before release.

Some funky behavior remained. For example, when renaming a keyframe from slide-in to in-left-to-right, it stopped working.
It only worked for us using slide-in and slide-out. This is especially weird because in the demo app keyframes are named for example _slide-from-right_1bx3g_1.
I'm sure these quirks will be ironed out soon.

After about three hours it was time to wrap up, and we had the slide transition in the product listing working well.

Many thanks to my colleagues Sean and Ruud in the Hackathon - it was a lot of fun, and I hope we get a chance to do something like that together again!

Also thanks to Jake Archibald and the team there for creating a great API and for publishing such an inspiring video!

The Result

Desktop view

Mobile view

Real World Use Cases

Of course, today the new page transition API is an experimental feature in Chrome Canary, so it might take a while for it to land in a stable Chrome release, and then the question remains how long it will take before other browsers pick up on the technology.

We're happy to see Adam Wathan from Tailwind CSS also ready to dive into the technology, so we'll have native Tailwind support when the feature becomes available in a stable Chrome release.

The new page transition experiments are really exciting, going to play with it with Tailwind when I get a chance this week https://t.co/VT6ueGqq7V

— Adam Wathan (@adamwathan) May 15, 2022

We joked about "next year in Chrome, the year after in Firefox and in 10 years it'll be in Safari" during the hackathon, but who knows! The great thing is that the API is gracefully falling back to standard behaviour so it doesn't break anything in browsers that don't support it yet.

And it shows us yet again that all the powerful features needed for a great user-experience can be implemented by the browser instead of by a JavaScript library that adds hundreds of kilobytes to the payload of the page. It adds yet another argument to the discussion that a usefull PWA does not need to be a SPA, nor does it require a JavaScript DOM rendering engine to power it.

Once these technologies mature and the real need for specific PWA features are clear, we'll start to add those features to Hyvä. Page transitions already look like a promising feat to add to that list.