[MenuButton][base] Create the MenuButtonUnstyled component

[michaldudak]

After creating demos for #30961 it became clear that leaving implementation of menu buttons to developers would force them to write a lot of code. We can create an abstraction for a button that triggers the appearance of a menu and responds to keyboard input (in a slightly different way than a normal button - pressing up/down arrow keys should also open the menu).

Bonus points for making it work with SelectUnstyled.

Note: make sure that clicking on the button when menu is open does not cause blinking, as it's currently the case in MenuUnstyled demos (see #32661 (comment), point 1)

[siriwatknp]

@michaldudak I am about to start the Menu for Joy UI as well. What do you think about using button prop to specify the menu button?

// The usage will be like this:
<MenuUnstyled button={<ButtonUnstyled>trigger</ButtonUnstyled>}>
  ...
</MenuUnstyled>

[michaldudak]

Why not follow the pattern we've got elsewhere with componentsProps?

Also, I was thinking about encapsulating all the menuButton related logic in a separate component instead of moving it in the Menu. This way we could have a standalone MenuButton component:

<MenuButton label="trigger">
  <MenuUnstyled>
  ...
  </MenuUnstyled>
</MenuButton>

What do you think?

[siriwatknp]

I like having MenuButton declare first (it is more intuitive because the MenuButton would be the first thing I want to see) but I don't think MenuUnstyled should be a child because when disablePortal: true, The menu renders inside the button which sounds incorrect.

I propose using a popup prop to pass a menu:

<MenuButton popup={<Menu>...</Menu>}>
  Trigger
</MenuButton>

By default, the MenuButton renders a button but if I want to change the component to IconButton I can do this:

const IconButton = styled('button')(...)

<MenuButton component={IconButton} popup={...}>
  <Icon />
</MenuButton>

This MenuButton could also be used with a Dialog:

<MenuButton popup={<Dialog>...</Dialog>}>
  Open
</MenuButton>

What do you think?

Implementation

// MenuButton
return (
  <React.Fragment>
    <button>...</button>
    <Context.Provider value={dataForTheMenu}>{popup}</Context.Provider>
  </React.Fragment>
)

@michaldudak Any thoughts on my proposal?

[michaldudak]

Sorry, it got lost among other notifications :/

I propose using a popup prop to pass a menu

One concern I have with this approach is that having a "large" JSX within a prop doesn't look well, and it's harder to read. Let's consider the following:

<MenuButton popup={(
  <Menu>
    <MenuItem>First</MenuItem>
    <MenuItem>Second</MenuItem>
    <MenuItem>Third</MenuItem>
  </Menu>})>
  Trigger
</MenuButton>

it feels slightly less readable and harder to write (because of nested parenthesis) than

<MenuButton label="Trigger">
  <Menu>
    <MenuItem>First</MenuItem>
    <MenuItem>Second</MenuItem>
    <MenuItem>Third</MenuItem>
  </Menu>
</MenuButton>

By default, the MenuButton renders a button but if I want to change the component to IconButton I can do this

This looks great.

This MenuButton could also be used with a Dialog

That's good, however, keep in mind that MenuButton and Menu need a "special connection" ;)
For example, a menu should open and highlight its first element when Arrow Down is pressed while the menu button is focused. Similarly with Arrow Up. MenuUnstyled exposes the needed methods as an imperative handle, so MenuButton needs to have the Menu's ref.

Having written this, another idea of composition came to my mind - a controlled menu button

const [open, setOpen] = useState();

<MenuButton popupRef={menuRef} onPopupVisibleChange={setOpen}>Trigger</MenuButton>
<Menu ref={menuRef} open={open}>
  ...
</Menu>

This would decouple definitions of menu and menubutton, but require more work from developers (it won't just work upon placing it on the page).

[siriwatknp]

and it's harder to read.

I think it is better than confusion compare to:

<MenuButton label="Trigger">
  <Menu>...</Menu>
</MenuButton>

In JSX, this means Menu is a child of the MenuButton which is wrong. The Menu should be a sibling.

2: The other way is to provide a MenuProvider similar to Chakra UI:

<MenuProvider>
  <MenuButton>trigger</MenuButton>
  <Menu>...</Menu>
</MenuProvider>

3: Or back to my first proposal, add a button prop to the Menu (it looks intuitive to me) which does not require a new component.

// The usage will be like this:
<Menu button={<Button>trigger</Button>}>
  ...
</Menu>

That's good, however, keep in mind that MenuButton and Menu need a "special connection" ;)

Fair enough, let's keep the MenuButton for the menu then.

a controlled menu button

🤔 I rather not go this way.

[michaldudak]

Another idea - how about including the button in the Menu component itself (both Unstyled and Joy)? It would remove the confusion and make things simpler for users. For cases where a button is not required (like a context menu), components.Button could allow null.

Then we would have:

<Menu label="Trigger">
  <MenuItem>...</MenuItem>
  ...
</Menu>

or

<Menu components={{ Button: null }}>
...

[siriwatknp]

Another idea - how about including the button in the Menu component itself (both Unstyled and Joy)? It would remove the confusion and make things simpler for users. For cases where a button is not required (like a context menu), components.Button could allow null.

Then we would have:

<Menu label="Trigger">
  <MenuItem>...</MenuItem>
  ...
</Menu>

or

<Menu components={{Button: null}}>
...

But then what is the root slot? the button or the popper?

<Menu label="Trigger" data-testid="">
</Menu>

// becomes
<button data-testid="">...</button>
<Popper>...</Popper>

I lean toward having the button being root to have a similar experience to the Select.

For cases where a button is not required (like a context menu), components.Button could allow null.

Using button as a root slot would not work well 🥲.

Overall, I still favor MenuButton as a separate component (I might extract Select into Select and SelectButton as well because the current customization experience is not that good).

[michaldudak]

Using button as a root slot would not work well

Perhaps the root slot could be a Fragment by default.

I've taken a look at what the other libraries are doing. Chakra, Mantine, and Radix (with Select, as they don't have the menu yet) use the context approach:

<Menu>
  <MenuButton />
  <MenuList>
    <MenuItem />
  </MenuList>
</Menu>

React Spectrum has another solution:

<MenuButton>
  <button />
  <Menu>
    ...
  </Menu>
</MenuButton>

and FluentUI uses a completely different approach:

<Button menuProps={…} />

[mnajdova]

<Menu>
  <MenuButton />
  <MenuList>
    <MenuItem />
  </MenuList>
</Menu>

This looks most intuitive API to me. And, in addition, we can also support it with the components API:

<Menu
  components={{
    Button: {},
    List: {}.
  }}
/>

[siriwatknp]

@mnajdova @michaldudak I think the resulting API should weigh in:

• MenuButton should be a feature, not breaking changes (fine for Joy and Base but not for Material UI)
• Single DOM per component (this would make customization a lot easier)
• Favor explicit code over too much encapsulation. I think it is better to write a little bit more code that gives me full control of the customization rather than writing a few lines of code but I have to dig into the implementation when customization is needed.

Here is the comparison for all options:

Option 1:

encapsulating all the menuButton related logic in a separate component instead of moving it in the Menu. This way we could have a standalone MenuButton component

Playground: #35671

<MenuButton label="trigger">
  <MenuUnstyled>
  ...
  </MenuUnstyled>
</MenuButton>

Cons

• Might be confused because the result is not the same as JSX. MenuUnstyled is not inside the MenuButton.

Option 2:

Playground: #35719

Having MenuButton declare first but use a prop (popup) to open the Menu:

<MenuButton popup={(
  <Menu>
    <MenuItem>First</MenuItem>
    <MenuItem>Second</MenuItem>
    <MenuItem>Third</MenuItem>
  </Menu>})>
  Trigger
</MenuButton>

Cons

• having a "large" JSX within a prop doesn't look well, and it's harder to read.

Option 3:

Playground: #35778

<Menu label="Trigger">
  <MenuItem>...</MenuItem>
  ...
</Menu>

Cons

• what is the root slot? the button or the popper?
• customization seems harder

  // before
  <Menu variant="...">...</Menu>
  
  // with option 3
  <Menu label="Trigger componentsProps={{ listbox: { variant: '...' } }}>
  </Menu>

Option 4:

Similar to Chakra UI, Menu becomes a provider.

This option is similar to Option 5, please use next playground to evaluate it.

<Menu>
  <MenuButton />
  <MenuList>
    <MenuItem />
  </MenuList>
</Menu>

Cons:

• Is this considered a breaking change for Material UI?
• Menu does not render anything (it is a provider), would it confuse people who are familiar with Material UI?

Option 5:

Quite similar to option 4 but uses a provider name so that it does not break Material UI's Menu component

Playground: #35782

<MenuProvider>
  <MenuButton />
  <Menu>
    <MenuItem />
  </Menu>
</MenuProvider>

Cons:

• Need to import the Provider which looks strange if I want to apply this approach to Select

  <SelectProvider>
     <SelectButton />
     <Select>
       <SelectItem />
     </Select>
   </SelectProvider>

Option 6:

use hook, usePopup instead of MenuButton. (Is it possible to make the hook generic with other components e.g. dialog?)

const { getButtonProps, getMenuProps } = usePopup();

<Button {...getButtonProps()}>
<Menu {...getMenuProps()}>...</Menu>

Cons

• adding custom onClick to the button must be placed in getButtonProps({ onClick }).

Option 7:

Same as #9893 final proposal which uses React.cloneElement(). It does not introduce breaking change.

Playground: #35784

<Menu button={<Button>Open</Button>}>
  <MenuItem>...</MenuItem>
</Menu>

---

Even though I think option 4 is intuitive but I guess it would be a breaking change for Material UI (if yes, I rather go with either option 2, 5, or 6 instead)