What this prompt does
This prompt designs the state management architecture for a React app, recommending the right combination of tools rather than forcing one library to do everything. It evaluates React Context, Zustand, Jotai, Redux Toolkit, and TanStack Query against your app's needs, then explains for each state category which tool to use and why, with folder structure, store setup, custom hooks, devtools, persistence, and a migration path from your current solution — plus a data-flow diagram.
The variables describe your situation so the recommendation fits. [app_type] and [complexity_level] set scale, [data_types] lists the kinds of state you hold (session, server data, UI state, forms, notifications), [realtime_needs] and [offline_required] flag WebSocket and offline concerns, and [current_solution] is what you're migrating from. The key insight the prompt encodes is separating server cache from client state: TanStack Query owns server data, while Zustand or Context owns UI state. Pressure-testing that split and the migration path before committing prevents the common mess of one over-stretched store.
When to use it
- Choosing state tools for a new non-trivial React app before writing stores
- Untangling an app where one Redux store has absorbed every kind of state
- Deciding where server cache ends and client UI state begins
- Planning a migration off Redux thunks to a lighter combination
- Designing persistence and offline-read strategy deliberately
- Documenting a data-flow diagram so the team shares one mental model
Example output
You get a written recommendation mapping each of your [data_types] to a specific tool, with rationale, plus folder structure, example store setup, custom hooks, devtools configuration, and a persistence strategy. There's a concrete migration path from [current_solution] and a data-flow diagram showing how state moves through the app. Rather than "use Zustand," it justifies the split — server data on TanStack Query, UI state on Zustand or Context — so the choices hold up as the app grows.
Pro tips
- List
[data_types]honestly and granularly; lumping server data in with UI state is exactly the mistake this prompt exists to prevent - Set
[complexity_level]realistically — over-stating it invites heavier tooling than a medium app needs - Be specific about
[realtime_needs]; WebSocket-driven state has different caching implications than polled data - Name your actual
[current_solution]so the migration path is concrete rather than generic advice - Treat the recommendation as a decision to debate, not a verdict — the value is in the rationale, which you can challenge
- Resist adopting every tool it suggests at once; migrate one state category at a time using the provided path
