# Implement an Accessible Autocomplete Search Component Build a frontend autocomplete search bar from a supplied visual design. As the user enters text, show matching suggestions in a list. The list should use alternating row backgrounds while preserving selected, hover, focus, loading, empty, and error states. Assume a provided asynchronous `search(query)` function returns an array of results with stable IDs and display labels. ### Constraints & Assumptions - Do not search for an empty or whitespace-only query. - Results from an older request must not replace results for a newer query. - Keyboard and screen-reader users must be able to navigate and select results. - Styling must not encode selection or errors through color alone. - The component should remain responsive while requests are pending. ### Clarifying Questions to Ask - Is selection submitted immediately, or does it populate the input first? - What debounce interval and minimum query length are expected? - Should matching text be highlighted, and is matching case-sensitive? - How should the component behave when it loses focus? ### Part 1: State and Request Flow Describe the component state and event flow from typing through displaying a response. #### What This Part Should Cover - Query, results, active index, status, and selected value as distinct state. - Debouncing where appropriate and cancellation or sequence guards for stale requests. - Reset behavior when the query is cleared or a result is selected. ### Part 2: Interaction and Accessibility Explain mouse and keyboard behavior and the semantic relationship between the input and result list. #### What This Part Should Cover - Arrow-key navigation, Enter selection, Escape dismissal, and predictable focus handling. - Combobox/listbox semantics, active-descendant linkage, labels, and status announcements. - Stable keys and safe handling when results change under the active index. ### Part 3: Styling and Verification Explain how you would implement alternating row backgrounds without breaking other states, and describe the most important tests. #### What This Part Should Cover - Base striping with explicit precedence for active, selected, hover, and disabled states. - Tests for stale responses, keyboard navigation, empty/error behavior, and design-state styling. - Separation of data behavior from presentation where practical. ### What a Strong Answer Covers - A race-safe asynchronous state model and clear loading/empty/error behavior. - Complete keyboard and assistive-technology interaction, not only clickable rows. - Styling that follows the design while keeping interaction states visible. - Focused component and integration tests for timing, accessibility, and selection. ### Follow-up Questions - How would you virtualize thousands of suggestions while preserving accessibility? - When would you cache prior query results? - How would you avoid issuing duplicate requests across multiple autocomplete instances?