Comparison
Client statevsServer state
Client state
the value only exists because this screen is open, and nobody else in the world needs to know about it.
State the browser owns outright: which tab is selected, whether the menu is open, what has been typed but not submitted. It is synchronous, never stale, and cheapest kept as close to the component that uses it as possible. Promoting it to a global store 'just in case' is the usual way a codebase acquires a state management problem it did not have.
Full entry →Server state
the data on screen is a copy of something you do not own, and it went out of date while you were looking at it.
Data whose source of truth lives on a server and is merely cached in the client. It has properties client state does not — it can be stale, it can be shared with other users, it needs loading and error states, and it needs revalidating — which is why hand-rolling it with a state atom and an effect reproduces a caching library badly. Recognising which of your state is this kind is the single most useful sorting exercise in a frontend codebase.
Full entry →