State Categories and Decision Framework

The Dirty Secret of Frontend State

Here's something that took the React ecosystem about 8 years to figure out: not all state is the same. For years, we shoved everything into Redux — API responses, form inputs, sidebar toggles, URL parameters, WebSocket messages — and then wondered why our apps were slow, buggy, and painful to maintain.

The problem was never Redux itself. The problem was treating fundamentally different kinds of data as if they had the same requirements. That's like storing milk, documents, and fireworks in the same cabinet. They need different containers because they have different properties.

The Five Categories of Frontend State

1. Server State

Data that originates from a remote source. The server is the source of truth, and your client copy is a stale cache that can become outdated at any moment. This is the category most teams get wrong.

const { data: user } = useQuery({
  queryKey: ['user', userId],
  queryFn: () => fetchUser(userId),
  staleTime: 5 * 60_000,
});

Server state has concerns that no other category shares:

• Caching — how long is this data fresh?
• Deduplication — two components requesting the same data should not trigger two fetches
• Background refetching — data should refresh when the user refocuses the tab
• Optimistic updates — show expected results before the server confirms
• Retry with backoff — network failures need automatic recovery

Putting this in Redux means you build all of that yourself. TanStack Query gives it to you out of the box.

2. Client UI State

State that exists only in the browser. The server doesn't know about it and doesn't care.

const [isSidebarOpen, setSidebarOpen] = useState(false);
const [selectedTheme, setSelectedTheme] = useState('dark');
const [activeTab, setActiveTab] = useState('overview');

This is typically small. If your "client state" store has 40 slices and 35 of them are API responses, you don't have a client state problem — you have a server state problem solved with the wrong tool.

3. URL State

State encoded in the URL — query parameters, path segments, hash fragments. URL state is special because it's the only state that's shareable and survives page refreshes without extra work.

// /products?category=electronics&sort=price&page=3
const searchParams = useSearchParams();
const category = searchParams.get('category');

If a user can't send their current view to a colleague by copying the URL, you've lost one of the web's superpowers.

4. Form State

Ephemeral state tied to a user's in-progress input. It has a clear lifecycle: initialize, edit, validate, submit, discard. Form state rarely needs to be global.

const { register, handleSubmit, formState } = useForm<CheckoutForm>();

5. Real-Time State

State pushed from external sources — WebSocket messages, Server-Sent Events, collaborative editing data. Real-time state has unique challenges around conflict resolution, ordering guarantees, and reconnection.

const [cursors, setCursors] = useState<Map<string, Cursor>>(new Map());
socket.on('cursor-move', ({ userId, position }) => {
  setCursors(prev => new Map(prev).set(userId, position));
});

The Colocation Principle

This is the single most important rule in state management, and it's deceptively simple:

State should live as close as possible to where it's used.

Global state is the last resort, not the default. Before reaching for Zustand or Redux, ask: can this be useState in the component that needs it? Can it be useSearchParams? Can it be a TanStack Query cache entry?

Why "Just Use Redux" Is Outdated

Let's be clear: Redux is not bad. Redux Toolkit is genuinely well-designed. But the ecosystem that made Redux the default answer for everything has changed dramatically.

In 2016, Redux was the only tool. There was no TanStack Query for server state, no useSearchParams for URL state, no useActionState for form state, no Zustand for lightweight client state. Redux was the Swiss Army knife because it was the only knife.

Today, specialized tools exist for every category. And specialized tools beat general-purpose ones every time:

The remaining use case for Redux is genuinely complex client state with strict requirements: time-travel debugging, action replay for bug reports, middleware pipelines for audit trails, or state machines too complex for simpler tools. That's maybe 5-10% of apps.

The Decision Framework

Here's the framework your team can use for any new piece of state. Ask these questions in order:

Common Anti-Patterns

Putting It All Together

Here's what a well-architected state setup looks like for a typical production app:

// Server state — TanStack Query
const { data: products } = useQuery({
  queryKey: ['products', { category, sort, page }],
  queryFn: () => fetchProducts({ category, sort, page }),
});

// URL state — nuqs
const [category, setCategory] = useQueryState('category');
const [sort, setSort] = useQueryState('sort', parseAsStringEnum(['price', 'name', 'date']));
const [page, setPage] = useQueryState('page', parseAsInteger.withDefault(1));

// Client UI state — Zustand (only for truly shared state)
const isSidebarOpen = useUIStore((s) => s.sidebarOpen);

// Form state — React Hook Form
const { register, handleSubmit } = useForm<ReviewForm>();

// Local state — useState (default choice)
const [isDropdownOpen, setDropdownOpen] = useState(false);

Five categories, five tools, zero overlap. Each tool does what it's best at. That's the architecture.