Search UX & Autocomplete

The plain-language idea

A search box looks like the simplest possible UI element, but four separate decisions determine whether it feels genuinely helpful or just technically functional.

How long to wait before firing a request is a perceptual decision, not just a performance one. The JavaScript track's debounce lesson covers the mechanism (delay a function call until input goes quiet); this is about the feel of the delay itself. Too short (50ms) fires a request on nearly every keystroke, producing flickering results and unnecessary network noise. Too long (600–800ms) feels laggy, like the box isn't responding to what was just typed. Something in the 250–300ms range is a common sweet spot: long enough that a fast typer finishes a word before anything fires, short enough that results still feel connected to the keystroke that triggered them.

What fills the box before anyone types anything is real, valuable real estate, not a blank space to ignore. Showing the user's own recent searches, or aggregate popular ones, gives a useful default state instead of an empty input and a blinking cursor — and often lets a returning user re-run a past search in one tap instead of retyping it.

See it in a real thing: a debounced query with a considered empty state

const debouncedQuery = useDebouncedValue(query, 280); // fast enough to feel live, slow enough not to fire per keystroke

useEffect(() => {
  if (!debouncedQuery) return;
  fetchResults(debouncedQuery);
}, [debouncedQuery]);

Once results come back, highlighting the matched substring inside each result (bolding the "data" inside "database") lets a user visually confirm why each result matched instead of reading every result in full to figure out relevance — a small change that measurably speeds up scanning a results list.

// safe: escape the query before building the highlight regex, never inject raw
// user input into innerHTML directly
function highlightMatch(text: string, query: string) {
  const escaped = query.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
  return text.replace(new RegExp(`(${escaped})`, "gi"), "<mark>$1</mark>");
}

And when nothing matches at all, a genuinely helpful zero-results state does more than report failure. "No results found" is a dead end. Suggesting a likely correction ("Did you mean 'database'?"), broadening to a related category, or offering another path forward turns a failed search into a recoverable moment instead of a wall.

What people usually miss

Watch out

• The debounce delay is a UX call worth testing by feel, not a number to guess once and leave alone. What reads as "responsive" versus "laggy" varies with the kind of search and the speed of the backend behind it.
• A fully client-side search over an already-loaded, small list often doesn't need debouncing at all — if there's no network round trip, filtering can run on every keystroke with no perceptible cost, and adding an artificial delay there just adds lag for no reason.
• The empty-before-typing state is prime real estate, not a placeholder to skip. Recent or popular searches shown there measurably reduce how often a user has to retype something they've searched before.
• Highlighting matched text has to go through a safe escaping step, not a raw string injection — treating user input as trusted HTML is a real vulnerability, however small the feature looks.
• A zero-results state should propose a next step, not just state the failure — a correction, a broader category, or an alternate path all turn a dead end into a recoverable moment.

Why this matters in interviews

"The search feels laggy" is a common bug report, and the strong answer goes past "the API is slow" to consider whether the debounce delay itself is tuned wrong, whether the empty and zero-results states are pulling their weight, and whether matched-text highlighting is even implemented safely — search UX is a small surface with disproportionately many places to get wrong.