Client-Side Data Layer

The distinction this rests on is the one that untangles most frontend state confusion: server state is a cached copy of data owned elsewhere, which can go stale, needs revalidation and may be changed by someone else. Client state is genuinely local — a form's contents, whether a panel is open, the current filter selection.

Storing server state in a general-purpose client state container was the standard approach for years and produced enormous amounts of hand-written code for loading flags, error handling, refetching, deduplication and cache expiry, reimplemented per feature and slightly differently each time.

A data layer library handles that generically: request deduplication so ten components asking for the same resource produce one call, stale-while-revalidate so the interface renders instantly from cache and updates when fresh data arrives, background refetching on window focus or reconnection, and optimistic updates with rollback.

The architectural consequence worth noting is that this pushes cache invalidation into the client, where it is subject to the same difficulties as anywhere else. Tag-based invalidation after a mutation is the usual approach, and getting it wrong shows up as a user completing an action and seeing the old value — a bug class that is hard to reproduce and easy to ship.