Server State Versus UI State
The distinction between data owned elsewhere and cached locally, and state that exists only in this session — conflating them causes most client state bugs.
Server state is data owned by the backend and held on the client as a cache. It can be stale, it can be refetched, it can be invalidated, it may be shared between components, and it needs loading and error representations. It is a caching problem.
UI state is local and authoritative: which tab is open, whether a modal is showing, the current value of an uncontrolled input, scroll position. It cannot be stale because nothing else owns it.
Putting both in one global store treats the first as though it were the second: the cached list of orders is stored as though the client owned it, so there is no staleness model, no revalidation, and the developer manually writes into the store after every mutation — which is cache invalidation implemented by hand, without naming it.
Separating them makes each simple. Server state goes to a data-fetching layer with caching, deduplication, background revalidation and retry built in. UI state stays local to the component that owns it, and is lifted only when genuinely shared.
Most "our state management is unmanageable" complaints resolve to this one distinction not having been made.