A complete autocomplete: debounce, abort, cache, highlight, keyboard and ARIA
The fake API answers shorter queries more slowly, so "b" would arrive after "bl": aborting it in the cleanup keeps the right results. Picking with ArrowDown, ArrowDown, Enter selects the second option. Typing "bl" again comes from the cache with no new request. Try it with the keyboard and a screen reader.
A search box that suggests as you type waits for a pause before asking the server (debounce), cancels or ignores answers to old queries, caches results it has seen, highlights the matching text, and follows the ARIA combobox pattern so arrow keys, Enter, Escape and screen readers all work, with clear loading, empty and error states.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write a useDebouncedValue(value, ms) hook and use it to log a query only after typing stops.
Add a size limit to the autocomplete cache so it keeps only the 50 most recently used queries.
Explain it without notes
Explain debounce and throttle and give a use case for each.
How do you prevent stale search results from overwriting fresh ones?
Walk through the ARIA and keyboard behaviour of an autocomplete.
What states should a search UI handle?
Preview
Console
Nothing logged yet.Expected console output
Options for 'bl': Blackberry, Blueberry (requests: 2)
Picked with the keyboard: Blueberry
'bl' again from the cache (requests: 2)
No fruit matches “kiwi”