Add Menu and Navbar components

[mkernohanbc]

Draft PR for initial feedback on design and implementation.

This PR adds two new components:

• Menu and various subcomponents: a dropdown menu for use in cases where a Select is inappropriate (eg. navigation)
• Navbar: a generic navigation bar, implemented based on RA Toolbar

Menu

Menu is logically very similar to Select, and follows the same Collections API.

The MenuTrigger, Menu and MenuItem components are the core parts, but MenuSection, MenuSection and SubmenuTrigger components are also exported to support complex composition:

function App() {
  return (
    <MenuTrigger>
      <Button>This button activates the menu</Button>
      <Menu>
        <MenuSection>
          <MenuSectionHeader />
          <MenuItem />
        </MenuSection>
        <Separator />
        <MenuSection>
          <MenuSectionHeader />
          <MenuItem />
        </MenuSection>
      </Menu>
    </MenuTrigger>
  );
}

Menus can be composed dynamically using the items or sections props, or manually composed via the children slot.

See Storybook docs for a more detailed explanation of the structure of this set of components, and each component's individual API.

Navbar

This is a (currently extremely basic) implementation of an idea we've discussed previously: a secondary navigation menu that can be used alongside the Header component.

What I currently have on this branch is:

• A standalone Navbar component, implemented using RA Toolbar
• A change to Header to natively integrate Navbar via a new subMenuItems prop

Navbar has relatively little internal logic of its own, beyond sizing/spacing and automatically generating <Separator /> elements between items. It is built around a generic children slot, expecting some number of <Link>, <Button>, <Menu> etc.

[mkernohanbc]

@Philip-Cheung these components are feature-complete(ish), but the design is largely judgement calls and mimicking our general design language. Please take a look to familiarize yourself with these components' feature-set and behaviour; when you have a formal design spec, I'll work back on that.

@ty2k would appreciate an initial look over this, particularly the Menu piece. I've taken a slightly different approach to implementation than we did with Select (ie. decomposing into multiple discrete subcomponents), and hit on a bunch of complexity around how to elegantly handle multiple methods of composition (children / items / sections)

[Philip-Cheung]

@mkernohanbc will take a look at this this afternoon

[Philip-Cheung]

Bugs:

When I open the menu, the dropdown menu's focus mode is wrapped around all of the menu items.

[Philip-Cheung]

Not sure what check icon we're using here but its not the icon from our DS: https://www.figma.com/design/6BAmnRmL9FXxY2bkkSYiQj/B.C.-Design-System?node-id=3351-1754&t=MIKwwQnz00xAJTjf-4

[mkernohanbc]

Not sure what check icon we're using here but its not the icon from our DS: https://www.figma.com/design/6BAmnRmL9FXxY2bkkSYiQj/B.C.-Design-System?node-id=3351-1754&t=MIKwwQnz00xAJTjf-4

This tracked back to a discrepancy between FA versions, corrected in 882a9a3

[ty2k]

Very slick! I like the Menu implementation and it seems to work really nicely with keyboard controls, including for complex cases like the Submenu.

I haven't gone through this with a fine-toothed comb because of the amount of code here, but this is a first pass. In general, I think it would be ideal to break this into several PRs:

• One for each SVG icon
• Popover by itself if it's generic
• Menu and MenuItem
• Navbar

[ty2k]

I think Toolbar should just be a regular <nav>.

The issue with Toolbar is it gets the toolbar role, whereas a <nav> gets navigation.

[ty2k]

Is this a general purpose Popover or specific to Navbar and Menu? Can it go in by itself if it's generic? If it's generic, we're already using the Popover from RAC throughout the library, so the names and usage should be reconciled.

If it's specific, can it be renamed for specificity?

[ty2k]

Can we leave it out of Header?

• Better separation of concerns.
• Leaves the Header props cleaner.
• Better customization for breakpoints (contrived example: Header goes from desktop to tablet design at 900px but Navbar needs to change at 750px).

[ty2k]

I see the move to the v6 version of this icon has a different (not square) aspect ratio. Will this cause visual regressions in other components like Checkbox?

Something to think about in general for icons if we're going to mix and match versions of Font Awesome. I think the majority we have right now are following the old square ratio.