search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.58k stars 4.23k forks source link

Components: Update `Navigator` components — Tracking Issue #34907

Open ciampo opened 3 years ago

ciampo commented 3 years ago

This is an overview issue to track all of the tasks necessary to introduce and refine the set of Navigator components, especially in the context of using it in the updated Global Styles Sidebar.

As discussed in numerous previous issues and PRs (#34885, #32923, #34904), the current set of Navigation components feels limited, as it is quite tailored to representing nested menus, and has a quite imperative style.

For these reasons, we would like to replace the current set of Navigation components with a new set of components (for now called Navigator), focused on offering a simple set of APIs to navigate through different "screens" by simply specifying the current screen's path in a simple, declarative way. This new set of components should not be rendering any opinionated pieces of UI.

Improve the component

Adoption strategy

This is a potential strategy, although it needs to be validated:

ciampo commented 3 years ago

A brief recap of what's happened so far:

One of the most recent points of conversation has been about having the Navigation components touching the browser's URL. In https://github.com/WordPress/gutenberg/pull/32923/files#r710975447 @youknowriad has argued that

our components in @wordpress/components shouldn't be exposing anything related to URLs at all as this doesn't make sense in a react native context. If we want to sync the navigation state to URLs, we can still do it in the application layer (edit-site) like done here but I don't see it as a requirement for a start.

I personally believe that we should aim at having a complete set of Routing capabilities powering the Navigation components. The prototype from https://github.com/ItsJonQ/g2/pull/293 features a Routing system heavily inspired by react-router. An idea could be to:

With a feature-full router under the hood, we would be able to pick and choose which type of "routing" (e.g. in-memory, URL-based...) we want to expose from @wordpress/compoments.

griffbrad commented 3 years ago

Regarding routing, Q's original feedback on the current Navigation component is worth revisiting: https://github.com/WordPress/gutenberg/pull/24107#issuecomment-662578255

In particular, he describes how the requirements for the component align very well with the requirements for a router. The challenge with using React Router directly is that its state management and shared context may block using multiple instances of the router for different sub-sections of UI. @ockham and @sirreal chimed into urge further exploration of directly using React Router, though: https://github.com/ItsJonQ/g2/issues/20#issuecomment-681005936

I agree that if we're integrating a routing API, we ought to explore using React Router directly further.

Beyond the routing concerns, though, I think the biggest issue with the current components is that they're designed particularly for navigation menus whereas the structure proposed in G2's Navigator component does not introduce opinionated styles for that use case. Beyond keeping in mind the other navigation-related requirements (e.g. nested layers, tracking "active" state, affecting things outside the menu, outside changes affecting the menu itself), sticking to a Reakit-like approach to styles seems important here so that these components aren't useful only for the particular menus we have in mind now but can be used in any part of the Gutenberg UI without introducing style conflicts.

This issue from G2 goes over some of these style-related requirements:

Note: Navigator and it's sub-components do not render styles (e.g. a dark background). This is by design. These components are effectively (smart) layout components. They are designed to focus on functionality. Aesthetic rendering should be provided by enhancing the sub-components and from the content itself.

stokesman commented 3 years ago

Fix a bug where a horizontal scrollbar would appear during a transition

I've made #35310 as an example of fixing that without worrying about it within the component for now. Don't let the number of changes throw you off. The last two commits are extraneous to the scrollbar fix. They're outdated CSS cleanup and alignment improvement for the Post Editor’s preferences modal. I may just break them off for a separate PR.

In addition to that, I wanted to suggest we improve the animation in the component by having the exiting screen also animate. Apparently, it was that way in the g2 repo and we've got some dregs of that still leftover in ours. I've got #35312 open that restores the framer-motion exit animations. Also, because I was curious about performance differences there's #35311 which does the same but with CSS driven animation.

ciampo commented 3 years ago

Thank you @stokesman for taking the time to contribute to the Navigator component! I've left individual comments on each of the issues that you linked.

Navigator is a very recent component and should be still considered highly experimental. We are purposefully introducing it in its simplest form and adding features or fixes as we experiment with its usage across a few places in Gutenberg. This means that, at the moment, development on the component may move very quickly and change direction often.