State Management
Most React Native state problems are classification problems. Teams use the wrong tool because they do not clearly separate local UI state, server state, app-wide client state, and persisted state.
State categories
| State type | Examples | Typical owner |
|---|---|---|
| Local UI state | Modal visibility, tab selection, input focus | Screen or component |
| Server state | API data, paginated lists, mutations | Data fetching layer |
| Global client state | Session, feature flags, app mode | App-level store or provider |
| Persisted state | Tokens, onboarding completion, preferences | Secure or local storage boundary |
Recommended default posture
- Keep local state local.
- Treat server state as a caching and synchronization concern.
- Use global state only for information truly shared across unrelated parts of the app.
- Persist the minimum necessary data.
Server state strategy
A dedicated server-state layer is usually worth it. The benefits:
- Normalized loading and error behavior.
- Cache invalidation patterns.
- Background refresh and optimistic updates.
- Better separation between transport and presentation.
Global state strategy
Global state should stay small and boring. Good candidates:
- Auth session.
- User identity summary.
- App-level configuration.
- Cross-cutting UI mode such as theme or locale.
Bad candidates:
- Screen-local form fields.
- Data that already exists in a server-state cache.
- Temporary UI state tied to one user action.
Offline and persistence
If the app needs offline resilience, define it explicitly:
- Which data must survive process restarts?
- What should be cached versus persisted?
- How are failed mutations retried?
- What conflict resolution strategy exists?
Offline behavior should be product-driven, not accidental.
Form state
Form-heavy apps should standardize:
- Validation timing.
- Error presentation.
- Field state ownership.
- Submission retries and disabled states.
Without a standard, every screen handles validation and feedback differently.
Anti-patterns
- Storing everything in one global store.
- Mixing API calls directly into presentational components.
- Duplicating the same server data in multiple stores.
- Persisting sensitive data without a security model.
Decision rule
Use the smallest state mechanism that matches the state's actual lifetime and sharing requirements. Complexity should be earned, not assumed.
From here, continue to Device APIs and Native Capabilities.