DropdownMenu

import { DropdownMenu, DropdownMenuContent, DropdownMenuLabel, DropdownMenuSeparator, DropdownMenuTrigger, DropdownMenuItem } from '@elirobinson/react/components/organisms/DropdownMenu';

import {
  DropdownMenu,
  DropdownMenuContent,
  DropdownMenuItem,
  DropdownMenuLabel,
  DropdownMenuSeparator,
  DropdownMenuTrigger,
} from '@elirobinson/react/components/organisms/DropdownMenu';

export default function Basic() {
  return (
    <DropdownMenu>
      <DropdownMenuTrigger className="ds-button ds-button--secondary">
        Guide actions
      </DropdownMenuTrigger>
      <DropdownMenuContent>
        <DropdownMenuLabel>U8 Soccer Season Plan</DropdownMenuLabel>
        <DropdownMenuItem>Edit</DropdownMenuItem>
        <DropdownMenuItem>Duplicate</DropdownMenuItem>
        <DropdownMenuItem>Archive</DropdownMenuItem>
        <DropdownMenuSeparator />
        <DropdownMenuItem>Delete</DropdownMenuItem>
      </DropdownMenuContent>
    </DropdownMenu>
  );
}

When to use it

Use DropdownMenu for a set of actions anchored to a trigger — row actions in a table, a "…" overflow menu, a view switcher. It's action-oriented: items are role="menuitem" and run a handler, they don't navigate. If every item should actually change the URL, use NavigationMenu or plain links instead — a role="menuitem" on a link tells assistive tech the wrong thing about what activating it does.

Aligning items with inset

inset on DropdownMenuLabel/DropdownMenuItem adds left padding so plain text lines up with sibling items that have a leading marker — a checkmark on the current selection, in this case.

import { useState } from 'react';

import {
  DropdownMenu,
  DropdownMenuContent,
  DropdownMenuItem,
  DropdownMenuLabel,
  DropdownMenuTrigger,
} from '@elirobinson/react/components/organisms/DropdownMenu';

const views = ['List', 'Grid', 'Board'] as const;

export default function Alignment() {
  const [view, setView] = useState<(typeof views)[number]>('List');

  return (
    <DropdownMenu>
      <DropdownMenuTrigger className="ds-button ds-button--secondary">
        View: {view}
      </DropdownMenuTrigger>
      <DropdownMenuContent>
        <DropdownMenuLabel inset>Layout</DropdownMenuLabel>
        {views.map((option) => (
          <DropdownMenuItem key={option} inset={option !== view} onClick={() => setView(option)}>
            {option === view ? `✓ ${option}` : option}
          </DropdownMenuItem>
        ))}
      </DropdownMenuContent>
    </DropdownMenu>
  );
}

Submitting a form from an item

An item that submits a form — a sign-out button running a server action, say — must not close the menu as part of the click that submits it. Closing is a discrete state update React flushes synchronously, still inside the click dispatch: the portal unmounts before the browser reaches the click's default action, React has already suppressed the browser's own submission so that it can run the form's action itself, and no live fiber is left to run it against. The result is an item that looks like it does nothing at all.

So DropdownMenuItem reads its own type: an item with type="submit" does not close on select, and everything else still does.

<DropdownMenuContent>
  <form action={signOutAction}>
    <DropdownMenuItem type="submit">Sign out</DropdownMenuItem>
  </form>
</DropdownMenuContent>

The menu then stays open until the action navigates away, or until you close it yourself once the action resolves. closeOnSelect overrides the default in either direction — closeOnSelect={false} keeps an ordinary item's menu open (a toggle the user may want to flip more than once), and closeOnSelect on a submit item closes it anyway, which is only correct when the submission does not need the form to survive the click.

Props

Accessibility

• DropdownMenuContent renders role="menu", portaled to document.body; each DropdownMenuItem is role="menuitem". The trigger carries aria-haspopup="menu", aria-expanded, and aria-controls.
• Escape closes the menu from anywhere on the page — a document-level listener, active only while the menu is open. Clicking anywhere outside the trigger or the menu content also closes it.
• Opening the menu does not move focus into it — clicking or activating the trigger leaves DOM focus on the trigger button itself. Arrow-key/Home/End navigation only takes over once a menu item already has focus (for example, after tabbing to one).
• Keyboard, once a menu item has focus: ArrowDown/ArrowUp move focus between items and wrap around at both ends (ArrowDown past the last item goes to the first, and vice versa — unlike Combobox/CommandPalette's clamped, non-wrapping model, since this menu moves real DOM focus rather than tracking an aria-activedescendant). Home/End jump to the first/last item. Tab closes the menu and lets focus continue to whatever's next in the page, rather than trapping it.
• DropdownMenuSeparator renders role="separator" with aria-orientation="horizontal".
• Content is positioned with fixed coordinates computed from the trigger's bounding rect, recalculated on scroll and resize while the menu is open, so the menu follows its trigger.
• A menu that doesn't fit below its trigger flips above it, and one that overruns the right edge pins its right edge to the trigger's instead — the bottom/start you get by default are preferences, not guarantees. Each axis flips at most once per open and never flips back, so a menu can't oscillate while you scroll. side and align on DropdownMenuContent set the preferred side.
• A menu that fits on neither side is shifted rather than shrunk: it keeps its width and slides along the axis until it is back inside the viewport, so its items never reflow into whatever space is left beside a pinned edge. It stops being edge-aligned with its trigger, which is the price. The width it keeps has a floor — .ds-dropdown__content sets --anchored-min-width: 180px, and the positioner keeps the larger of that and the trigger's width. A menu taller than the viewport is the one case no offset rescues: it takes a max-height of the viewport and scrolls its own items. See useAnchoredPosition.

Related