DropdownMenuItem and ContextMenuItem VS just MenuItem

[buffaybu]

I'm building a component library based on Radix Primitives and come across a design question: Why there are DropdownMenuItem and ContextMenuItem instead of just MenuItem (likewise MenuContent/MenuCheckboxItem/MenuSeparator/...)?

Expected API:

<>
  <DropdownMenu>
    <DropdownMenuTrigger />
    <MenuContent>
      <MenuItem />
      <MenuSeparator />
      <MenuCheckboxItem />
    </MenuContent>
  </DropdownMenu>

  <ContextMenu>
    <ContextMenuTrigger />
    <MenuContent>
      <MenuItem />
      <MenuSeparator />
      <MenuCheckboxItem />
    </MenuContent>
  </ContextMenu>

  {/* a more aggressive one */}
  <Menu>
    <DropdownMenuTrigger />
    <MenuContent>...</MenuContent>
  </Menu>
</>

The only difference between DropdownMenu and ContextMenu is the trigger and it feels cumbersome for a library to export different menu content components. Mui has only one Menu (in this case, MenuContent) and can be combined with any kind of triggers.

It seems that the implementations of DropdownMenuItem and ContextMenuItem are identical except for useMenuScope which is declared locally at the module level. If useMenuScope is the only difference, is it possible to pass the hook by a context provided by the root component? Or is there any concern to have a common MenuItem?

[benoitgrelard]

hi @buffaybu,

We do this by design for a few reasons:

1. There are sometimes accessibility differences which warrant differences for each uses case, we may realise this later down too.
2. Having a unified API for each component reduces breaking changes down the line as it gives us more freedom to make changes in specific implementations without impacting other primitives.
3. DX is better for first time use and less experienced developers as they get all the parts from one package.

In the case of DropdownMenuItem and ContextMenuItem, you are correct that they are mostly equivalent and extend our internal MenuItem. In fact, before the introduction of context scoping (#906) they were the same. That change kinda goes in hand with what I explained in point 2. as it would have been a breaking change otherwise.

I hope this helps you understand our decisions to go this direction.

Additionally, we are always keen to understand use-cases and figure out where people hit barriers so with that in mind, can I ask what situation prompted your question? Where is the friction day to day with this? Is it when trying to share the styles for both?

Thanks! 🙏

[buffaybu]

Where is the friction day to day with this? Is it when trying to share the styles for both?

Yes, for sharing styles and for sharing menu content.

For example, Google Docs allows a user to trigger the menu by a right-click...

...or a left-click on the menu icon.

To archive this with Radix Primitives I have to write this and keep them sync manually:

const dropdownMenu = (
  <DropdownMenu>
    <DropdownMenuTrigger />
    <DropdownMenuContent>
      <DropdownMenuItem>Item 1</DropdownMenuItem>
      <DropdownMenuSeparator />
      <DropdownMenuItem>Item 2</DropdownMenuItem>
    </DropdownMenuContent>
  </DropdownMenu>
);

const contextMenu = (
  <ContextMenu>
    <ContextMenuTrigger />
    <ContextMenuContent>
      <ContextMenuItem>Item 1</ContextMenuItem>
      <ContextMenuSeparator />
      <ContextMenuItem>Item 2</ContextMenuItem>
    </ContextMenuContent>
  </ContextMenu>
);

Instead, I wish I could write the same menu content once:

const menuContent = (
  <>
    <MenuItem>Item 1</MenuItem>
    <MenuSeparator />
    <MenuItem>Item 2</MenuItem>
  </>
);

const dropdownMenu = (
  <DropdownMenu>
    <DropdownMenuTrigger />
    <DropdownMenuContent>
      {menuContent}
    </DropdownMenuContent>
  </DropdownMenu>
);

const contextMenu = (
  <ContextMenu>
    <ContextMenuTrigger />
    <ContextMenuContent>
      {menuContent}
    </ContextMenuContent>
  </ContextMenu>
);

[benoitgrelard]

There are definitely ways of doing this, in fact I did exactly this in a demo recently:
https://codesandbox.io/s/radix-performance-demo-qxd8o?file=/src/components/asset-card.js

The gist is this:

const SomeSharedMenu = React.forwardRef(({ type = DropdownMenu, ...props }, forwardedRef) => {
  const MenuType = type;
  return (
    <MenuType.Content {...props} ref={forwardedRef}>
      <MenuType.Item>Item 1</MenuType.Item>
      <MenuType.Item>Item 2</MenuType.Item>
      <MenuType.Separator />
      <MenuType.Item>Item 3</MenuType.Item>
      <MenuType.Item>Item 4</MenuType.Item>
      <MenuType.Item>Item 5</MenuType.Item>
    </MenuType.Content>
  );
});

[jjenzz]

Just to clarify, DropdownMenu and ContextMenu aren't standalone "just in case" we have differences later... they have differences today which existed before the scoping task.

• The DropdownMenuTrigger has a bunch of aria attributes including aria-controls that references the DropdownMenuContent so it requires an id for this relationship, while the ContextMenu does not (different accessibility concerns).
  You will likely miss out on these a11y benefits when using things like MUI that promote re-usable parts across differing patterns.
• The DropdownMenuContent has logic to determine if an outside click is the trigger or not to prevent it from closing in that case. The ContextMenu doesn't need this logic (different functionality concerns).
• The DropdownMenuContent has portalled, side and align props, ContextMenuContent does not (different APIs).
• ... and possibly more I haven't thought of.

Those last two points ensure we are able to keep bundle size small for ContextMenu consumers because they don't need all of the additional DropdownMenu related logic. Instead, we make sure that our primitives re-use utility components under the hood (e.g. our Menu) when there are similarities to keep things streamlined.

Furthermore, the scoping is a very important piece.... if you opened a ContextMenu from a right click on something inside DropdownMenu, it prevents the ContextMenuContent from being treated as a nested/sub DropdownMenuContent because the scoping identifies them as two separate primitives. For example, a demonstration of the problem:

 <Menu>
    <DropdownMenuTrigger />
    <MenuContent>
     <Menu>
        <ContextMenuTrigger />
        <MenuTriggerItem />
        {/* Is this a submenu or a context menu? */}
        <MenuContent>...</MenuContent>
      </Menu>
    </MenuContent>
  </Menu>

Things may look the same but that does not mean they are the same in terms of functionality or keyboard and/or screen reader accessibility.

[buffaybu]

Maybe we can introduce a Submenu.

const menuContent = (
  <>
    <MenuItem>Item 1</MenuItem>
    <MenuItem>Item 2</MenuItem>

    {/* A submenu, no matter it's in a DropdownMenu or a ContextMenu */}
    <Submenu>
      <MenuTriggerItem>More...</MenuTriggerItem>
      <SubmenuContent>
        <MenuItem>Sub Item 1</MenuItem>
        <MenuItem>Sub Item 2</MenuItem>

        {/* an out-of-scope nested menu */}
        <ContextMenu>
          <ContextMenuTrigger>Context Menu</ContextMenuTrigger>
          <ContextMenuContent>
            <MenuItem>Nested Context Menu Item</MenuItem>
          </ContextMenuContent>
        </ContextMenu>

      </SubmenuContent>
    </Submenu>
  </>
);

const dropdownMenu = (
  <DropdownMenu>
    <DropdownMenuTrigger />
    <DropdownMenuContent>
      {menuContent}
    </DropdownMenuContent>
  </DropdownMenu>
);

const contextMenu = (
  <ContextMenu>
    <ContextMenuTrigger />
    <ContextMenuContent>
      {menuContent}
    </ContextMenuContent>
  </ContextMenu>
);

I haven't fully went through the scope code but this seems enough to distinguish between a submenu and a nested menu.

[buffaybu]

And Submenu can reuse the items!

const accountMenuContent = (
  <>
    <MenuItem>Upgrade</MenuItem>
    <MenuItem>Change password</MenuItem>
  </>
);

const accountMenu = (
  <DropdownMenu>
    <DropdownMenuTrigger />
    <DropdownMenuContent>
      {accountMenuContent}
    </DropdownMenuContent>
  </DropdownMenu>
);

const headerMenuContent = (
  <>
    <MenuItem>New post</MenuItem>
    <Submenu>
      <MenuTriggerItem>Account...</MenuTriggerItem>
      <SubmenuContent>
        {accountMenuContent}
      </SubmenuContent>
    </Submenu>
    <MenuItem>Sign out</MenuItem>
  </>
);

const headerMenu = (
  <DropdownMenu>
    <DropdownMenuTrigger />
    <DropdownMenuContent>
      {headerMenuContent}
    </DropdownMenuContent>
  </DropdownMenu>
);

[benoitgrelard]

Unfortunately I don't think we are going to change the way we do the API for all the reasons we mentioned above. Hopefully this answer here is satisfactory: #992 (reply in thread)

[jjenzz]

Agree with @benoitgrelard. It is a bad assumption that we can combine the APIs just because the code "looks the same" or they are "styled the same". They are conceptually different so the components exist for appropriate separation of concerns which helps with all the things mentioned.

If you could help us understand why you need to have the same parts we can maybe help suggest some alternative solutions.

[buffaybu]

@benoitgrelard's demo works great, and indeed sharing menu items between DropdownMenu and ContextMenu is not a very common scenario in support of MenuItem.

why you need to have the same parts

At first it just feels 🤨 to have several pairs of components that have 100% identical code. Maintaining them by manually syncing features, bug fixes and docs looks like an anti-pattern in contrast to DRY. Especially a menu item or a submenu seems to remain the same no matter what kind of menu it's in.

However I see your points about the design like "conceptually different" and understand them but I'm still getting used to them.

Thanks y'all for your patience! Radix Primitives is an amazing library!