Sort your state before you store it

Two years building production dashboards taught me that most "state management" problems aren't storage problems. They're sorting problems.

A dashboard I worked on kept the same filter state in three places: the URL (so links could be shared), a Redux slice (so distant components could read it), and a local useState (because someone needed it fast, once, in one component). The three copies disagreed constantly. The bug reports said "the filters are broken." The filters were fine. The sorting was broken.

Here's the rule I use now: before choosing a tool, sort every piece of state into one of four buckets.

1. Server state

Data that lives on a server and you're just borrowing — API responses, lists, pagination. This is the biggest bucket in any dashboard, and it doesn't belong in your client store at all. I use RTK Query for this: it owns the cache, the refetching, the loading states. The day I stopped duplicating API data into Redux slices "just in case," a whole class of stale-data bugs disappeared.

2. Client state

State your app actually owns — UI toggles, wizard steps, unsaved form input. useState and useReducer handle most of it. When distant components need it, a small store (Zustand in my newer projects) beats prop drilling without Redux's ceremony.

3. URL state

Filters, tabs, page numbers, selected rows. If a user should be able to share it, refresh it, or go back to it, it belongs in the URL. This was the expensive lesson: the filter bug above vanished the day filters moved to search params. Shareable links became a feature instead of a bug report.

4. Ephemeral state

Hover states, animation flags, "just clicked" feedback. Local, short-lived, never leaves the component. The most common mistake I see is promoting this to global state "for consistency." Don't — consistency here means every component handles its own ephemera.

The checklist

A four-question version I run before adding any state:

1. Does it come from the server? → query cache (RTK Query / TanStack Query), not the store.
2. Should it survive a refresh or be shareable? → URL.
3. Do distant components need it? → small global store.
4. Otherwise → local state, where it's used.

Most state debates I've sat through were really arguments about skipping question one.

The deeper point: state tools don't fix state thinking. Redux, Zustand, Context — they're all fine. The bugs live one level up, in the decision about where each piece of data belongs. Sort first, store second, and the "complexity" of state management turns out to be mostly self-inflicted.