Remote Data
The life of server-owned data in a component tree: when a request starts, what renders meanwhile, which response lands, how it is cached, how a write goes back. Most screen bugs are data-timing bugs.
on this pageshowhide
explore
- Fetch Timing & Waterfalls5 questions
- Loading, Error & Empty States6 questions
- Request Races & Cancellation5 questions
- Server-State Cache & Staleness6 questions
- Writes & Optimistic Updates5 questions
- Live Updates & Streams6 questions
questions
page 2 of 2As a lead, how would you set one convention for loading, error and empty states across many screens built by several teams?
basics
~20 sStandardise the vocabulary and the obligations: the named states every data-backed surface must handle, the copy pattern and action each branch carries, the escalation policy. Leave placeholder shape and fallback granularity to the team that knows the screen.
How do you decide which pushed signals belong in the shared data cache and which stay ephemeral?
basics
~20 sAsk whether anything reads the value back later. Server-owned records a later-mounting component must see belong in the cache. Presence, typing flags and live cursors are true only now, churn constantly, and belong in a short-lived ephemeral store.
How would you set the default staleness window for cached server data across an app, and who should own the exceptions?
basics
~20 sSet the default from the consequence of showing a slightly old value, not from a feeling about speed. Classify data by that consequence, give the app one modest non-zero default, and record every exception in a single reviewable table.
showing 31–33 of 33