Server state is a cache you did not admit to
The moment you put a fetched list in a store, you own a cache. Naming it changes which questions you ask about it.
Client state you own: it is true because you say so. Server state you do not: it is a copy of something on another machine that can change without telling you, may be stale the instant it arrives, can fail to load, can load twice at once, and belongs to a user who might log out. Treating those two identically is why so many applications have a manual refresh button.
Once you call it a cache the questions become obvious. How long is this fresh for. What happens when two components ask at once. When does it refetch, on focus, on reconnect, on an interval, never. What happens to it after nobody is looking. What invalidates it after a mutation. Those are the questions a query library answers, and they are the ones you are answering implicitly if you do not use one.
This is also why server components change the calculation rather than removing it. Fetching on the server removes the client cache for data you only read once. It does not remove it for anything the user interacts with, and knowing which is which is a design decision you make per feature rather than per application.
You should now be able to
- Explain why server state is categorically different from client state
- List the questions a cache forces you to answer
Loading…