Menu Component Improvements

[alexlafroscia]

Menu Avoids Rendering a DOM Node

The Menu component in the React/Vue implementations does not render a DOM node by default. It can, because I believe they want to make sure that all components can use an as= property to configure the node that's rendered, but by default it just renders a Fragment (which results in nothing in the DOM).

Since Ember doesn't really have a concept of a Fragment, I think that not rendering a DOM node at all is closer to the React/Vue implementation than rendering a div.

Note: This is a breaking change, as any attributes or modifiers placed on this element should be moved to a new parent div element

Before

<Menu data-test-menu class="bg-gray" as |menu|>
  ...
</Menu>

After

<div data-test-menu class="bg-gray">
  <Menu as |menu|>
    ...
  </Menu>
</div>

Menu::Items Focusing on Render

From the Headless UI documentation on the Menu:

Clicking the MenuButton toggles the menu and focuses the MenuItems component.

Using the focus trap here is a little unintuitive, because the menu item elements themselves are not focusable. However, this is a useful approach because

• Focus should be locked within the menu anyway, per the accessibility requirements of a menu
• Focus needs to be returned to the previously-focused element when the menu closes, which the focus-trap modifier will do for us

The documentation for the focus-trap library describes how you should handle a case where the element that focus is trapped within has no focusable children, which is to focus the "wrapper" element itself using initialFocus, which is the approach taken here!

Using the focus-trap library to return focus to the trigger button should resolve the weirdness around focus returning to the wrong element sometimes. focus-trap will also handle the "press-escape-to-dismiss-the-menu" behavior for us without needing additional logic for that.

Closes #55
Closes #54

[alexlafroscia]

Something isn't quite right with the way the focus trap is being used -- I'll mark this is ready once I fix that up!

[GavinJoyce]

I think the existing API is a little nicer to work with, but 👍 on the change if it brings us closer to the React/Vue APIs

[alexlafroscia]

I think the existing API is a little nicer to work with

Just to clarify, you'd prefer that Menu does have a DOM node of it's own?

I'm thinking about a case where someone builds out a component that wraps Menu. If it were me, I would do something like this:

{{! app/components/my-menu.hbs }}
<Menu as |menu|>
  <menu.Trigger
    {{did-insert (set this 'menuTrigger')}}
    ...attributes
  />
  <menu.Items
    {{popper-tooltip this.menuTrigger}}
  />
</Menu>

If Menu creates a DOM node of it's own, I probably need some way to add classes to both Menu and the menu trigger since that might end up being necessary to get the layout where this component is used correct. Needing to think about both of these nodes is unnecessary overhead from the perspective of someone making use ofMenu. If I want that wrapper node, it's easy to wrap this whole thing in a div, but I bet in most cases it would be better to conceptually map my component to a single DOM node, the menu trigger.

[alexlafroscia]

I'd love to get a review from @achambers as well before merging, just to make sure everyone's on the same page with the changes here since it's a breaking change!

Edit: Upon thinking about it more, I'd love verification that this indeed closes the two tickets that I linked to as well. I'm pretty sure it does but would love to make sure!

[GavinJoyce]

I'm thinking about a case where someone builds out a component that wraps Menu. If it were me, I would do something like this

👍 I'm convinced by your example, thanks

[achambers]

Love your work @alexlafroscia. I'm in support of this improvement. Thanks.

[alexlafroscia]

Thanks @achambers !