When React State Management Gets Complicated: Context vs Redux vs RTK Query

The real question isn't "which library" — it's "what kind of state"

Most state management debates skip a step. Before picking a tool, I sort state into three buckets, because each one has a different natural home.

Bucket 1: UI state

Is a modal open? Is a tab active? This state is local, short-lived, and rarely needs to leave the component tree. useState or useReducer is usually enough. Reaching for Redux here is like using a warehouse to store a sticky note.

Bucket 2: Shared app state

Theme, current user, feature flags — state that many unrelated components need to read but rarely need to write frequently. This is where Context earns its keep. It's built into React, requires no extra dependency, and for state that changes infrequently, the re-render concerns people worry about rarely matter in practice.

Bucket 3: Server state

This is the one people most often get wrong. Product lists, inventory counts, order status — this data doesn't originate in the client at all. It's a cached copy of something the server owns. This is where RTK Query (or React Query) fits, because it solves problems Context and plain Redux don't natively handle: caching, refetching, invalidation, and loading/error states as first-class citizens.

So where does plain Redux still fit?

Redux (without RTK Query) still makes sense when you have complex, client-owned state that many features read and write, with logic that benefits from a predictable, centralized store — think a multi-step checkout flow with branching logic, or a POS interface managing an in-progress offline transaction. If your state is genuinely complex and client-driven, not just server data in disguise, Redux's structure pays for its boilerplate.

A framework, not a rule

The mistake isn't picking the "wrong" library — it's using one tool for all three buckets because it's the one you reached for first. Sort the state first. The tool choice gets a lot easier after that.

A concrete example: an e-commerce cart

To make the framework tangible, consider a shopping cart. Whether the cart drawer is open is UI state (useState). The current logged-in user and their currency preference is shared app state (Context). The multi-step checkout flow — shipping, payment, review, with validation and branching between them — is complex client logic that benefits from Redux's structure. The actual product catalog and current stock levels are server state, best handled by RTK Query with its built-in caching and refetch behavior.

Trying to force all four of these into a single tool is where most react state management pain actually originates — not from React itself, but from a mismatched tool-to-problem fit.

Common signs you've picked the wrong bucket

• If you're manually tracking isLoading and error booleans next to server data in Redux, that's usually a sign the data belongs in RTK Query instead
• If a Context value changes on every keystroke and is causing visible re-render slowdowns, that state was probably better suited to local state or a more targeted subscription
• If a useState value is being prop-drilled through six components, it's outgrown local state and needs promotion to Context or a store

Migrating without a rewrite

You rarely need to migrate an entire app's state management at once. Because these tools solve different problems, it's usually possible to introduce RTK Query for server data while leaving existing UI state exactly as useState, without touching unrelated code. Incremental adoption, driven by which bucket is actually causing pain today, is far more realistic than a full rewrite motivated by a blog post.