Remote Data

The first render happens with no data, because the request only starts once the component exists. The user waits for that dataless frame plus a full round trip, and every nested component that fetches repeats the pattern.

A write passes through idle, pending, then success or failure, and the component renders each. Disabling the trigger while pending stops a duplicate write the server may apply twice, whose two responses can also land in either order.

Debouncing waits for a quiet gap after the last keystroke and then fires once; throttling fires at a fixed maximum rate while typing continues. A search field wants debouncing, because only the settled query matters.

Stale means the entry is still usable but no longer trusted to match the server. A reader gets the cached value immediately as data, not as loading, while the cache refetches behind it and re-renders on arrival.

Per-component flags give each component its own placeholder: fine granularity, many indicators, coordination by hand. A subtree that declares itself not ready hands one ancestor fallback the whole region: one coherent placeholder, but everything inside waits for the slowest part.

Only a request whose input comes from another response has to wait for it. Most nested waits are accidental: the child's key was already available from the URL or a prop, so hoisting the declaration lets both start together.

In the same cache entries components already read. A push channel is just another writer of existing keys, so views re-render through their normal subscription and no component cares whether a value came from a request or an event.

An optimistic update patches the cached copy with the client's predicted result before the request settles. Rollback needs the previous value of exactly the entries it touched plus the patch's own identity; success needs reconciliation with the server's representation.

Responses can come back in a different order than the requests went out, and both write to the same state, so the slower earlier one lands last and wins. A latest-wins rule fixes it: only the newest request may write.

An entry is created on first request, stays fresh inside its staleness window, goes stale past it, becomes unused when its last subscriber unmounts, and is collected after the retention window. Two independent timers govern it.

Not simply the last to arrive: a response reflects server state from when the request started, so it can be older than an event landing after it. Order writes by a server-owned revision, or refetch when none exists.

The payload is the same empty collection, but the cause and the next step differ. Nothing created yet needs the action that creates the first item; a filter that excluded everything needs widening or clearing. One shared message misleads one audience.

The wait moves in front of the screen: a loader on the route starts the screen's requests before the destination renders, so the screen arrives complete and with no internal waterfall. The price is a slower-feeling navigation.

By what the payload can support: a full resource replaces the entry, a partial change with a stable identity patches it, a bare notification only invalidates the affected keys. Never patch from a payload that leaves the record inconsistent.

Patch when the response carries the complete updated form of exactly what changed and nothing derived elsewhere depends on it. Invalidate and refetch when the write moves counts, ordering, pages or other entities, or when its response says nothing useful.

By keying requests in flight: the first ask starts the request and stores its pending result under a key derived from the request; identical asks arriving while it is pending attach to that same pending result.

A keyed cache stores each response under the request that produced it, so one record can sit in several entries, each refreshed separately. A normalized cache stores each record once by identity, so one update reaches every reader.

The accumulated list is what the user sees, so it needs one loading state, one refetch and one invalidation. Pages are not independent either: a cursor page depends on the previous response, and offset pages shift when rows are inserted.

Decide by blast radius and by what can be retried. A local branch keeps the rest of the screen alive and a precise retry next to the component that issued the request. Escalate when the failure invalidates the whole region.

Each panel branches on “a request is in flight” instead of “there is nothing to show”. With a previous value held, keep rendering it and mark progress quietly; reserve the placeholder for the load that has nothing to replace.

Intent arrives before the click, so the request overlaps the user's decision time and is in flight when the screen renders. The costs: requests for destinations nobody opens, and a result the destination must find by key.

Because the changes made while disconnected were never delivered, so entries sit at pre-gap values with nothing marking them stale. Reconnect must resubscribe and trigger a catch-up read of the keys that still have readers.

To the set of interested readers, not to one component. Reference-count per key in the cache layer: the first reader opens the subscription, later readers join it, and the last teardown closes it after a short grace window.

Stop treating each response as the final word. Track how many writes to that entity are in flight, derive the view from a base value plus ordered pending patches, ignore or queue superseded writes, and revalidate once nothing is pending.

It depends who owns the request. A read whose only consumer was that instance should be cancelled; a read a shared layer keeps for other consumers should finish. A write already sent must complete.

Separate two symptoms: too many requests, and content replaced by a placeholder. Loading over an existing entry points at a missing or unstable key, not a trigger. Then keep each trigger only where data changes unobserved and refetching is cheap.

Separate the request's definition from its start site. Describe it once, parameterised and keyed, so any layer can refer to it; then choose who starts it per surface — the route, an intent handler, or the component that reads it.

Weigh how predictably the client can compute the result against the cost of being wrong. Optimism fits reversible, self-contained, frequent changes; a write the server decides, or whose reversal would confuse or cost, should wait.

Put the policy in one shared layer once more than a handful of screens race: request identity, latest-wins, deduplication and cancellation then hold by default rather than per call site. Per-component guards suit only one-off, screen-private requests.