Combobox

One collapsed list used to be enough for anything a user had to choose. Three pricing plans, four notification intervals — click, glance, pick, two seconds.

Then the option counts grew and the pattern stopped holding. A country field on a signup form carries close to two hundred entries. Open the list and half the screen fills with alphabetized names while the user scrolls looking for their own. Typing a first letter to jump was possible, but almost nobody knew it, and with ten countries starting on the same letter it still meant several more presses.

Meanwhile users had gotten used to search. Looking for something meant typing a few characters, not hunting through a list. Once you know that three letters narrow two hundred rows to two, there's no reason to go back to scrolling.

A combobox merges those two behaviors into one part. A text field and a list of options sit together, and what's typed into the field narrows the list. The "combo" in the name is that merger.

The typed characters filter the candidate list, and the value is set when the user picks one of the survivors. On screen it happens in five steps.

1. At rest it looks like a plain text input — one field. It has to look like it accepts a cursor, or the user never thinks to type into it.
2. Focusing the field opens the list. Whether an empty field shows everything or only recent and suggested entries is a design decision. With several thousand candidates, opening the whole set gets in the way rather than helping.
3. Every keystroke narrows the list, and the matching rule has to be chosen deliberately. Matching only from the start of a name means someone typing "republic" finds nothing under Czech Republic, while matching anywhere in the string leaves more candidates standing. Accents add another decision — whether "sao" should find São Paulo.
4. Arrow keys move through the candidates and Enter confirms; clicking does the same. Skip this step and the user's hand has to leave the keyboard for the mouse, which gives back exactly the speed the typing bought.
5. The confirmed value stays in the field and the list closes.

Two more decisions sit on top. The first is whether values outside the list are allowed. For a fixed set like countries, block them; for something like tags, where new values are legitimate, put a "create new" row at the bottom. The second is what happens when nothing matches. An empty dropdown reads as a broken component, so it needs a "no results" line and a sentence about what to do next.

Accessibility takes real work in this part. The field and the list are separate elements, so keyboard navigation doesn't come for free, and the number of remaining candidates and the one currently highlighted have to be announced through ARIA attributes for anyone listening to the screen to get the same information.

Anywhere the set of choices is large. The dividing line is the count. Two or three options are faster laid out as radio buttons; up to six or seven a collapsed list is fine; past a few dozen the work moves to this part.

The most familiar case is a long fixed list — countries, currencies, time zones. The list never changes, so it ships with the page and the filtering happens in the browser.

Often the candidates come from the server instead, as when assigning an owner or mentioning a colleague inside a document. Here the request shouldn't fire on every keystroke; wait for roughly 300 milliseconds of quiet and send one. Three requests going out while someone types a name can come back out of order, leaving the list showing matches for a prefix the user already moved past.

Values with a fixed format, like dates and numbers, don't belong here. Listing candidates isn't the right shape for them, which is why a calendar-based date picker handles dates separately. In the other direction this part gets confused with search UX, because the two look alike. A search field takes the typed string itself and carries it to a results page; a combobox produces no value until something in the list is confirmed.

"Sixty options — let's make that a combobox rather than a select."

The count crossed the threshold, so the part should change.

"The combobox only matches from the start of the word."

Typing a middle word finds nothing, which is a bug report about the filter rule rather than about the component.

"Is this free entry, or does it have to come from the list?"

Asking whether values outside the list are accepted. How the value gets stored on the back end follows from the answer.

At Pagedeck this part is the field for choosing who a document gets shared with. It started as a collapsed list, and once headcount hit 45 people started saying that finding a name took too long on its own. Noa put up a combobox instead, and Theo added the debounce when wiring it up.

The thing that actually snagged came after it shipped. Sharing had to work with outside email addresses, and the list only held employees. Mia settled it by allowing values outside the list, with a rule that anything shaped like an email address gets an "invite this address" row at the bottom. A swap made over option counts turned into a decision about what the field is allowed to hold.

People treat it as a strictly better select. Search is attached, so using it anywhere seems free. But put it on a field with four options and the user first has to decide whether to type or to pick, and that decision takes longer than scanning four rows would. The filter rule earns nothing on a shallow list either. Left uncorrected, this reading covers the whole interface in one part, with a cursor blinking on questions that have two possible answers.

The other is reading it as a search field. Typing to narrow results looks identical in both. The difference is what comes out. A search field carries the raw string the user typed into a results view, while a combobox has no value until an item is confirmed. Blur the two and users type a few characters, press Enter, and submit a form with an empty field.