Select

A thin styling wrapper over Radix Select: Select / SelectTrigger / SelectContent / SelectItem / SelectValue compose exactly like the primitive, styled to the DS. Every Radix prop passes through unchanged — this page doesn't re-document Radix's own API, only the conventions specific to this styling layer.

Choosing between Select and Combobox

The design system ships two single-select dropdowns on purpose. They look the same — both wear the same 44px field shell — and differ only in interaction:

Why this isn't one component with a searchable prop. A combobox announces itself to a screen reader as an editable field, and opens the keyboard on mobile. For a three-option list both are wrong: there is nothing to type, and a keyboard covering half the screen to pick "Ascending" is a regression. Select stays a button precisely so a short list behaves like one.

If more than one value can be chosen, neither applies — reach for MultiSelect.

Implementation notes

• SelectTrigger needs its own accessible name. Unlike a native <select>, nothing associates a visible <Label> automatically — pass aria-label (or pair it with a <Label htmlFor>) directly on the trigger.
• For picking several values, this isn't the component. Select commits to one Radix Root with one current value; use MultiSelect when more than one option can be chosen at once, rather than working around Select's single-value model.

Do / Don't

• Do control value/onValueChange from the consumer — this composes with whatever state a filter panel or form already holds.
• Don't style SelectContent per-consumer to fake a multi-select or a combobox — reach for the purpose-built component instead of bending this one past what Radix's single-select model supports.
• Don't add a filter input above a Select to make a long list bearable — that is a Combobox, and it already handles the keyboard and screen-reader semantics that pairing does not.