Navigator: add support for exit animation

[ciampo]

What?

Part of #59418
Requires #64786 to be merged first

Add exit animations to Navigator screen

Why?

An exit animation can help the user understand the transition to a new screen better — and gives an additional sense of polish to the UI.

The animation specs (durations, delays, easing functions) are also updated following the latest motion guidelines (cc @nick-a8c)

How?

• Added a useScreenAnimatePresence hook which takes care of managing the screen's animation lifecycle
• Use CSS transitions to animate the screen
• Use data- attributes to set animation state on the DOM element, which is used to trigger the CSS transitions
• Use CSS grid on the provider to force all screens to overlap, while also pushing the height of the container
• Always render the screen root element, while conditionally rendering its contents
• Updated tests to completely skip animations, that were causing errors and general flakiness
• Added a note in the README about setting the wrapper height (related conversation in Navigator: polish Storybook examples #64798 (comment))

Testing Instructions

• Make sure that the animations are always applied to the pair of screens (the one transitioning in and the one transitioning out), both when navigating to a new screen and back to the parent screen;
• Make sure that the animations work as expected on all supported browsers;
• Make sure that the animations are not performed when enabling "reduced motion" browser/OS settings

Testing Instructions for Keyboard

Screenshots or screencast

navigator-exit-animations.mp4

10x slow-motion:

navigator-exit-animations-slowmo.mp4

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ciampo <[email protected]>
Co-authored-by: mirka <[email protected]>
Co-authored-by: tyxla <[email protected]>
Co-authored-by: jsnajdr <[email protected]>
Co-authored-by: jasmussen <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[jasmussen]

Nice. Is it possible to test this in the site editor? It's not clear that the new animation from this branch is applied there:

Here's trunk for comparison:

[ciampo]

It appears that the site editor sidebar doesn't use Navigator anymore — looking at the file history, the change happened in #60466. I was on parental leave at the time, but it seems like the main reason was to use the global site-editor router instead of having to coordinate with Navigator's internal router.

Navigator is still being used in the Global Styles sidebar, though.

[mirka]

Animating presence will likely be a recurring need. How can we abstract this into something encapsulated and reusable, so we don't have to add in a bunch of ad hoc animation coordinating logic into a component every time we need an entry/exit animation?

Not immediately sure if we should use a library like react-transition-group (maybe 1.7kB gzipped if we only needed the Transition component), or if we want to maintain our own for an even smaller size. Thoughts?

[ciampo]

Animating presence will likely be a recurring need

That's true, although in many cases, animating presence can be done with some recent CSS features. But those can't be used with Navigator because we remove a Screen's markup when the screen gets deselected.

Not immediately sure if we should use a library like react-transition-group (maybe 1.7kB gzipped if we only needed the Transition component), or if we want to maintain our own for an even smaller size.

I'm conflicted — on one end, I don't like to reinvent the wheel if the problem has been solved well by third-parties. On the other, we're trying to move away from framer-motion for smaller bundle size and better performance (using CSS native features as much as possible).

If we used react-transition-group, we'd need to use the CSSTransition component (2.6kB), since the Transition component is just the abstract logic.

Also, this specific type of animation will be much easier when view transitions become more advanced and better supported in the next few years.

How can we abstract this into something encapsulated and reusable, so we don't have to add in a bunch of ad hoc animation coordinating logic into a component every time we need an entry/exit animation?

I wonder if doing so would represent a form of early optimization. Maybe we can keep Navigator as-is, and re-discuss this topic if/when we have more real use cases for animating presence, so that we can better understand what type solution we'd need to implement?

[mirka]

I wonder if doing so would represent a form of early optimization. Maybe we can keep Navigator as-is, and re-discuss this topic if/when we have more real use cases for animating presence, so that we can better understand what type solution we'd need to implement?

I'm not familiar enough to make a confident judgement in either direction, but I trust you on your assessment after working on it.

I guess what immediately makes me a bit uncomfortable though is how the animation logic is interspersed in the component code. Do you think it would be worth the effort to extract most or all of the animation logic into a single hook? No regard for reusability at the moment, but just to isolate all the animation concerns into a single place. I'm already a bit afraid of touching this code, and I think separating the concerns would help a lot to ease that sense of complexity.

[ciampo]

Rebased to include all recent Navigator changes. I will look at addressing the remaining feedback by the end of the week

[ciampo]

I guess what immediately makes me a bit uncomfortable though is how the animation logic is interspersed in the component code. Do you think it would be worth the effort to extract most or all of the animation logic into a single hook? No regard for reusability at the moment, but just to isolate all the animation concerns into a single place.

This is a great suggestion, I definitely agree. I pushed a couple of commits and things are looking much more clear :)

[tyxla]

I still need to test and review this thoroughly, but I'm submitting some early, naive feedback.

[jsnajdr]

I don't have any further feedback, everything has been addressed. The glitch with Typography panel is solved. I think this is ready to 🚢

[t-hamano]

This PR seems to have caused problems with the shadow preset panel and font size preset panel.

Looking at the browser error log, it might be a problem with the implementation of the shadow/font size preset, but could you take a look at the following issue?

• Shadow/Font size preset panel crashes the editor #65711

[ciampo]

This PR seems to have caused problems with the shadow preset panel and font size preset panel.

Looking at the browser error log, it might be a problem with the implementation of the shadow/font size preset, but could you take a look at the following issue?

• Shadow/Font size preset panel crashes the editor #65711

Thank you for flagging — left a reply in the issue itself.

[jeffpaul]

@nick-a8c would you mind sharing your WordPress.org username so we can ensure you're properly credited in the 6.7 release next week?