Server State vs Client State

Server state is remotely owned, asynchronous data that the frontend reads or updates through a backend, while client state is local data controlling UI behavior and interactions. Separating them helps choose appropriate storage, synchronization, caching, and update strategies.

Server state originates outside the browser and is typically fetched over a network. Examples include user profiles, product catalogs, permissions, and notification data. It can become stale, may be shared across screens or users, and usually requires loading, error, retry, caching, and synchronization behavior.

Client state is owned by the frontend application and primarily exists to represent local UI or interaction concerns. Examples include whether a modal is open, the current tab, an input's temporary value, or a selected item. It generally does not need synchronization with a remote source unless the application explicitly persists it.

The distinction is about ownership and lifecycle rather than where a variable is physically stored. A server response held in a React component is still server state, while a locally chosen theme stored in a global store remains client state. Treating remote data as ordinary UI state often leads to duplicated fetching logic, stale copies, and unnecessary synchronization code.

Frontend applications commonly use data-fetching or server-state libraries for remote data and component state, context, or client-state stores for UI state. The exact choice depends on application complexity, but the key design question is whether the backend is the authoritative owner of the data.

Key points

• Server state is remotely owned and accessed asynchronously.
• Client state is locally owned and usually represents UI or interaction concerns.
• Server state can become stale and often benefits from caching and synchronization.
• Avoid duplicating server data into general-purpose client stores without a clear reason.
• Choose state-management tools according to ownership, lifecycle, and synchronization needs.

Interview questions

What is the difference between server state and client state?

Server state is data whose authoritative source is a backend service, such as a user's profile or a product list. It is usually asynchronous and can become stale, so fetching and caching are important concerns. Client state is owned by the frontend and commonly represents UI or interaction state such as modal visibility or the active tab. The distinction is primarily about ownership and lifecycle.

Why should server state not automatically be treated like ordinary client state?

Remote data has characteristics that local UI state does not, including network latency, failures, staleness, caching, and synchronization. If an application copies remote data into a general client store, it may create two sources of truth. The application then needs extra logic to keep those copies consistent. A server-state-oriented approach can instead centralize fetching, caching, invalidation, and refetching behavior.

How would you decide whether a piece of state belongs in a server-state library or a client-state store?

First, I would determine who owns the data and whether the backend is authoritative. If it comes from an API and needs fetching, caching, synchronization, or invalidation, it is a strong candidate for server-state management. If it represents local UI behavior, such as a dialog being open or a temporary selection, ordinary client-state mechanisms are usually appropriate. I would also consider whether the state needs to survive navigation, be reflected in the URL, or be shared across unrelated components.

What problems can arise when server data is duplicated into a client store?

The primary risk is having multiple representations of the same remote entity. After a mutation, one copy can be updated while another remains stale, producing inconsistent UI. The application may also need custom synchronization, invalidation, and refetch logic that a dedicated server-state solution could already provide. Duplication can still be appropriate for deliberate client-side transformations or workflows, but the ownership boundary should remain explicit.

Is data stored in a React component automatically client state?

No. Storage location does not determine ownership. A component can temporarily hold server data returned by an API, but the data is still server state because the backend is authoritative. Conversely, a local UI value can be placed in a global store and remain client state. Classification should therefore focus on where the data comes from and who is responsible for its truth.