React Patterns (Deep Workflow)
Healthy React codebases emphasize clear data flow, minimal effects, and predictable rendering. Prefer composition over inheritance; treat effects as synchronization, not “do something after render” for everything.
When to Offer This Workflow
Trigger conditions:
- - Prop drilling vs context vs external stores; confusion on server components (Next) vs client
- useEffect spaghetti; stale closures; double-fetch
- Re-render performance; large lists; hydration issues
Initial offer:
Use six stages: (1) structure & boundaries, (2) state & data sources, (3) hooks discipline, (4) effects & events, (5) performance, (6) testing & a11y). Confirm React version and framework (plain CRA, Vite, Next App Router).
Stage 1: Structure & Boundaries
Goal: Colocate state; split presentational vs container only when it clarifies—not by default.
Practices
- - Compound components for flexible APIs; avoid mega-props objects
- In Next App Router: default to Server Components; add
use client at leaves
Stage 2: State & Data Sources
Goal: Local state for UI; server state via React Query/SWR/Apollo as appropriate; avoid duplicating server entities in global stores without sync rules.
Stage 3: Hooks Discipline
Goal: Rules of Hooks satisfied; custom hooks encapsulate reusable stateful logic with clear inputs/outputs.
Practices
- - Name hooks
useThing; return stable APIs (objects memoized when needed)
Stage 4: Effects & Events
Goal: Prefer event handlers for user-driven work; useEffect for sync with external systems (subscriptions, non-React widgets).
Practices
- - Cleanup subscriptions; abort fetches; list effect dependencies honestly
- Strict Mode double-invoke in dev—write effects idempotent
Stage 5: Performance
Goal: Measure before memo; virtualize long lists; code-split routes.
Practices
- -
useCallback/useMemo when profiling shows benefit—not by default - Concurrent features and Suspense boundaries where supported
Stage 6: Testing & Accessibility
Goal: React Testing Library user-centric queries; focus management and labels for forms.
Final Review Checklist
- - [ ] Component boundaries match data ownership
- [ ] Server vs client state strategy clear
- [ ] Hooks and effects used appropriately
- [ ] Performance optimizations evidence-based
- [ ] Tests and a11y basics covered for critical flows
Tips for Effective Guidance
- - Derive state when possible instead of storing redundant pieces.
- URL as state for shareable UI state when appropriate.
- Point to state-management skill for Redux/Zustand-scale decisions.
Handling Deviations
- - Legacy class components: same principles; hooks migration incremental.
React 模式(深度工作流)
健康的 React 代码库强调清晰的数据流、最小化的副作用和可预测的渲染。优先使用组合而非继承;将副作用视为同步机制,而非渲染后做某事的万能方案。
何时提供此工作流
触发条件:
- - Props 逐层传递 vs Context vs 外部存储;对(Next 的)服务端组件与客户端的混淆
- useEffect 混乱;闭包过时;重复请求
- 重渲染性能问题;大型列表;水合问题
初始建议:
使用六个阶段:(1)结构与边界、(2)状态与数据源、(3)Hooks 规范、(4)副作用与事件、(5)性能优化、(6)测试与无障碍。确认 React 版本和框架(普通 CRA、Vite、Next App Router)。
阶段 1:结构与边界
目标: 就近放置状态;仅在有助于清晰化时拆分展示型与容器型组件——而非默认拆分。
实践
- - 使用复合组件实现灵活 API;避免巨型 props 对象
- 在 Next App Router 中:默认使用服务端组件;在叶子节点添加 use client
阶段 2:状态与数据源
目标: UI 使用本地状态;服务端状态通过 React Query/SWR/Apollo 等工具管理;避免在全局存储中复制服务端实体而不建立同步规则。
阶段 3:Hooks 规范
目标: 满足 Hooks 规则;自定义 Hook 封装可复用的有状态逻辑,具有清晰的输入/输出。
实践
- - 命名 Hook 为 useThing;返回稳定的 API(必要时对对象进行记忆化)
阶段 4:副作用与事件
目标: 用户驱动的工作优先使用事件处理函数;与外部系统(订阅、非 React 组件)同步时使用 useEffect。
实践
- - 清理订阅;中止请求;诚实列出副作用依赖
- 开发模式下严格模式会双重调用——编写幂等的副作用
阶段 5:性能优化
目标: 在使用 memo 前先测量;虚拟化长列表;代码分割路由。
实践
- - 仅在性能分析显示收益时使用 useCallback/useMemo——而非默认使用
- 在支持的地方使用并发特性和 Suspense 边界
阶段 6:测试与无障碍
目标: 使用 React Testing Library 进行以用户为中心的查询;管理焦点和表单标签。
最终审查清单
- - [ ] 组件边界与数据所有权匹配
- [ ] 服务端与客户端状态策略清晰
- [ ] Hooks 和副作用使用得当
- [ ] 性能优化基于证据
- [ ] 关键流程的测试和无障碍基础覆盖
有效指导技巧
- - 尽可能推导状态,而非存储冗余数据
- 适当情况下将 URL 作为可共享 UI 状态
- 对于 Redux/Zustand 级别的决策,指向状态管理技能
处理偏差
- - 遗留类组件: 相同原则;逐步迁移到 Hooks