Implement debounced autocomplete component
Implement an Autocomplete Input Component
Context
Build a reusable web UI component that provides typeahead autocomplete for user input. Assume a modern browser environment. You may implement with React + TypeScript (preferred) or plain JavaScript; an asynchronous function to fetch suggestions will be provided.
Assume a function is available:
-
fetchSuggestions(query: string, signal?: AbortSignal): Promise<string[]>
Requirements
-
Debounced input handling to limit network calls (e.g., 300 ms wait after the last keystroke).
-
Asynchronous fetch of suggestions using the provided fetchSuggestions.
-
Render a suggestion list below the input.
-
Keyboard navigation:
-
Arrow Down/Up to move the active selection through suggestions (wrap around permitted).
-
Highlight the active suggestion.
-
Enter submits the active suggestion if one is highlighted; otherwise, submit the current input value.
-
Reasonable edge handling:
-
Avoid race conditions from overlapping async requests.
-
Handle empty/no results gracefully.
-
Do not fetch when the query is too short (e.g., 0–1 chars).
Deliverable
-
A working component implementation with brief notes on how it satisfies the above.
-
Include any minimal CSS or class hooks to show highlighting.
-
Provide a short usage example with a mock fetchSuggestions.
Constraints & Assumptions
-
Preserve the scope, facts, inputs, and requested outputs from the prompt above.
-
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
-
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.
Clarifying Questions to Ask
-
Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
-
State explicit assumptions before making sizing or architecture decisions.
-
Prioritize the functional path first, then address reliability, security, observability, and rollout.
What a Strong Answer Covers
-
A scoped requirements summary with concrete non-goals and success metrics.
-
API, data model, architecture, consistency, capacity, and operations.
-
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
-
A validation, monitoring, migration, and launch plan appropriate for the risk level.
Follow-up Questions
-
What breaks first at 10x traffic or data volume?
-
How would you degrade gracefully during dependency failures?
-
What metrics and alerts would prove the design is healthy after launch?