Aborting the previous request
Only rea finishes on the server. The aborted line comes after the next start because the cleanup aborts synchronously but the rejection is delivered asynchronously (a microtask). Combine this with a debounce (Topic 10.2) so fewer requests start at all.
Responses can arrive out of order, so ignore or abort stale requests; share one request between components that need the same data (deduplication); and show cached data at once while refreshing it in the background (stale-while-revalidate). Building a tiny cache shows how data libraries work inside.
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 latestOnly(fn) helper that wraps an async function so only the most recent call's result is delivered (older calls resolve to undefined).
Add a 5-second timeout to a fetch in an effect that's also cancelled on unmount.
Extend the tiny cache with an invalidate(key) function that marks the entry stale and refetches it if any component is subscribed.
Explain it without notes
What is a race condition in data fetching, and how do you reproduce one?
Compare the ignore flag and AbortController. When would you use each?
What is request deduplication and how would you implement it?
Explain stale-while-revalidate and what staleTime adds to it.
Preview
Console
Nothing logged yet.Expected console output
server: start "r"
server: start "re"
client: aborted "r"
server: start "rea"
client: aborted "re"
server: done "rea"
screen: REA results