2.6 KiB
2.6 KiB
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
- Scope revision crucial: Original "need global state" reframed to specific state categories
- Separation of concerns: Different state types need different solutions
- Hypothesis verification: Confirmed WebSocket support before finalizing
- 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.