Design a dropdown menu

Requirements: a list of actions behind a button

A dropdown menu (also called an action menu or a menu button) is a button that opens a floating list of commands. You pick one, the list closes, and the command runs. On GitHub, the "..." button on a comment opens Copy link, Quote reply, Edit, and Delete. In Google Docs, the File menu opens New, Open, Make a copy, and Share.

Nothing is "selected" afterwards: the menu does something, it does not hold a value. That separates it from the select in the dropdown-select guide, which picks a value for a form (a country, a size) and shows it in the trigger. A menu runs an action, and its trigger never changes.

The dropdown-select guide covers listboxes, comboboxes, the general popup positioning rules, and form integration, and it introduces the menu button in a few lines. Here we go deep on the menu itself.

Questions to ask first

A design-system component has many callers, so the questions are about who will use it and where. Each answer below changes a decision later in the guide.

• What goes in a menu? Plain actions only, or also check items ("Show line numbers"), radio groups ("Sort by: Name, Date, Size"), submenus, separators, and group labels? Each kind has its own ARIA role and keyboard rule.
• Is it a single menu button or a menu bar? A row of menus like File, Edit, View that you move across with the arrow keys is a different pattern, called a menubar, with more keyboard rules.
• Where does it live? In a toolbar, in a scrolling side panel, in every row of a table, inside a modal? A menu inside a scrolling container or a dialog must still escape clipping and stacking.
• How many items? Five to fifteen is normal. If someone needs 200 items with search, that is a combobox or a command palette, not a menu.
• Which devices? Mouse, keyboard, touch, and screen readers (NVDA, JAWS, VoiceOver) are all in scope for a design system. Touch has no hover, which matters for submenus.
• Which frameworks and browsers? We assume React, the last two versions of Chrome, Edge, Firefox and Safari, and right-to-left languages such as Arabic and Hebrew.

Functional requirements

• A trigger button opens and closes the menu with a click, a tap, Enter, Space, or the arrow keys.
• Items of four kinds: action (menuitem), check item (menuitemcheckbox), radio item in a group (menuitemradio), and submenu trigger. Plus separators and labelled groups.
• Full keyboard support: arrows, Home, End, typeahead by letters, Escape, Tab, and focus back on the trigger after close.
• Submenus open with ArrowRight or hover and close with ArrowLeft or by moving away, with hover intent so a diagonal mouse move does not close them.
• Disabled items that are visible and announced but cannot run.
• The menu stays inside the viewport: it flips above the trigger when there is no room below, shifts sideways, and scrolls when it is taller than the space.
• An optional keyboard shortcut hint on items, like "Ctrl+D" next to Duplicate.
• A context menu variant that opens at the pointer on right-click or long-press.

Non-functional requirements

Out of scope, and why

• Picking a value for a form: that is the select, covered in the dropdown-select guide.
• Searching hundreds of commands: that is the command palette (its own guide), opened with Cmd+K.
• Very long lists: the virtualized-combobox guide covers windowing thousands of options.
• Site navigation links: we will argue in the next chapter that they should not use this component at all.

Menu, select, or navigation: pick the right pattern first

Three widgets look the same when closed: a button with a little arrow. Open, they all show a floating list. But they make different promises to assistive technology, and picking the wrong one is the most common menu bug in real products. So the first decision is not how to build a menu, but whether this thing should be a menu at all.

What role="menu" promises

When a screen reader meets role="menu", it says "menu". On Windows, NVDA and JAWS also switch from browse mode (where letter keys jump between headings and links) to focus mode (where keys go to the page). The user now expects desktop-app behavior: arrow keys move between items, letters jump to items, Enter runs the item, and Escape closes. They do not expect Tab to move through items, and they do not expect links.

The WAI-ARIA Authoring Practices Guide (APG) describes a menu as a widget that offers a list of choices, such as actions or functions, and behaves like the menus of a desktop application. That is the contract you sign by using the role.

A single menu button, or a menubar?

Google Docs has a menubar: File, Edit, View, Insert sit in a row with role="menubar". The whole bar is one tab stop. ArrowLeft and ArrowRight move between the top items, and when a menu is already open, moving sideways opens the next menu straight away, so you can sweep across menus like in a desktop app. A menu button is just one trigger and one menu, like GitHub's "...".

A menubar is a menu button plus a roving focus layer on the bar (the same one-tab-stop, arrows-inside model the tabs guide uses for a tab list) and a shared "is any menu open" flag. Building the single menu right gives you most of the menubar, so our design builds the menu as the core and offers the bar as a thin wrapper. Most product teams only need the button. A menubar makes sense when the page is an application, like a document or code editor, where users expect desktop habits.

The keyboard contract: open, move, type, close

Once we agree it is a menu, the keyboard behavior is not ours to invent. The APG Menu Button and Menu and Menubar patterns define it, and screen reader users have learned it from desktop apps. Our job is to implement it fully and to make the few choices the APG leaves open.

Roles and states on each element

<button id="more-btn" aria-haspopup="menu" aria-expanded="true"
        aria-controls="more-menu">More actions</button>

<div id="more-menu" role="menu" aria-labelledby="more-btn">
  <div role="menuitem" tabindex="-1">Edit</div>
  <div role="menuitem" tabindex="-1" aria-keyshortcuts="Control+D">Duplicate</div>
  <div role="menuitem" tabindex="-1" aria-haspopup="menu"
       aria-expanded="false">Move to</div>
  <div role="separator"></div>
  <div role="group" aria-label="View">
    <div role="menuitemcheckbox" tabindex="-1" aria-checked="true">Show labels</div>
  </div>
  <div role="separator"></div>
  <div role="menuitem" tabindex="-1" aria-disabled="true">Delete</div>
</div>

• The trigger is a real button with aria-haspopup="menu" (or true, which means the same for menus) and aria-expanded that flips between false and true. aria-controls pointing at the menu is optional in the APG.
• The menu has role="menu" and a name, usually aria-labelledby pointing at the trigger, so a screen reader says "More actions, menu".
• Items are menuitem, menuitemcheckbox, or menuitemradio. Check and radio items carry aria-checked. Radio items sit in a role="group" with a label, so "Sort by" is announced once for the group.
• A submenu trigger is a menuitem with its own aria-haspopup and aria-expanded.
• Separators get role="separator" and are never focusable.

Every key, and what it does

Moving focus: roving tabindex or aria-activedescendant

The APG shows both techniques in two versions of its Actions menu button example. The keyboard-navigation and focus-management lessons explain them in general; here is what each means for a menu.

Typeahead: a buffer and a timer

The APG lists typeahead as optional: a printable key moves focus to the next item whose label starts with that character. We treat it as required, because long-time desktop users expect it. Libraries also keep a short buffer, so typing "du" quickly jumps to "Duplicate" even when "Delete" comes first. Radix UI clears its buffer 1,000 ms after the last key.

Two details make it feel right. Pressing the same letter again cycles through the items that start with it. And libraries that make disabled items unfocusable, such as Radix, also skip them in the search; our design keeps them focusable, so they stay in it.

let buffer = "";
let timer: number | undefined;

export function typeahead(key: string, labels: string[], current: number): number {
  buffer += key.toLowerCase();
  window.clearTimeout(timer);
  timer = window.setTimeout(() => (buffer = ""), 1000);

  const repeated = [...buffer].every((c) => c === buffer[0]);
  const search = repeated ? buffer[0] : buffer;
  // A single letter starts after the current item, so pressing "d" twice cycles.
  const start = search.length === 1 ? current + 1 : current;
  for (let i = 0; i < labels.length; i++) {
    const index = (start + i) % labels.length;
    if (labels[index].toLowerCase().startsWith(search)) return index;
  }
  return current;
}

Disabled items: focusable or skipped?

The APG note is short: disabled menu items are focusable but cannot be activated, and they carry aria-disabled="true". The reason is discovery: if Delete is skipped, a screen reader user never learns it exists, or why it is missing. Some libraries choose the opposite, and Radix UI leaves disabled items out of arrow-key and typeahead movement.

Our design follows the APG by default. It uses aria-disabled, never the disabled attribute (which removes the element from focus), and blocks activation in the item handler. A tooltip-like hint ("Only owners can delete") can live in aria-describedby, so the reason is heard too.

Escape, Tab, and where focus goes after close

Escape and running an item return focus to the trigger. Without that, focus falls to body when the menu unmounts, and a keyboard user starts again from the top of the page. Tab is different: the APG says Tab closes all menus and moves focus out. A menu is not a modal, so we do not trap focus (the modal-dialog guide covers traps).

Letting the browser handle Tab only works when the menu sits right after its trigger in the DOM, as it does with the Popover API. If the menu is portaled to the end of body, Tab would jump to the end of the page, so the Tab handler first moves focus to the trigger and then lets the browser's default move on from there.

One subtle case is an item that opens a dialog, like "Rename...". The menu closes and the dialog opens and takes focus. When the dialog closes, it must return focus to the menu's trigger, because the item it came from no longer exists.

Submenus and hover intent

A submenu is a menu inside a menu: "Move to" opens a list of folders to its side. For the keyboard, the rules from the last chapter are enough: ArrowRight (or Enter, or Space) opens it and focuses its first item, ArrowLeft or Escape closes it and puts focus back on "Move to". The hard part is the mouse.

The naive version, and the diagonal problem

The naive rule is: open a submenu on pointerenter of its parent item, and close it the moment the pointer enters any other item. Picture the menu: Edit, Duplicate, Move to, Archive, Delete, each 32 px tall. You hover "Move to" and its submenu appears to the right, with "Projects" 80 px lower.

You move the mouse in a straight line toward "Projects", and that diagonal line crosses "Archive" on the way. The naive rule activates Archive, closes the submenu, and leaves you pointing at empty space. People learn to move in an L shape, right first and then down, which is a sign the menu is fighting them.

How the triangle test works

At the moment the pointer leaves "Move to", we record its position P. The submenu is a rectangle, and we take its two corners nearest to the menu, A (top) and B (bottom). Then, on every pointermove, we test whether the new point lies inside triangle P, A, B.

A point is inside a triangle when it lies on the same side of all three edges, which takes three cross products. That costs microseconds, far below the 16 ms frame budget.

type Point = { x: number; y: number };

const side = (p: Point, a: Point, b: Point) =>
  (b.x - a.x) * (p.y - a.y) - (b.y - a.y) * (p.x - a.x);

export function inTriangle(p: Point, a: Point, b: Point, c: Point): boolean {
  const d1 = side(p, a, b);
  const d2 = side(p, b, c);
  const d3 = side(p, c, a);
  const hasNeg = d1 < 0 || d2 < 0 || d3 < 0;
  const hasPos = d1 > 0 || d2 > 0 || d3 > 0;
  return !(hasNeg && hasPos);
}

// On pointermove over a sibling item:
// if (inTriangle(now, exitPoint, subTopNear, subBottomNear) && !graceExpired) skip;
// else activate the sibling and close the submenu.

• Add a grace timeout (about 300 ms). If the pointer rests inside the triangle, the user has stopped aiming; let siblings take over.
• Or rebuild the triangle as the pointer moves. jQuery-menu-aim measures from recent pointer positions, so the triangle shrinks as the pointer gets closer. Radix keeps the exit point and relies on its 300 ms timeout instead; either works if the timeout is there.
• Pad it by a pixel or two. Floating UI's safePolygon has a buffer option (half a pixel by default) for exactly this, so the edges do not flicker on rounding.
• Mirror it in right-to-left: the submenu is on the left, so the near corners are its right edge.

Touch and pen have no hover

On a phone, there is no pointerenter before a tap, so hover intent does not apply. We check event.pointerType and, for touch and pen, open submenus on tap only. On small screens (say under 480 px wide), side-by-side submenus often do not fit at all; a common answer is to replace the content of the menu with the submenu's items plus a Back item at the top, the way iOS and Android action sheets drill down. That is a presentation change only; roles and keys stay the same.

Positioning: anchored, on screen, above everything

The dropdown-select guide covers the base problem (clipping, stacking, the top layer, and the flip, shift and size rules, with a lab), and the tooltip guide adds anchoring. This chapter covers only what is different for a menu: several layers open at once, submenus that sit to the side, and a pointer aiming at items, so a menu that moves is a real bug.

Escaping clipping, with submenus in mind

A menu in a table cell inside a card with overflow: hidden gets cut off, and a menu under a sticky toolbar with a higher z-index opens behind it. Both come from clipping ancestors and stacking contexts (groups of elements the browser paints as one layer). What is new for a menu is that several layers can be open at once: the menu, a submenu, and maybe a submenu of that.

Placing a submenu: CSS anchor positioning or a library

CSS anchor positioning ties an element to an anchor element in CSS, with no JavaScript and no scroll listeners. It arrived in Chrome and Edge 125 in 2024, Safari 26 in 2025, and Firefox 147 in January 2026, so the last two versions of every major browser now have it. But the newer implementations are young, and real-user analytics usually show a tail of older browsers. A library such as Floating UI computes the same placement in JavaScript with middleware (offset, flip, shift, size) and works everywhere, so it stays as the fallback.

The top-level menu uses the same CSS as a select's popup. The submenu is the menu-specific part: it anchors to its parent item, opens toward the inline end (the right in English), and flips to the other side when there is no room.

.menu-item[aria-haspopup] { anchor-name: --move-to; }

@supports (position-anchor: --a) {
  .submenu[popover] {
    position-anchor: --move-to;
    /* beside the item, top edges aligned, growing down */
    position-area: inline-end span-block-end;
    position-try-fallbacks: flip-inline, flip-block;
    max-block-size: calc(100dvh - 16px);
    overflow-y: auto;
  }
}

Each trigger and parent item needs a unique anchor name, so the component generates one per instance from React's useId() instead of the fixed name in this sample. When anchor positioning is in every browser our users have (check real-user analytics, not just release notes), we can delete the JavaScript path.

What is different for a menu

• Height. A 12-item menu is about 400 px tall, so the size rule from the dropdown-select guide applies on almost every open: take the side with more room, cap the height, and let the menu scroll.
• Submenus go to the side. The placement is right-start (its top aligned with the parent item), flipping to left-start when there is no room. Right-to-left pages start on the left; logical names (inline-end) make that automatic, as the rtl-layouts lesson explains.
• Never shift a submenu over its parent. Covering "Move to" hides where the user came from and breaks the safe triangle. Flip to the other side first, and shift only up or down.
• Do not move while the pointer is aiming. Recomputing placement on scroll is right; recomputing because the menu's own content changed size (a check mark appears) can make it jump under the pointer. We choose the side when a menu opens and keep it until it closes.
• Scroll and resize while open. Floating UI's autoUpdate listens to scroll on every scrolling ancestor, resize, and a ResizeObserver on both elements. That cost is why we attach it only to an open menu, never to 500 closed ones. When the trigger scrolls out of view, close the menu (or hide it with the hide middleware).

Pointer details: press, drag, release, right-click

A mouse click is three events: pointerdown, pointerup, and then click. Which one opens the menu, which one runs an item, and which one closes the menu from outside are small choices that decide whether the menu feels native or clumsy.

Press-drag-release, and the early release trap

With open-on-press, the user's button is still down when the menu appears. They can drag onto "Duplicate" and release: pointerup fires on the item, and we run it. Each item listens for pointerup and runs itself if the press did not start on that item.

But there is a trap. If the menu opens with an item right under the pointer (a context menu opened at the pointer, or a menu that flipped up over the trigger), a quick click's pointerup lands on that item a few milliseconds after the press. The menu opens and runs Delete in one click.

• Ignore a pointerup on an item that comes within a short time of opening (a few hundred ms is a common choice; treat the exact number as a tuning value) and close to where the press started.
• Never place the menu over the trigger. Offset it by a few pixels with the offset middleware so the release lands on the trigger, not an item.
• For context menus, open at the pointer plus 2 px, so the pointer is on the menu's corner, not on an item.

Closing on an outside press

A menu closes when you press anywhere else. With nested auto popovers, the browser's light dismiss does this, and we only sync state from the toggle event. The portal fallback listens for pointerdown on the document in the capture phase, so it sees the press before any page handler can stop it, and closes if the target is outside every open level and the trigger.

A press on another menu's trigger should close ours and open theirs in the same gesture, not need two clicks. A press on our own trigger is the one outside-looking press we must ignore, as the next section explains.

Should the outside press also reach the thing under it? macOS menus swallow it: clicking outside only closes the menu. Many web menus let it through, so one click closes the menu and presses the button below, while Radix's default modal mode blocks it. Our default is to let it through for a non-modal menu, because a swallowed click on the web feels like a lost click.

Preventing flashes

• Toggle on the trigger, not close-then-open. A press on the open trigger must close it once. If outside-dismiss closes it on pointerdown and the trigger's click then opens it again, the menu flashes and stays open.
• Do not open on hover for top-level menus. Hover-opening a menu button makes menus pop open as the mouse crosses a toolbar. The exception is a menubar: once one menu is open, hovering a sibling top item switches to its menu, like desktop apps.
• Mount, measure, then show. Paint the menu only after its position is computed, or it appears at the top-left for one frame. With Floating UI, keep the menu hidden until the first computePosition resolves; with CSS anchor positioning, the browser handles it.
• Short animations, and none with reduced motion. A 100 to 150 ms fade or scale is enough. Under prefers-reduced-motion: reduce, show it instantly.

The context menu variant

A context menu is the same menu opened differently: right-click on a file in Google Drive shows Open, Rename, Share, Remove. The browser fires the contextmenu event on right-click and on the keyboard's context menu key (and Shift+F10 on Windows). We call preventDefault() to suppress the browser's own menu and open ours at clientX and clientY.

Positioning uses a virtual anchor: a zero-size rectangle at the pointer, with flip and shift as usual. A context menu opened from the keyboard has no pointer position, so we anchor it to the focused element instead.

• Touch has no right-click. Long-press of about 500 ms opens it (a common choice, not a standard), canceled if the finger moves more than about 10 px, which means a scroll. iOS Safari may show its own callout on long-press; -webkit-touch-callout: none on the target suppresses it.
• Always offer another way. Right-click is invisible. Every action in a context menu must also exist in a visible "..." menu or toolbar, for touch users, for keyboard users who do not know Shift+F10, and for discoverability.
• Do not hijack right-click everywhere. Override only on the objects that have actions, so people can still copy text or open links in a new tab elsewhere.

Architecture and testing: a small store and a few behaviors

Everything so far is behavior: keys, focus, hover intent, positioning, dismissal. The naive build puts all of it in one 600-line Menu component with a dozen useEffect calls. It works until someone needs a submenu, a menubar, or a context menu, and then every behavior is copied. The design that scales splits the menu into a small store that owns state, and behaviors that read and write it, with thin components on top.

The item registry: how the menu knows its items

Arrow keys and typeahead need the items in order, with their labels and disabled flags. Children can be anything: items wrapped in groups, conditional items, items from a map. So each Menu.Item registers itself with the store on mount (its element, its text, disabled) and unregisters on unmount.

The order comes from the DOM, not from registration order. Before moving, we sort registered elements with compareDocumentPosition, or we query [role^=menuitem] inside the content. That stays correct when an item is inserted conditionally in the middle.

How data flows on open and select

Input arrives as a DOM event on the trigger or an item. A behavior turns it into a store change: open = true, activeIndex = 0. The store notifies subscribers, React re-renders the content, and an effect moves real focus to the active item.

When an item is selected, the store emits a select event to the caller's onSelect, which runs the app's command, usually a network call like POST /files/42/duplicate. The menu does not wait for it: it closes and returns focus right away, and the app reports success or failure with a toast. Menus that wait for a server are rare and need a loading item state, which we leave to the caller.

Testing: what screen readers say, and what machines can check

A menu passes a visual review long before it works. The bugs that matter are in what is announced and where focus goes, and they hide from people who test with a mouse. The accessibility-testing and screen-readers lessons cover the tools; this section is the test plan for this component.

What a screen reader user should hear

The manual matrix covers the pairs most used in practice: NVDA with Chrome or Firefox and JAWS with Chrome on Windows, VoiceOver with Safari on macOS and iOS, and TalkBack with Chrome on Android. Two things only humans catch: whether NVDA and JAWS switch to focus mode when the menu opens (if not, arrow keys read the page instead of moving in the menu), and whether VoiceOver on iOS can reach and activate items with swipes, since there are no arrow keys.

Automated tests, by layer

• Unit tests for the pure parts: typeahead matching (repeated letters cycle, the buffer clears after 1,000 ms with fake timers), the triangle test, and the next-index function with disabled items and wrapping.
• Component tests with Testing Library: query by role, never by class: getByRole("button", { name: "More actions" }), press {ArrowUp}, expect getByRole("menuitem", { name: "Delete" }) to have focus and aria-disabled. Assert focus returns to the trigger after Escape and after select. jsdom has no layout, so do not test positions here.
• axe-core in those tests: it catches a menu without items, an item outside a menu, a missing name on an icon-only trigger, and invalid aria-checked on a plain menuitem.
• Browser tests with Playwright: real layout and real pointer events. Place the trigger 20 px from each window edge and assert the menu stays inside the viewport. Drag from trigger to an item and release. Move the mouse diagonally to a submenu and assert it stays open. Run in Chromium, Firefox and WebKit.
• Visual regression: screenshots of the open menu in light, dark, right-to-left and forced-colors mode (Windows High Contrast), where focus must be visible without our background colors.

test("ArrowUp opens on the last item and Escape returns focus", async () => {
  const user = userEvent.setup();
  const onDelete = vi.fn();
  render(<RowMenu canDelete={false} onDelete={onDelete} />);
  const trigger = screen.getByRole("button", { name: "More actions" });

  trigger.focus();
  await user.keyboard("{ArrowUp}");
  const del = screen.getByRole("menuitem", { name: "Delete" });
  expect(del).toHaveFocus();
  expect(del).toHaveAttribute("aria-disabled", "true");
  expect(trigger).toHaveAttribute("aria-expanded", "true");

  await user.keyboard("{Enter}");
  expect(onDelete).not.toHaveBeenCalled();

  await user.keyboard("{Escape}");
  expect(screen.queryByRole("menu")).toBeNull();
  expect(trigger).toHaveFocus();
});

The component API, its data model, and 500 rows

The API is the part every product team touches, so it carries most of the design system's long-term cost. The component-api-design lesson covers the general trade-offs; here are the menu-specific ones.

<Menu.Root>
  <Menu.Trigger aria-label="More actions"><DotsIcon /></Menu.Trigger>
  <Menu.Content>
    <Menu.Item onSelect={edit}>Edit</Menu.Item>
    <Menu.Item onSelect={duplicate} shortcut="Control+D">Duplicate</Menu.Item>
    <Menu.Sub label="Move to">
      {folders.map((f) => (
        <Menu.Item key={f.id} onSelect={() => move(f.id)}>{f.name}</Menu.Item>
      ))}
    </Menu.Sub>
    <Menu.Separator />
    <Menu.CheckboxItem checked={labels} onCheckedChange={setLabels}
      onSelect={(e) => e.preventDefault()}>Show labels</Menu.CheckboxItem>
    <Menu.Separator />
    <Menu.Item onSelect={remove} disabled={!canDelete}
      description="Only owners can delete">Delete</Menu.Item>
  </Menu.Content>
</Menu.Root>

Controlled or uncontrolled open state

Most callers never think about open state, so the menu is uncontrolled by default: it keeps open inside. Some need control, such as a product tour that opens the menu to point at an item, or a test. So Menu.Root also takes open and onOpenChange(open, reason), the same pattern React uses for value and onChange on inputs.

The reason ("trigger", "escape", "outside", "select", "tab") matters. A caller who wants to keep the menu open after a select, but still close on Escape, can tell the two apart.

onSelect as a cancelable event

After an item runs, the menu closes. Check items are the common exception: flipping "Show labels" and "Show grid" one after the other should not need two openings. Instead of a closeOnSelect prop on every item, onSelect receives an event, and calling event.preventDefault() keeps the menu open. Radix does this by dispatching a cancelable custom event on the item, so a wrapper can decide per call while the default stays the common case.

Keyboard shortcut hints

Showing "Ctrl+D" next to Duplicate teaches the shortcut. The shortcut prop renders the hint, localized per platform ("Cmd+D" on macOS), and sets aria-keyshortcuts with the ARIA spec's key names (Control+D, or Meta+D on macOS). The attribute only announces the shortcut; it does not make it work, so the app registers the real key handler at page level, where it works while the menu is closed.

Screen reader support for aria-keyshortcuts varies. Pick one channel so the shortcut is not read twice: either hide the visible hint with aria-hidden and rely on the attribute, or leave the hint readable and skip the attribute. We choose the attribute and test it in the screen reader matrix.

The data model

type ItemKind = "action" | "checkbox" | "radio" | "submenu";

type RegisteredItem = {
  id: string;            // from useId(), used for aria-controls and tests
  kind: ItemKind;
  element: HTMLElement;  // for focus() and DOM order
  textValue: string;     // typeahead label, defaults to textContent
  disabled: boolean;
};

type MenuState = {
  open: boolean;
  activeId: string | null;
  items: Map<string, RegisteredItem>;
  typeahead: { buffer: string; clearAt: number };
  parent: MenuStore | null;     // set for submenus
  openSubId: string | null;     // at most one open child
  placement: "bottom-start" | "top-start" | "right-start" | "left-start";
};

Note what is not in the store: the checked values. checked belongs to the caller (it is app state, like "show labels"), so check and radio items are controlled by the caller. The menu reflects it in aria-checked and reports changes. That keeps one source of truth when the same setting also appears in a toolbar.

Performance at scale

One menu is cheap. The cost appears when a data table renders a "..." menu on each of 500 rows. The data-table guide covers the table; this section is about what each row's menu costs.

What the naive version costs

Suppose each row renders a full menu, hidden with CSS, with 10 items, each an icon, a label and a shortcut hint. That is about 4 DOM nodes per item, so roughly 45 nodes per menu with the wrapper and separators, and about 22,500 extra nodes across 500 rows. Add 500 sets of event listeners and, if positioning runs while hidden, 500 scroll listeners.

Lighthouse's DOM size audit has long warned at about 800 nodes on the whole page and failed at about 1,400, so the hidden menus alone would be many times over. Style recalculation, layout and memory all grow with node count. These are estimates for this example, but the order of magnitude is the point.

• Code-split the heavy parts. The trigger is tiny; positioning and the hover-intent code load with the content on first open. A pointerenter or focus on any trigger can start that import early, so the first open still lands in one frame.
• Keep the open path synchronous. No await between the press and the first paint of the menu. If items depend on permissions, fetch them with the page, not on open.
• Measure with the Performance panel. Press to first paint counts toward Interaction to Next Paint (INP), where good is 200 ms or less; a menu should take about one frame.

Running it in the interview

In 45 minutes you cannot say everything in this guide, and you should not try. The interviewer is checking that you see past "a div that toggles" to the parts that make a menu correct for everyone, and that you can make trade-offs out loud.

Say your trade-offs out loud: "roving tabindex, because there is no text field to keep focus", "disabled items stay focusable, as the APG says, though Radix skips them". A named trade-off with a reason scores higher than a perfect answer given silently.