Two kinds of state
Not all state is the same. Client state is data your app fully owns and that lives only in the browser, like a toggled menu, a selected tab, or text inside an input. Server state is data that lives on a server and that your app merely borrows a copy of, like a user profile or a list of orders.
- Client state is synchronous and always up to date because you are the only writer.
- Server state is asynchronous and can be stale because someone else may change it.
- Server state needs caching, refetching, and error handling that client state never does.
Why the split matters
Teams get into trouble when they shove server data into a plain client store and then hand write loading flags, retries, and cache rules. That code grows fast and breaks often.
- Treat server state with a data fetching library that handles caching for you.
- Keep client state in local component state or a small store.
- Never copy server data into client state just to mutate it directly.
Drawing this line early tells you which tool each piece of state belongs in and stops one giant tangled store from forming.
Key idea
Decide whether each piece of state is owned by you or borrowed from a server, because borrowed server state needs caching and refetching that owned client state does not.