Navigation: Add component

I got a VERY early and rough prototype of a Navigation component during early development of G2: https://g2-components.xyz/iframe.html?id=components-navigator--default&viewMode=story#

Having a feature-rich<Navigation /> component would be a VERY welcomed addition in the world of web components. Some features would include:

• Reactive to Route changes (e.g. React Router, Reach, Browser, etc… should be library agnostic)
• Reactive to programatic changes
• Nestable (in theory forever)
• Animations
• Persistent UI across screens (e.g. headers in iOS/Android)
• Focus handling on screen changes

(The React Native world already has this ❤️)

I initially wrote about the requirements, mechanics, and breakdown in detail here: https://github.com/WordPress/gutenberg/pull/24107#issuecomment-662578255

Visual Prototype

An example of this experience can be seen in this CodePen (by @jameskoster) https://cdpn.io/jameskoster/debug/vYGEEpp#

Link to Figma file: https://www.figma.com/file/e4tLacmlPuZV47l7901FEs/WordPress-Design-Library?node-id=1456%3A72

Another Figma Prototype: https://www.figma.com/proto/QNNc834dBBNz1bL2qc9VZyq5/Navigation-experimental?node-id=1765%3A4323&viewport=517%2C73%2C0.14826907217502594&scaling=scale-down

[ItsJonQ]

Updates! I have something working:

Demo: https://g2-components.xyz/iframe.html?id=components-navigator--sidebar

Nested screens work, along with “active” awareness, back/forward navigation awareness + animation sync.

The Navigation component code does work, however, I would not be comfortable using it outside of prototyping. The primary thing that needs to be fixed would be the (current) reliance on React Router Context. The current work-around to avoid app integration conflict is to use a namespace param (which isn’t ideal).

Anywhoo!! It looks + feels promising 😃

Check out the code needed to create this experience: https://github.com/ItsJonQ/g2/blob/master/packages/components/src/Navigator/__stories__/Navigator.Sidebar.stories.js

The components + markup is simple, and should feel very familiar to those who have used React Router (or any routing library). There’s room for improvement, but we should continue with this DX in mind!

Things to Improve

NavigationLink composition

One thing I’d like to improve is this:

<NavigatorLink to="Home">
    <MenuItem>My Home</MenuItem>
</NavigatorLink>

We should have to nest a component under <NavigatorLink />. Instead, it should be this:

<NavigatorLink as={MenuItem} to="Home">
    My Home
</NavigatorLink>

However, this appears to be a limitation with React Router (for the time being)

Animations

Right now, it’s being handled by react-transition-group. I’d like to refactor this in favour of components from the Animation system (@wp-g2/animations). It uses Framer Motion under the hood, which is VERY capable in seamlessly handling stateful mount/unmount transitions.

This will also give us core-level reducedMotion support for free ✌️

MenuItem

The example navigation uses another component for it’s item UI, MenuItem. MenuItem is based on List from Material UI:

https://material-ui.com/components/lists/

As such, it should be enhanced to enable (left aligned) Icon rendering, as well as other features that List offers - such as right aligned actions, a badge count, etc…

[sirreal]

I’d leave a strong vote for using a library and against implementing something when an OSS library (with a compatible license) already has the features we want.

The react / @wordpress/element situation is very painful at times, but I don’t think this is likely to be so relevant. Perhaps https://github.com/WordPress/gutenberg/pull/24107 is the most appropriate place to discuss whether or not to just use react-router?

It seems to me that the only argument against using react-router was the fact that it’s context don’t nest well:

Using a Router (e.g. React Router) for the a nav menu means that it will not be compatible with 3rd party apps using the same Router. (Router context cannot be gracefully shared, as the libraries are built to assume 1 single router instance).

Can we explore that space? That seems like a surmountable problem if its the only argument against react-router.