Autocomplete
Autocomplete is a search field that proposes matches while you type, from a set the reader does not have to know in advance. It differs from a picker in what it promises: the list is a shortcut to an answer, not the definition of the legal answers, and it often comes from a server rather than from memory. Both blocks here search as you type, ink the matched run inside each hit, and take the arrow keys as well as the pointer.
The highlight is not decoration. Inking exactly the characters in the field and nothing more turns the list into a spell-check: the reader sees their own typing reflected in every result and catches a transposed letter before wondering why nothing matches. The other half of the work is invisible. Debouncing is not enough on its own, because a slow early request can land after a fast later one and repaint the list with results for a prefix the reader has already moved past.
Account search
Best for
Search boxes with suggestions: the run you typed is inked in each hit so the eye lands on it
Anatomy
60px search field with clear · floating list of 50px rows · the typed run inked brand, the rest muted · thin scroll
Location picker
Best for
A setting shown as a pill that opens into a search: location, timezone, language
Anatomy
Location pill, brand-ringed while open · panel with close · Field Header Label · pill search field · 58px pill results with pin, match and region
Using Autocomplete
Reach for it when
- A search box where the reader half-knows the thing they are looking for
- Address or place entry, where the canonical spelling comes from a service
- A setting whose value is one of thousands: timezone, language, currency
- An at-mention inside a composer, offered as the name is typed
Reach for something else when
- The set of answers is fixed and modest, like a status or a plan tier: a dropdown states the options instead of waiting for someone to guess a prefix
- The reader is adding entries rather than finding one; a tag input holds a set, while autocomplete returns a single answer
- Results take seconds to arrive: a list that lands after the reader has finished typing is worse than none, so use a search button and a results page
Where it shows up
Account lookup
A support tool where the operator half-remembers a customer name. Results appear under the field with the typed run inked in each, the arrow keys walk them, and a clear button resets the search without reaching for the mouse.
Location settings
A setting shown as a pill until someone changes it. The pill opens a panel with its own search field and results that pair the matched place with its region, which is what separates two towns of the same name.
Mentions in composers
Typing an at-sign opens a list of people in the thread. The suggestion list has to appear without stealing the caret, commit on Enter, and get out of the way when the next character makes nothing match.
Address entry
Checkout forms that suggest a formatted address from the first line. The reader types a street, picks the match, and the remaining fields fill from a source that spells the town the way the post office does.
Questions
How should autocomplete handle no results?
Say so in the list, in the place where results would have appeared, rather than closing the panel. A list that vanishes mid-typing reads as a bug, and the reader starts deleting characters to work out what broke. If they can still act on what they typed (add it, search everything, report it missing) offer that as a row.
Does autocomplete need debouncing?
It needs debouncing and it needs stale responses discarded. Debouncing stops a request per keystroke. It does not stop an early slow request landing after a later fast one and repainting the list with matches for a prefix the reader has moved past. Tag every response with the query it answers and drop anything that is not the current one.
Premium components,
free in your inbox.
Join the Orvain Dispatch and get production-ready components, free to keep: React and Vue code plus the Figma frame, yours to ship.
Orvain MCPAutocomplete
Autocomplete is a search field that proposes matches while you type, from a set the reader does not have to know in advance. It differs from a picker in what it promises: the list is a shortcut to an answer, not the definition of the legal answers, and it often comes from a server rather than from memory. Both blocks here search as you type, ink the matched run inside each hit, and take the arrow keys as well as the pointer.
The highlight is not decoration. Inking exactly the characters in the field and nothing more turns the list into a spell-check: the reader sees their own typing reflected in every result and catches a transposed letter before wondering why nothing matches. The other half of the work is invisible. Debouncing is not enough on its own, because a slow early request can land after a fast later one and repaint the list with results for a prefix the reader has already moved past.
Account search
Best for
Search boxes with suggestions: the run you typed is inked in each hit so the eye lands on it
Anatomy
60px search field with clear · floating list of 50px rows · the typed run inked brand, the rest muted · thin scroll
Location picker
Best for
A setting shown as a pill that opens into a search: location, timezone, language
Anatomy
Location pill, brand-ringed while open · panel with close · Field Header Label · pill search field · 58px pill results with pin, match and region
Using Autocomplete
Reach for it when
- A search box where the reader half-knows the thing they are looking for
- Address or place entry, where the canonical spelling comes from a service
- A setting whose value is one of thousands: timezone, language, currency
- An at-mention inside a composer, offered as the name is typed
Reach for something else when
- The set of answers is fixed and modest, like a status or a plan tier: a dropdown states the options instead of waiting for someone to guess a prefix
- The reader is adding entries rather than finding one; a tag input holds a set, while autocomplete returns a single answer
- Results take seconds to arrive: a list that lands after the reader has finished typing is worse than none, so use a search button and a results page
Where it shows up
Account lookup
A support tool where the operator half-remembers a customer name. Results appear under the field with the typed run inked in each, the arrow keys walk them, and a clear button resets the search without reaching for the mouse.
Location settings
A setting shown as a pill until someone changes it. The pill opens a panel with its own search field and results that pair the matched place with its region, which is what separates two towns of the same name.
Mentions in composers
Typing an at-sign opens a list of people in the thread. The suggestion list has to appear without stealing the caret, commit on Enter, and get out of the way when the next character makes nothing match.
Address entry
Checkout forms that suggest a formatted address from the first line. The reader types a street, picks the match, and the remaining fields fill from a source that spells the town the way the post office does.
Questions
How should autocomplete handle no results?
Say so in the list, in the place where results would have appeared, rather than closing the panel. A list that vanishes mid-typing reads as a bug, and the reader starts deleting characters to work out what broke. If they can still act on what they typed (add it, search everything, report it missing) offer that as a row.
Does autocomplete need debouncing?
It needs debouncing and it needs stale responses discarded. Debouncing stops a request per keystroke. It does not stop an early slow request landing after a later fast one and repainting the list with matches for a prefix the reader has moved past. Tag every response with the query it answers and drop anything that is not the current one.
Related blocks
All blocksPremium components, free in your inbox.
Join the Orvain Dispatch and get production-ready components, free to keep: React and Vue code plus the Figma frame, yours to ship.
