Client Cache & Optimistic UI

Query keys, freshness, staleness and revalidation; updating the interface before the server has agreed, and reconciling honestly when it does not.

The Client Cache Model
▶ lab

A key, an entry, a freshness state and a revalidation rule — the cache your application owns, which is not the browser's HTTP cache and does not obey its headers.

Q · When my application already has this data, what decides whether it asks the server for it again?
Query Keys and Invalidation
▶ lab

The key is the identity of the data. Deduplication, hits, cross-contamination and the blast radius of every invalidation are all decided by what you put in it.

Q · What exactly identifies this piece of server data, and what should happen to it when something changes?
Stale-While-Revalidate
▶ lab

Render what you have, fetch what is current, write it in — and take responsibility for the fact that the page changed under the person reading it.

Q · Should I show the user data I already have while I check whether it is still true?
Optimistic UI
▶ lab

Updating the interface before the server has agreed: a claim the client makes on the authority's behalf, acceptable exactly when the rollback is honest.

Q · When is it right to show the user that something happened before the server has confirmed that it did?
Rollback and Reconciliation
▶ lab

The server rarely just says yes or no. It says something slightly different — and reverting your prediction is usually the wrong answer to that.

Q · The server accepted my mutation and returned something other than what I predicted. Now what?
Out-of-Order Responses
▶ lab

"cat" then "car": A leaves first, B returns first, A returns last and overwrites the newer result with the older one. The fix is a rule about which response is allowed to win.

Q · Two requests are in flight for the same piece of the interface. Which response is allowed to write to the cache?