ADR-008: 状态管理优先 React hooks 与 reducer

[ceilf6]

决策

P0 状态管理优先使用 React hooks、context 和 reducer。只有当跨模块共享状态明显复杂时，再引入 Zustand。

备选方案

• React 内置状态。
• Zustand。
• Redux Toolkit。
• XState。

理由

P0 核心复杂度在录制时钟、事件模型和回放调度，不在全局状态库。先用 reducer 能保持实现轻量。Redux/XState 会增加样板代码；Zustand 可以作为后续低成本增强。

影响

录制控制器和回放调度器应封装为独立模块，React 状态只承载 UI 投影，避免业务逻辑散落在组件里。

[yangchloeeeee]

支持。P0 的难点在录制时钟、事件流、快照 seek 和回放调度，不在状态库。先用 hooks、context 和 reducer 更轻量。

建议补充一个边界：React 状态只做 UI 投影，核心逻辑要放在框架无关模块里。比如 RecordingClock、EventBus、RecordingController、ReplayScheduler、ReplayReducer 都应该是独立可测模块，组件只订阅状态、触发命令。

这样后续如果 P1 引入 Zustand，也只是替换 UI 状态容器，不会重写核心业务逻辑。Zustand 可以在跨页面/跨模块共享状态明显增多、context 层级过深、多个面板频繁订阅同一状态时再引入。

Redux Toolkit 和 XState 暂时不建议进入 P0。XState 对状态机表达力强，但接入和学习成本会影响交付节奏。

[Suxian2001]

支持。另外几个状态管理方案区分一下责任边界更好

[ceilf6]

支持。另外几个状态管理方案区分一下责任边界更好

• hooks 做一般 UI 状态映射，像 loading 态等等
• 低频、跨局部组件树共享的上下文用 Context
• 局部但状态转移明确的 UI/流程状态用 Reducer
• 在跨模块共享导致逻辑复杂的状态变量纳入 Zustand（ Redux 还是太重了，应该是不会引入的，并且咱们项目应该不会有用到 Redux 的地方 Pinia VS Vuex）