saranskumar Goal
Design state boundaries that keep the frontend predictable and maintainable.
When to Use
- A feature is becoming state-heavy.
- The app mixes server data, form state, and UI state.
- The team needs a state-management decision before coding.
Instructions
- Classify data as server state, client state, form state, or derived UI state.
- Decide what belongs in component state, context, store, or query cache.
- Define update patterns, invalidation rules, and optimistic behavior.
- Note persistence needs, sync needs, and cross-route sharing.
- Recommend conventions that fit the team's stack.
Constraints
- Do not use global state by default.
- Do not store server cache in local stores unless there is a strong reason.
- Keep state ownership explicit.
Output Format
- State classification
- Ownership map
- Update rules
- Tooling recommendation
- Risks
Examples
- "Design state management for a collaborative editor."
- "Should this Next.js app use Zustand, context, or query state?"