Stale-while-revalidate with memory and localStorage caches
The first visit has no cache, so it shows a skeleton. On the second visit (the key change remounts Price) the cached price appears instantly while a fresh one loads, then it's swapped in. In the preview localStorage is in memory and resets on each Run.
A resilient app keeps copies of data in layers (memory, localStorage, IndexedDB, the HTTP cache and a service worker), shows cached data at once and refreshes it in the background (stale-while-revalidate), updates the screen optimistically and rolls back on failure, notices when the network goes away, and saves drafts and queued actions so nothing the user typed is lost.
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 usePersistentState(key, initial) hook that works like useState but saves to localStorage, safely.
Add a "You're offline" banner to any app using useSyncExternalStore.
Explain it without notes
Compare memory, localStorage, IndexedDB, the HTTP cache and service workers as caching layers.
What is stale-while-revalidate and why does it improve UX?
How do you implement an optimistic update safely?
How would you make a form work offline without losing data?
Preview
Console
Nothing logged yet.Expected console output
Visit 1: shows a skeleton (checking for updates)
Visit 1: shows 100 (fresh)
Visit 2: shows 100 (checking for updates)
Visit 2: shows 105 (fresh)