Navigator: disable initial animation

[ciampo]

What?

Alternative approach to #48630
Partially addresses #48595

Change the Navigator component so that the very fist NavigatorScreen doesn't perform its initial animation when rendered on screen.

Why?

As described in #48595 , we'd like to disable such animation the component is first rendered, while maintaining the animation when navigating across different menus.

How?

Added a check that will disable the animation if the NavigatorScreen being shown is the initial screen (and it's not a backwards navigation).

Testing Instructions

Storybook:

• Load the Storybook examples
• Make sure that the component doesn't animate on first render
• Make sure that the component animates on every following render (both forwards and backwards)

Site editor:

• Open the site editor
• Make sure that the menu in the left sidebar doesn't animate on first render
• Navigate though the left sidebar menus, make sure that the menus animate in
• Edit a template by clicking the pencil icon (the left sidebar should close)
• Click the "W" logo to reopen the sidebar. Make sure that the menu in the sidebar doesn't animate on its first render
• Navigate to the parent menu, and make sure that the animation is rendered

Check for regressions in other areas of the editor where Navigator is used (the initial animation should be disabled there too, but everything else should work as expected):

• Global styles sidebar
• Preferences modal (on small viewports)

Screenshots or screencast

(Note: in the videos I slowed the Navigator animation to be 2 seconds long, to really showcase the changes from this PR)

Before:

Navigator.no.initial.animation.-.BEFORE.mp4

After:

Navigator.no.initial.animation.-.AFTER.mp4

[ciampo]

Unrelated to this PR:

while testing for this fix, I realised that there is a flash on unstyled text ("Dashboard") when navigating from the "Templates" menu to the "Design" menu.

[jasmussen]

I don't think that's unstyled text, I think that's the tooltip that appears. But I would agree, it would be nice if that tooltip was delayed by something like 2s.

[tomdevisser]

Thank you for working on this @ciampo! I think it's almost there with this change, except for the opacity change when switching between editor/sidebar. The idea from the design viewpoint was that the text is already there, so it shouldn't animate or fade in.

[jasmussen]

Looks good!

Overall it's good to think of these orchestrations not as disparate animations, but as materials that behave according to each other. In this case you could imagine the drilldown navigation to be one long horizontal scroll, that as you literally drilldown moves leftwards, and as you drill back up moves rightwards. In that light, moving it leftwards when you go into editing makes sense, because the canvas pushes it away, and it moves rightwards when you exist the fullscreen editor, because it's pulled back in.

The fades are a separate aspect. I could do with or without them, as they aren't related to the material.

[jameskoster]

In that light, moving it leftwards when you go into editing makes sense, because the canvas pushes it away, and it moves rightwards when you exist the fullscreen editor, because it's pulled back in.

Haha, this behaviour is actually that #48595 was seeking to eliminate :) The motivator being the idea that the Frame (as suggested by its shadow) exists on a layer above the dark material. So entering full-screen edit mode doesn't push the menu away, instead the menus remain in place and the Frame simply expands to cover it visually.

To clarify in slowmo, the aim was this:

slowmo.mp4

Rather than:

slowmo.mp4

[ciampo]

Thank you all for the feedback!

I think that we should differentiate between the two main sources of "animation" that, combined, contribute to the scenario that we're discussing:

• The Navigator component, which is responsible for animating the different "menu screens" when interacting with each menu item
• The sidebar container (I believe called "Site hub" in code), responsible for the open/close/resize animation of the whole sidebar

My suggestion is that we keep this PR focused on the Navigator component, since any changes to the component can have implications in other parts of the editor too (for example, Global Styles and the preferences modal on small viewports). This PR can basically be the first step towards #48595 .

The way the menu (ie. Navigator) gets resized/translated/cropped can be handled in a separate PR, since it's specific to the "Site Hub" container and the @wordpress/edit-site package.

[github-actions]

Flaky tests detected in f51d02a.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4426378795
📝 Reported issues:

• [Flaky Test] shows changes in a template when a template part it contains is modified #42139 in /test/e2e/specs/site-editor/template-part.spec.js

[jasmussen]

Haha, this behaviour is actually that #48595 was seeking to eliminate :) The motivator being the idea that the Frame (as suggested by its shadow) exists on a layer above the dark material. So entering full-screen edit mode doesn't push the menu away, instead the menus remain in place and the Frame simply expands to cover it visually.

Ah yes, thanks for the reminder and apologies for the detour!

[mirka]

Code looks good and tests well 👍