95 lines
2.6 KiB
Markdown
95 lines
2.6 KiB
Markdown
# Example: Architecture Decision with Sequential Thinking
|
|
|
|
**Problem**: Choose state management for growing React app.
|
|
|
|
## Sequential Thinking Approach
|
|
|
|
```
|
|
Thought 1/4: Initial assessment
|
|
|
|
React app growing complex. useState scattered across components.
|
|
Need centralized state management.
|
|
Options: Redux, MobX, Zustand, Context API, Jotai.
|
|
|
|
Next: Define requirements
|
|
|
|
Thought 2/5: Requirements (adjusted up)
|
|
|
|
App needs:
|
|
- Real-time updates (WebSocket)
|
|
- Offline support
|
|
- Complex nested state
|
|
- Multiple devs (maintainability)
|
|
- TypeScript (type safety)
|
|
|
|
These eliminate simpler solutions.
|
|
Next: Evaluate remaining options
|
|
|
|
Thought 3/5 [REVISION of Thought 1]: Scope refinement
|
|
|
|
Original assumption: Need global state management.
|
|
Realization: Not all state needs centralization.
|
|
|
|
Better breakdown:
|
|
- Server state (API data): React Query
|
|
- UI state (modals, forms): Local useState
|
|
- Auth state: Context API
|
|
- App-wide settings: Simple global store
|
|
|
|
This reduces problem scope significantly.
|
|
Changes evaluation criteria.
|
|
Next: Re-evaluate with refined scope
|
|
|
|
Thought 4/6: Re-evaluation (adjusted)
|
|
|
|
Only need lightweight store for app-wide settings.
|
|
Zustand fits:
|
|
- Minimal boilerplate
|
|
- Excellent TypeScript support
|
|
- No provider wrapper
|
|
- ~1KB size
|
|
|
|
React Query handles server state (caching, refetch, offline).
|
|
Most state stays local.
|
|
|
|
Next: Verify this handles all requirements
|
|
|
|
Thought 5/6 [HYPOTHESIS]: Hybrid approach
|
|
|
|
Hypothesis: Zustand + React Query + local state solves needs.
|
|
|
|
- Zustand: Theme, user prefs, global UI flags
|
|
- React Query: All server data, caching, sync
|
|
- useState: Component-local UI
|
|
|
|
Benefits: Simple, performant, maintainable.
|
|
Uncertainty: Real-time updates?
|
|
|
|
Thought 6/6 [FINAL]: Verified solution
|
|
|
|
React Query supports WebSocket via custom hooks.
|
|
Zustand handles global UI simply.
|
|
Local state for component-specific needs.
|
|
|
|
Architecture decision:
|
|
- Zustand for global UI state
|
|
- React Query for all server interactions
|
|
- Local useState for component state
|
|
|
|
Confidence: High
|
|
Assumptions: Team comfortable with React Query patterns
|
|
Benefits: Simpler than Redux, more powerful than Context
|
|
Trade-offs: Learning curve for React Query (but worthwhile)
|
|
```
|
|
|
|
## Key Insights
|
|
|
|
1. **Scope revision crucial**: Original "need global state" reframed to specific state categories
|
|
2. **Separation of concerns**: Different state types need different solutions
|
|
3. **Hypothesis verification**: Confirmed WebSocket support before finalizing
|
|
4. **Simpler is better**: Avoided over-engineering with heavy Redux solution
|
|
|
|
## Impact of Revision
|
|
|
|
Without Thought 3 revision, might have chosen Redux for all state—significant over-engineering. Revision led to more appropriate, simpler solution.
|