feat(drilldown): added drilldown menu

[mattnolting]

fixes #2635

Parent menus control placement of children. If pf-m-drilled-in is applied to pf-c-menu, the menu shifts to the left transform: translateX(-100%), out of view. The nested, children menus are positioned left: 100%;, until .pf-m-drilled-in is applied, where then transform: translateX(-100%) is applied.

Immediate parent li of the current menu has .pf-m-current-path applied. pf-m-current-path hides sibling, non-current li s and sets their visibility to hidden. We need to use visibility here because JS will need to reference height of lists when showing/hiding them.

[patternfly-build]

Preview: https://patternfly-pr-3438.surge.sh

A11y report: https://patternfly-pr-3438-coverage.surge.sh

CSS Size Report

Name	Current	Previous	Diff %
components/Menu/menu.css	12.6 kB	9.4 kB	25.17
patternfly-no-reset.css	888.9 kB	885.7 kB	0.36
patternfly.css	890.8 kB	887.6 kB	0.36
patternfly.min.css	788.3 kB	785.5 kB	0.36

[mattnolting]

@mcoker @christiemolloy examples have included JS to replicate React state mgmt. I'll remove that before final review.

[mcarrano]

This is looking good @mattnolting . My only critique is that when you drill into a new level, I believe that the header should show the name of the parent node rather than just the text "Back". To return up a level, the user would click the "<" icon. Does that make sense to others?

[doruskova]

@mattnolting @mcarrano Agree with showing the current level and use the back arrow for going back. However, it looks great to me. :)

[mcoker]

To return up a level, the user would click the "<" icon.

@mcarrano do you mean only the arrow would be clickable, and not the entire item? (arrow + parent node name)

[mcoker]

This looks great! I'll dig in some more, but some initial questions:

1. Do we need to animate the height? or could we just animate translate/opacity of menus coming in/out from the left/right? That would simplify the logic and increase the performance of the animation.
2. Not sure about the width… if we keep it, need to use pf-size-prem(). Did you try letting the width be determined by the contents of the menu?
3. Mentioned this outside of the issue, but I think we should be specific about the properties we animate on which items. Currently we're animating "all" on everything and on items that I wonder if need animation, like __menu-item.

[mattnolting]

1. Do we need to animate the height? or could we just animate translate/opacity of menus coming in/out from the left/right? That would simplify the logic and increase the performance of the animation.

To accomplish the left/right transition, I had to hide overflow, limiting the viewable children to the root dropdown menu width. Which means using the parent menu as the background for all child menus. Otherwise you would see child menus fading into view to the left/right of the initial dropdown. So it would be more of a fade in/fade out transition than a slide in/slide out transition. I couldn't find another way do that, also the dropshadow interferes with transitions when using the child menu's background.

2. Not sure about the width… if we keep it, need to use pf-size-prem(). Did you try letting the width be determined by the contents of the menu?

Since I used the width of the parent menu for all children, I had to set a base width. We could apply that css variable to the menu component making it easily changeable and set the base size w/pf-size-prem().

3. Mentioned this outside of the issue, but I think we should be specific about the properties we animate on which items. Currently we're animating "all" on everything and on items that I wonder if need animation, like __menu-item.

Yep, agree 👍

Here's the prototype I created if you want to experiment with it : https://codepen.io/bobcatTaco/pen/pogQbmY

[mcarrano]

This is looking great. I love the animation @mattnolting ! The only thing I would change is what shows up in the breadcrumb header when you drill down. Rather than being just a back link, it would contain the title of the parent node that you are viewing the contents of. The user would need to click the "<" to go back up a level. See how the Move To feature works in Google Drive, for example. Here's what that looks like:

Only the back-arrow is interactive.

[mcoker]

This looks good to me! Can you update the transitions to be more specific?

[mattnolting]

Looking at the JS interactivity, I noticed when I click on a menu item, it opens the next menu very quickly and I feel like I lose my position, could the keyboard focus / tabindex go straight to the top of the menu?

@christiemolloy Great point, i'm not sure how to do this statically. I'd like to shift this to React.

[mattnolting]

@christiemolloy @mcoker updated

[mcoker]

did you mean to add this?

[mattnolting]

I did, but maybe better addressed in another issue :)

[mcoker]

Suggested change

	--pf-c-menu--m-drilldown__list--TransitionDuration--transform: transform var(--pf-global--TransitionDuration);
	--pf-c-menu--m-drilldown__list--TransitionDuration--transform: var(--pf-global--TransitionDuration);

[mcoker]

Just one thing to fix a broken transition, and a question about the divider.

[christiemolloy]

LGTM!!!

[mcoker]

NICE!!!

[redallen]

🎉 This PR is included in version 4.55.0 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀