Design a Reusable Dropdown Menu Component

MediumFrontend Engineer Onsite System Design

Last updated October 27, 2026

Tests a candidate's ability to architect a production-grade, reusable UI component library element with consideration for flexible API design, accessibility (WAI-ARIA), state management, and large dataset performance.

Scenario

Roblox's Creator Dashboard and Web Marketplace require a unified, highly reusable dropdown component (e.g., or). This component must support diverse use cases across different product surfaces, from a basic sorting picker with 5 static options to an avatar accessory selector with 10,000+ items, remote search filtering, and multi-selection.

Design the architecture, public API, state model, and accessibility semantics for this component.

Requirements

Functional Requirements

Selection Modes: Support single-select and multi-select modes.
Data Sources: Handle both static item arrays and asynchronous data fetching with debounced search filtering and pagination/infinite scroll.
Extensibility: Allow consumers to provide custom trigger elements, custom list item renderers, and custom empty/loading states.
State Control: Support both controlled (value, onChange) and uncontrolled (defaultValue) usage patterns.

Non-Functional Requirements

Accessibility (a11y): Full compliance with W3C WAI-ARIA guidelines for combobox/listbox patterns. Must support complete keyboard navigation (ArrowUp, ArrowDown, Enter, Escape, Home, End, typeahead search) and screen reader announcements.
Performance: Smooth rendering (60 FPS) when opening and scrolling through lists containing up to 10,000 items.
Composability & Size: Modular design with zero unnecessary re-renders; minimal external dependencies.

What to Cover

Component API Design: Propose the public TypeScript interface or compound component structure (e.g., , , , ). Compare compound components vs. a configuration-prop model.
State Management & Mechanics: Detail the internal state machine (open/closed, focused index, selected value(s)). Explain how to handle outside clicks, trigger toggling, and keyboard focus delegation.
Accessibility Architecture: Describe the DOM structure, ARIA roles (combobox, listbox, option), and attributes (aria-expanded, aria-activedescendant, aria-selected).
Performance & Edge Cases: Outline your strategy for virtualized rendering of large lists and positioning/collision detection relative to the viewport.

Hint 1

Consider the trade-offs between a monolithic props-based configuration (e.g., ``) versus a composable compound component pattern (e.g., ``, ``).

Hint 2

For keyboard navigation and accessibility, weigh managing DOM focus on individual `` nodes against keeping focus on the input/trigger using `aria-activedescendant`.

Hint 3

When integrating virtualization for large lists, consider how keyboard navigation and screen-reader announcements are affected when off-screen DOM nodes are unmounted.

Follow-up questions

How would you implement collision detection and viewport boundary flipping (e.g., opening upward when near the bottom of the screen) without introducing layout thrashing?
How does your design manage focus trap and scroll lock when the dropdown is rendered via a React Portal?
If an engineer needs to support grouped options with non-selectable section headers and disabled items, how does that alter your keyboard navigation indexing logic?