---
title: React State Management
category: product
entity_type: skill
price: $15
canonical: https://forgehouse.ai/skills/react-state-management/
lang: en
hreflang_alt: https://forgehouse.ai/tr/skiller/react-state-management/
last_updated: 2026-06-20
---

# React State Management

> Master modern React state management with Redux Toolkit, Zustand, Jotai, and React Query.

A decision framework plus working patterns for picking the right state tool instead of forcing everything into one store. It draws the great divide between server state (handled by React Query) and client state (handled by Zustand, Jotai, or useState), enforces a single source of truth so the same data never lives in two places, and ships optimistic-update patterns that make actions feel instant with automatic rollback on failure. You stop fighting sync bugs and start shipping.

## Use cases
- Choosing between Redux Toolkit, Zustand, Jotai, and React Query
- Managing remote server state with caching and background sync
- Implementing optimistic UI updates with rollback
- Setting up scalable global stores with slices
- Combining client UI state with server data on one screen
- Migrating legacy Redux to Redux Toolkit

## Benefits
- The right tool per state category, ending the bugs that come from mixing paradigms
- Zero duplicated server state, so cache invalidation and race conditions disappear
- Actions that feel 0ms through optimistic updates with safe automatic rollback
- Fewer needless re-renders via selective subscriptions and state colocation

## What’s included
- A state-category and selection-criteria matrix (local, global, server, URL, form)
- Zustand quick-start plus a scalable sliced-store pattern with selectors
- Redux Toolkit slices with createAsyncThunk and typed hooks
- Jotai atomic, derived, async, and write-only atom patterns
- React Query keys factory with optimistic mutation (onMutate, onError, onSettled)
- Combined client-plus-server example and a legacy-Redux-to-RTK migration guide

## Who it’s for
React developers deciding how to structure state in a growing app and wanting to avoid sync bugs from over-globalizing or duplicating server data.

## How it runs
The skill never reaches for a store by reflex. It classifies every piece of state first, then assigns the right tool, this is the decision loop it runs:
1. Sort each state into one of five categories: local UI (useState), global client (Zustand, Jotai, Redux Toolkit), server data (React Query), URL state (search params), form state (React Hook Form), the category decides the tool
2. Apply the colocation test before anything goes global: used by 1-2 components means local useState, 3 or more siblings means context or store, lifting state higher than necessary is treated as a bug
3. Move all remote data to React Query with a query keys factory: staleTime and gcTime tuned per resource, enabled guards for dependent queries, never useState plus manual fetch for server data
4. Build the client store as Zustand slices (user slice, cart slice) combined into one typed store, exposed through selector hooks so components re-render only on the slice they read
5. Wire optimistic mutations end to end: onMutate cancels in-flight queries and snapshots the cache, the UI updates instantly, onError rolls back to the snapshot, onSettled invalidates to resync with the server
6. Enforce single source of truth in review: filter state lives in the URL only, server data in the query cache only, any value living in two places gets one owner and the copy deleted

## FAQ
### We already use Redux everywhere, is this only useful for new apps?
It includes a legacy-Redux-to-Redux-Toolkit migration guide, so existing codebases are squarely in scope. The decision framework also lets Redux stay where it earns its place; the goal is the right tool per state category, not a forced rewrite.

### What's the actual rule for choosing between the four libraries?
A state-category matrix: server data goes to React Query, client UI state goes to Zustand, Jotai, or plain useState, with URL and form state called out separately. The single-source-of-truth rule then keeps the same data from living in two stores, which is where most sync bugs start.

### Does it crown one 'best' library and lock me into it?
No. The premise is the opposite: server and client state get different tools, and the selection criteria depend on your app's shape. A one-store-for-everything prescription is exactly what it argues against.

## Price
$15, one-time, no subscription. VAT included.

Related guide: [AI code review and developer workflow](https://forgehouse.ai/guides/ai-code-review/)