# Build a Debounced Autocomplete Search Bar Design and implement an autocomplete search bar that waits briefly after typing before requesting suggestions. It must remain correct when users type quickly, delete text, move focus, select a result, or receive responses out of order. ### Constraints & Assumptions - Suggestions come from a remote endpoint and are keyed by the complete query string. - Empty or whitespace-only input closes the result list and makes no request. - The debounce interval is configurable; 250 milliseconds is a reasonable starting point, not a correctness requirement. - Suggestions have stable IDs and accessible display labels. - Network requests may fail, finish out of order, or complete after the component unmounts. ### Clarifying Questions to Ask - What minimum query length and result limit should apply? - Should identical recent queries use a cache, and how stale may it be? - Does selection navigate immediately or only fill the input? - Which keyboard, screen-reader, mobile, and international-input behaviors are required? - Should a blur close the list before or after a pointer selection is processed? ### Hints - Debouncing request creation does not by itself prevent stale responses. - Keep highlighted option identity separate from its current array index. - Define loading, empty, error, and closed states explicitly. ### What a Strong Answer Covers - Controlled input state and timer cleanup with no lost keystrokes. - Cancellation or request-generation guards so an older response cannot replace newer results. - A small state machine for closed, waiting, loading, success, empty, and error states. - Keyboard navigation, focus and blur ordering, combobox semantics, live announcements, and stable option IDs. - Cache policy, duplicate-query handling, composition events, testing with fake timers, and observability. ### Follow-up Questions 1. Why is canceling the debounce timer insufficient to prevent every stale result? 2. How would you preserve the highlighted option when cached results are refreshed? 3. How should the component behave during an input method editor composition session? 4. When would server-side rate limiting still be necessary even with client debouncing?