Break down 948-line monolithic component into 11 focused modules following Vercel React best practices: **Module Structure:** - types.ts: Centralized type definitions and constants - hooks/: Custom hooks for data management (useReportData, useChartData, useReportFilters) - components/: Reusable UI components (MetricSelector, ViewModeToggle, UserFilter, ReportChart, Tooltips) - utils/: Parser and aggregator utility functions **Key Improvements:** - Reduced main component from 948 to ~200 lines (79% reduction) - Separated concerns: data fetching, state management, and UI rendering - Enhanced reusability and testability of individual components - Maintained backward compatibility with existing imports **Additional Fixes:** - Fixed tooltip displaying duplicate average time values - Formatted time values to 1 decimal place in both views - Removed redundant time display from tooltip footer **Performance Optimizations Applied:** - Moved tooltip components outside parent component (rerender-no-inline-components) - Hoisted regex pattern creation outside loops (js-hoist-regexp) - Used functional setState updates (rerender-functional-setState) - Memoized expensive computations and callbacks All changes maintain existing functionality while improving code quality and maintainability. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
213 lines
5.7 KiB
Markdown
213 lines
5.7 KiB
Markdown
# ReportAnalysisDialog 组件重构分析
|
||
|
||
## 📊 当前状态分析
|
||
|
||
### 基本指标
|
||
|
||
- **总行数**: 948 行
|
||
- **函数/声明**: 9 个
|
||
- **React Hooks**: 20 个使用
|
||
- **职责数量**: 5+ 个主要职责
|
||
|
||
### 组件职责分析
|
||
|
||
#### 1. 数据获取与解析 (~150 行)
|
||
|
||
- `loadAndAnalyzeReports` - 数据加载逻辑
|
||
- `extractReportValues` - 报告内容解析
|
||
- `parseDurationToSeconds` - 时间解析
|
||
|
||
#### 2. 数据聚合与转换 (~200 行)
|
||
|
||
- `chartData` useMemo - 按日期聚合
|
||
- `comparisonData` useMemo - 按用户聚合
|
||
- `comparisonChartData` useMemo - 图表数据格式化
|
||
- `allUsers` useMemo - 用户列表提取
|
||
|
||
#### 3. 状态管理 (~100 行)
|
||
|
||
- 6 个 useState hooks
|
||
- 5 个 useCallback handlers
|
||
- 复杂的状态交互逻辑
|
||
|
||
#### 4. UI 控制与交互 (~200 行)
|
||
|
||
- 指标选择按钮
|
||
- 视图模式切换
|
||
- 用户筛选器
|
||
- 加载/错误状态显示
|
||
|
||
#### 5. 图表渲染 (~300 行)
|
||
|
||
- Recharts 图表配置
|
||
- 两个不同的视图模式
|
||
- 自定义 Tooltip 组件
|
||
- 图表样式和布局
|
||
|
||
## 🎯 重构目标
|
||
|
||
### 主要问题
|
||
|
||
1. **单一文件过大**: 难以维护和理解
|
||
2. **职责混乱**: 数据获取、处理、UI 混在一起
|
||
3. **复用性差**: 逻辑和 UI 紧耦合
|
||
4. **测试困难**: 难以单独测试各个部分
|
||
|
||
### 重构原则
|
||
|
||
1. **单一职责**: 每个模块只负责一件事
|
||
2. **可复用性**: 提取通用逻辑到 hooks
|
||
3. **可测试性**: 分离逻辑和 UI
|
||
4. **可维护性**: 清晰的文件结构
|
||
|
||
## 📦 建议的文件结构
|
||
|
||
```
|
||
src/renderer/src/components/report-analysis/
|
||
├── index.tsx # 主组件入口 (~150 行)
|
||
├── hooks/
|
||
│ ├── useReportData.ts # 数据获取和解析 (~100 行)
|
||
│ ├── useChartData.ts # 数据聚合和转换 (~150 行)
|
||
│ └── useReportFilters.ts # 筛选状态管理 (~80 行)
|
||
├── components/
|
||
│ ├── ReportChart.tsx # 图表组件 (~200 行)
|
||
│ ├── MetricSelector.tsx # 指标选择器 (~80 行)
|
||
│ ├── ViewModeToggle.tsx # 视图模式切换 (~50 行)
|
||
│ ├── UserFilter.tsx # 用户筛选器 (~100 行)
|
||
│ ├── CustomTooltip.tsx # 自定义 tooltip (~100 行)
|
||
│ ├── ComparisonTooltip.tsx # 对比 tooltip (~80 行)
|
||
│ └── LoadingState.tsx # 加载状态组件 (~60 行)
|
||
├── utils/
|
||
│ ├── parser.ts # 报告解析工具 (~100 行)
|
||
│ ├── aggregators.ts # 数据聚合函数 (~120 行)
|
||
│ └── formatters.ts # 格式化工具 (~60 行)
|
||
└── types.ts # 类型定义 (~80 行)
|
||
```
|
||
|
||
## 🔧 重构方案
|
||
|
||
### 方案 A: 完全重构 (推荐)
|
||
|
||
**优点**: 最大程度的解耦和可维护性
|
||
**缺点**: 需要更多时间,可能引入新问题
|
||
**时间估计**: 2-3 小时
|
||
|
||
### 方案 B: 渐进式重构
|
||
|
||
**优点**: 风险较低,可以逐步验证
|
||
**缺点**: 过渡期代码可能不够优雅
|
||
**时间估计**: 1-2 小时
|
||
|
||
### 方案 C: 最小化重构
|
||
|
||
**优点**: 改动最小,风险最低
|
||
**缺点**: 解决根本问题有限
|
||
**时间估计**: 30-45 分钟
|
||
|
||
## 📝 详细重构步骤
|
||
|
||
### Phase 1: 提取类型和工具函数 (低风险)
|
||
|
||
1. 创建 `types.ts` - 集中管理所有类型定义
|
||
2. 创建 `utils/parser.ts` - 提取报告解析逻辑
|
||
3. 创建 `utils/aggregators.ts` - 提取数据聚合逻辑
|
||
|
||
### Phase 2: 提取自定义 Hooks (中风险)
|
||
|
||
1. 创建 `hooks/useReportData.ts` - 数据获取和解析
|
||
2. 创建 `hooks/useChartData.ts` - 数据聚合和转换
|
||
3. 创建 `hooks/useReportFilters.ts` - 筛选状态管理
|
||
|
||
### Phase 3: 提取 UI 组件 (中风险)
|
||
|
||
1. 创建 `components/MetricSelector.tsx`
|
||
2. 创建 `components/ViewModeToggle.tsx`
|
||
3. 创建 `components/UserFilter.tsx`
|
||
4. 创建 `components/ReportChart.tsx`
|
||
|
||
### Phase 4: 重构主组件 (高风险)
|
||
|
||
1. 简化 `index.tsx` 只保留组合逻辑
|
||
2. 添加错误边界
|
||
3. 优化加载状态
|
||
|
||
## 🎯 重构后的预期效果
|
||
|
||
### 代码行数分布
|
||
|
||
- 主组件: ~150 行 (减少 84%)
|
||
- 每个 hook: ~80-150 行
|
||
- 每个 UI 组件: ~50-200 行
|
||
- 工具函数: ~60-120 行
|
||
|
||
### 可维护性提升
|
||
|
||
- ✅ 单个文件更小,更易理解
|
||
- ✅ 职责清晰,修改影响范围小
|
||
- ✅ 更容易进行单元测试
|
||
- ✅ 可以独立优化各个部分
|
||
|
||
### 性能影响
|
||
|
||
- ➡️ 性能基本不变或略有提升
|
||
- ➡️ 代码分割优化可能略微改善首次加载
|
||
- ➡️ 更好的 memoization 机会
|
||
|
||
## 🚨 风险评估
|
||
|
||
### 高风险区域
|
||
|
||
- 图表配置逻辑(Recharts 配置复杂)
|
||
- 数据转换和聚合(业务逻辑密集)
|
||
- 状态同步(多个状态之间的交互)
|
||
|
||
### 缓解措施
|
||
|
||
- 保持现有测试通过
|
||
- 逐步重构,每步验证
|
||
- 添加 TypeScript 严格检查
|
||
- 保留原有功能注释
|
||
|
||
## 📋 验证清单
|
||
|
||
重构完成后需要验证:
|
||
|
||
- [ ] 所有现有功能正常工作
|
||
- [ ] 单元测试通过
|
||
- [ ] E2E 测试通过
|
||
- [ ] 类型检查无错误
|
||
- [ ] 性能无明显下降
|
||
- [ ] 代码风格符合规范
|
||
|
||
## 🤔 建议的实施顺序
|
||
|
||
### 推荐方案: 渐进式重构 (方案 B)
|
||
|
||
**第1步**: 提取类型和工具函数 (15分钟)
|
||
|
||
- 创建类型定义文件
|
||
- 提取解析工具函数
|
||
- 验证编译和测试
|
||
|
||
**第2步**: 提取自定义 Hooks (30分钟)
|
||
|
||
- 提取数据获取逻辑
|
||
- 提取数据聚合逻辑
|
||
- 提取筛选状态管理
|
||
- 验证功能正常
|
||
|
||
**第3步**: 提取 UI 组件 (30分钟)
|
||
|
||
- 提取控制面板组件
|
||
- 提取图表组件
|
||
- 提取状态显示组件
|
||
- 验证交互正常
|
||
|
||
**第4步**: 简化主组件 (15分钟)
|
||
|
||
- 重构为组合式组件
|
||
- 清理代码和注释
|
||
- 最终验证
|
||
|
||
**总计**: 约 90 分钟,分4个阶段,每个阶段都可以独立验证
|