Headless UI
02 / 02

Combobox, Transition & Choosing a Headless Library

Combobox, Transition & Choosing a Headless Library

Combobox — Filterable Select

Combines a text input (filtering) with a dropdown of matching options — coordinating typed input, filtered results, and keyboard navigation together, genuinely more complex than a plain Listbox.

Transition — Coordinated Enter/Leave

<Transition
  show={open}
  enter="transition ease-out duration-100"
  enterFrom="opacity-0 scale-95"
  enterTo="opacity-100 scale-100"
  leave="transition ease-in duration-75"
  leaveFrom="opacity-100 scale-100"
  leaveTo="opacity-0 scale-95"
>
  <Menu.Items>...</Menu.Items>
</Transition>
// keeps the element mounted until its leave transition finishes,
// instead of yanking it out of the DOM the instant `show` flips false

RadioGroup, Switch & Tabs

RadioGroup renders selectable "cards" with correct radio-group semantics/arrow-key nav, unlike restyling-resistant native radios. Switch reimplements a checkbox as a toggle. Tabs applies the ARIA Tabs pattern (tablist/tab/tabpanel roles, aria-selected, arrow-key navigation between tabs) correctly by default.

The WAI-ARIA APG

Each component follows the WAI-ARIA Authoring Practices Guide's documented keyboard/focus/role expectations for that pattern — the same reference other accessible libraries (Radix UI, React Aria) target.

When to Reach for a Headless Library

Great for well-established patterns (menus, dialogs, comboboxes) where accessibility correctness is genuinely hard to get right from scratch. A truly novel, bespoke interaction that doesn't map onto any standard pattern may be more practical to build custom than to force into a general-purpose headless API.

Keep your own version of these notes — editable, searchable, and organised by your stack.

Start free