Implement the data-fetching logic for an autocomplete input whose UI is already provided. The component requests suggestions for the current query and must support debouncing, retries, latest-result wins, and caching.
### Part 1: Debounce Requests
Wait for a short quiet period before sending a request. Empty input should clear suggestions and must not trigger a fetch.
#### What This Part Should Cover
- Timer cleanup on every query change and unmount
- A clear distinction between debouncing input and delaying rendering
- Testability with an injected clock or fake timers
### Part 2: Latest Result Wins
Responses may arrive out of order. Ensure an older request cannot replace suggestions for a newer query.
#### What This Part Should Cover
- Cancellation when supported
- A request generation or query identity check
- Safe loading and error state transitions
### Part 3: Retry Transient Failures
Retry only failures classified as transient, with a bounded attempt count and backoff. A new query cancels the old retry sequence.
#### What This Part Should Cover
- Error classification
- Bounded exponential backoff with jitter
- Cancellation during sleep and fetch
### Part 4: Cache Suggestions
Reuse recent successful results by normalized query. Define cache size, freshness, and how cached data interacts with a background refresh.
#### What This Part Should Cover
- A normalized key
- TTL and bounded eviction
- Avoiding shared mutable results
- Stale-while-revalidate as an explicit option
### What a Strong Answer Covers
A strong answer treats every timer, request, and retry as cancelable lifecycle state, prevents stale writes after unmount, and keeps cache policy separate from UI rendering.
### Follow-up Questions
- Preserve accessibility announcements while results update.
- Deduplicate identical in-flight queries across components.
- Add client-side ranking without blocking typing.
Quick Answer: Implement resilient autocomplete fetching with a quiet period, bounded retries, newest-query precedence, and reuse of recent results. Cover empty input, out-of-order responses, cancellation during waits and requests, error classification, freshness and capacity policies, unmount safety, accessibility, shared requests, and responsive ranking.
Implement the data-fetching logic for an autocomplete input whose UI is already provided. The component requests suggestions for the current query and must support debouncing, retries, latest-result wins, and caching.
Part 1: Debounce Requests
Wait for a short quiet period before sending a request. Empty input should clear suggestions and must not trigger a fetch.
What This Part Should Cover Guidance
Timer cleanup on every query change and unmount
A clear distinction between debouncing input and delaying rendering
Testability with an injected clock or fake timers
Part 2: Latest Result Wins
Responses may arrive out of order. Ensure an older request cannot replace suggestions for a newer query.
What This Part Should Cover Guidance
Cancellation when supported
A request generation or query identity check
Safe loading and error state transitions
Part 3: Retry Transient Failures
Retry only failures classified as transient, with a bounded attempt count and backoff. A new query cancels the old retry sequence.
What This Part Should Cover Guidance
Error classification
Bounded exponential backoff with jitter
Cancellation during sleep and fetch
Part 4: Cache Suggestions
Reuse recent successful results by normalized query. Define cache size, freshness, and how cached data interacts with a background refresh.
What This Part Should Cover Guidance
A normalized key
TTL and bounded eviction
Avoiding shared mutable results
Stale-while-revalidate as an explicit option
What a Strong Answer Covers Guidance
A strong answer treats every timer, request, and retry as cancelable lifecycle state, prevents stale writes after unmount, and keeps cache policy separate from UI rendering.
Follow-up Questions Guidance
Preserve accessibility announcements while results update.
Deduplicate identical in-flight queries across components.