9.1 KiB
9.1 KiB
Cleaner v1.11.1 之后更新内容改进计划
本文档基于 v1.11.1..v1.12.3 区间内已完成的前端审查结果整理而成，目标不是重复提交记录，而是为后续实现人员提供一份可以直接排期和落地的改进路线图。计划范围仅覆盖 Cleaner 相关前端改进，不扩展到主进程 DAO、IPC 或数据库结构重构。
1. 背景与范围
本计划覆盖 v1.11.1 之后到当前最新版本 v1.12.3 的 Cleaner 前端相关更新，重点关注以下变化：
- 新增 Cleaner 操作历史弹窗
- 用数据库持久化替代原有 Markdown 报告查看路径
- 为执行结果补充失败与不确定删除统计
- 引入
React.lazy和BatchItem拆分来降低页面负担
本次计划的核心目标是：
- 先修复当前历史弹窗与执行结果展示中的稳定性问题
- 再优化首屏加载和复杂列表交互性能
- 最后补齐长期可维护性和可扩展性基础
默认审查区间固定为 v1.11.1..v1.12.3，默认文档语言为中文，默认落点为 docs/plans/。
2. 当前状态总结
这轮更新已经做对了几件重要的事情：
- Cleaner 历史记录已经完成数据库化，前端不再依赖旧的 Markdown 报告浏览流
CleanerOperationHistoryModal被独立成单独组件，并通过BatchItem局部拆分降低兄弟节点联动重渲染CleanerPage已经开始使用React.lazy引入历史弹窗与执行报告相关组件ExecutionReportDialog已经补充materialsFailed和uncertainDeletions的展示能力
这些改动说明整体方向是正确的，但从 React 最佳实践和后续维护成本看，当前实现仍然存在几个明确的改进空间：异步缓存策略不够稳、按需加载没有完全生效、复杂列表的扩展能力有限、前端回归保护不足。
3. 主要改进项
P0 立刻修
3.1 修正历史详情与物料详情的缓存时机
问题：
- 当前历史批次详情和物料详情会在请求发起前就标记为“已加载”
- 如果首次请求失败，后续再次展开不会重试，用户会长期看到空详情或误导性空状态
目标：
- 只在请求成功后写入缓存
- 失败后允许再次展开重新请求
- 在 UI 上保留现有交互风格，不做视觉重设计
建议方向：
- 将详情加载状态拆成
idle / loading / success / error detailsLoadedRef和loadedMaterialsRef只在成功后更新- 对失败场景提供自然重试路径，优先采用“再次展开即重试”的方式
预期收益：
- 避免瞬时请求失败被错误地永久缓存
- 提高历史查看功能的稳定性和用户信任感
3.2 将 Cleaner 历史弹窗改成真正条件挂载
问题：
- 当前
CleanerPage虽然使用了React.lazy，但历史弹窗组件仍然会在页面渲染时被挂入树中 - 这会导致对应 chunk 仍在首屏阶段就被加载，未达到真正按需加载的效果
目标：
- 历史弹窗只在用户打开时才参与渲染和加载
- 避免进入 Cleaner 页面就提前下载历史功能代码
建议方向：
- 采用条件渲染而不是仅保留
isOpen控制 - 延续当前交互样式和打开方式，不调整页面布局
预期收益：
- 降低 Cleaner 页面的首屏负担
- 更符合
bundle-conditional类最佳实践
3.3 补最小前端回归测试
问题：
- 本轮新增了历史弹窗、异步详情展开和执行结果增强，但前端侧缺少对应测试保护
目标：
- 为关键行为建立最小可行回归测试
- 优先补组件/行为测试，不新增端到端测试要求
建议方向：
- 覆盖历史弹窗未打开时不触发懒加载模块请求
- 覆盖批次详情和物料详情首次失败后再次展开可重试
- 覆盖管理员筛选切换后请求参数与结果一致
预期收益：
- 降低后续修复和优化时的回归风险
- 为后续分页、交互优化提供安全网
P1 本周优化
3.4 为历史列表增加分页能力
问题：
- 当前历史列表和明细表格按全量数据渲染，随着批次数量、订单数量和物料数量增加，性能风险会上升
目标：
- 让历史列表在数据增长后仍保持可接受的打开和滚动体验
建议方向：
- 默认优先采用分页，不先引入虚拟列表库
- 先做批次列表分页，再评估是否需要对订单或物料明细做进一步优化
预期收益：
- 控制渲染体量
- 降低复杂列表在中等数据规模下的卡顿风险
3.5 管理员筛选切换使用 startTransition
问题：
- 管理员切换用户筛选时会立即触发批次列表刷新，后续数据量增长后可能影响点击反馈
目标：
- 保持筛选按钮点击响应流畅
- 将非紧急更新降级处理
建议方向：
- 将筛选触发的列表刷新包装到
startTransition - 保持现有筛选交互模型不变
预期收益：
- 降低筛选切换时的阻塞感
- 更符合 React 对非紧急更新的建议用法
3.6 收敛重复派生计算
问题：
- 当前实现中存在多处基于
orders和currentAttempt的重复filter/map - 数据规模扩大后，这些重复遍历会逐步放大渲染成本
目标：
- 让渲染中的数据派生更集中、更可读
建议方向：
- 将当前 attempt 对应订单集合收敛成单一派生结果
- 复制列内容等行为复用同一份派生数据
预期收益：
- 降低不必要的重复计算
- 让
BatchItem的渲染路径更容易维护
3.7 优化执行报告的结果语义
问题：
- 当前执行报告的标题和成功态仍主要依赖
errors - 当存在
materialsFailed或uncertainDeletions时，结果表达仍可能显得过于乐观
目标：
- 让执行结果清楚区分成功、部分成功、失败、需人工确认
建议方向：
- 重新定义结果态判定优先级
- 在不重做 UI 视觉设计的前提下，优化标题、说明文案和结果提示条
预期收益：
- 降低误判执行结果的风险
- 让失败和不确定删除场景更容易被用户注意到
P2 后续演进
3.8 统一状态映射定义
问题：
- 当前状态的 label、icon、style 已有集中趋势，但仍是组件内局部定义
- 后续新增状态时容易出现展示不一致
目标：
- 用统一的受类型约束的映射管理状态展示
建议方向：
- 抽离共享状态映射
- 覆盖 batch、execution、order、material 这几类状态展示
预期收益：
- 降低重复定义
- 提高新增状态时的一致性和可维护性
3.9 补无障碍语义
问题：
- 当前批次展开和订单展开更多依赖点击容器，语义和键盘可达性还有提升空间
目标：
- 让复杂历史弹窗具备更清晰的交互语义
建议方向：
- 使用真实按钮作为展开触发器
- 增加
aria-expanded、aria-controls等属性
预期收益：
- 提升键盘交互和屏幕阅读器兼容性
- 为后续复杂交互维护提供更稳定语义基础
3.10 规划历史查询的扩展能力
问题：
- 当前查询能力主要围绕固定数量批次列表和基础筛选
- 如果历史功能继续增强，前端会越来越依赖更丰富的查询条件
目标：
- 为后续历史功能演进预留明确方向
建议方向：
- 预留时间范围筛选
- 预留状态筛选
- 延续服务端分页方向，而不是继续扩大前端一次性加载量
预期收益：
- 让后续功能迭代有稳定扩展路径
- 避免复杂度持续堆积在当前单一弹窗实现中
4. 推荐执行顺序
建议按以下顺序推进：
- 先修
P0，优先处理缓存时机错误和按需加载未完全生效的问题 - 在
P0修复完成后补最小前端回归测试，锁住关键行为 - 再做
P1，先分页，再处理startTransition和重复派生计算 - 最后进入
P2，统一状态映射、补无障碍语义，并规划历史查询扩展能力
这个顺序的原则是：先修稳定性，再做性能，再做长期演进。
5. 完成标准
本计划相关改进完成后，至少应满足以下验收标准：
- 历史弹窗未打开时，不触发对应懒加载模块请求
- 批次详情或物料详情首次请求失败后，用户再次展开可重新请求
- 用户筛选切换后，列表数据与筛选条件一致
- 执行报告在存在
materialsFailed或uncertainDeletions时，不再展示为完全成功 npm run typecheck通过- 相关前端测试通过
- Cleaner 页面关键路径手工验证通过，包括：
- 打开历史弹窗
- 展开批次详情
- 展开订单物料详情
- 切换管理员筛选
- 查看执行结果提示
6. 默认方案与实施约束
为避免后续实现阶段再次做不必要决策，本计划固定以下默认方案：
- 历史列表优先采用分页，不先引入虚拟列表库
- 历史弹窗继续保留现有交互样式，不做视觉重设计
- 测试优先补组件/行为测试，不新增端到端测试要求
- 本计划只覆盖 Cleaner 相关前端改进，不扩展到主进程 DAO、IPC、数据库结构重构
如果后续版本继续围绕 Cleaner 历史功能扩展，可以在本计划基础上继续追加更细的实施文档，但不应改变本计划中 P0 / P1 / P2 的优先级顺序。