State Architecture Decision Guide
Choosing the wrong state management tool wastes weeks of refactoring. This decision tree maps problem types to the right tools - use it before reaching for Redux by default.
State Management Decision Tree
- **Local to one screen?** → `useState` / `useReducer`. Don't lift state you don't need to share
- **Needed by 2-4 nearby components?** → Lift to common ancestor. Context only when prop drilling becomes painful (>3 levels deep)
- **Global UI state** (theme, language, modal open/closed)? → React Context with `useReducer`. Changes infrequently, not latency-sensitive
- **Auth state** (token, user profile, permissions)? → Auth Context + `expo-secure-store` for token. Accessed everywhere
- **Complex client cache** (products list, user feeds, pagination)? → **TanStack Query** (Module 7). It handles loading/error/stale states automatically
- **Complex cross-screen client state** (cart, draft posts, undo/redo)? → **Zustand**. Minimal boilerplate, works outside React components
- **Large team, strict patterns, time-travel debugging, RTK Query for API?** → **Redux Toolkit**
- **Never**: Use `redux` without Redux Toolkit in a new project; use `AsyncStorage` for sensitive data (use SecureStore); use Context for high-frequency updates (scroll position, timers)
Tip
Tip
Practice State Architecture Decision Guide in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Selecting the optimal state tool: Local, Context, Zustand, or Redux Toolkit
Practice Task
Note
Practice Task - (1) Write a working example of State Architecture Decision Guide from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Quick Quiz
Common Mistake
Warning
A common mistake with State Architecture Decision Guide is skipping edge case testing - empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready react native code.
Key Takeaways
- Choosing the wrong state management tool wastes weeks of refactoring.
- *Local to one screen?** → `useState` / `useReducer`. Don't lift state you don't need to share
- *Needed by 2-4 nearby components?** → Lift to common ancestor. Context only when prop drilling becomes painful (>3 levels deep)
- *Global UI state** (theme, language, modal open/closed)? → React Context with `useReducer`. Changes infrequently, not latency-sensitive