Editorial illustration.
Originally published 23 June 2023; rewritten and reviewed on 15 October 2026.
A user types three characters, pauses and then changes the query. Suggestions from the first request appear under the new text. The result may be technically valid and still be wrong for the interaction. I would treat relevance as part of the autocomplete contract.
Define the trigger and the response
Trim the query and wait for the minimum length before sending a request. A short debounce can reduce traffic while someone is still typing. Three characters is a reasonable example threshold, but the correct value depends on the dataset and the task.
Return a small, bounded result containing stable identifiers and display text. Apply filtering, authorisation and deterministic ordering on the server. Do not expose records simply because their names match.
Prevent stale results from taking over
Keep a request sequence number or cancel the earlier request where supported. Before displaying a response, confirm it still corresponds to the current query. Clear suggestions when the text falls below the threshold or the user has chosen a value.
Render suggestion names as text and preserve the difference between what the user typed and the identifier selected. On form submission, validate that identifier again; the browser list is not an authorisation decision.
Support more than a mouse click
Provide meaningful labels, keyboard movement, selection and dismissal. Announce loading and empty results appropriately, and do not trap focus when the list changes.
Test rapid typing, no results, a failed request and two records with similar labels. Decide what happens if a selected record is removed before submission. A polished autocomplete helps someone choose the right record without disguising uncertainty or allowing a delayed response to rewrite their intent.