# Proposal: 集成典型案例查询API数据展示

## Change ID
`integrate-typical-case-api`

## 概述
修改`CaseSearchContent.jsx`和`TypicalCaseDetailContent.jsx`组件，集成`CaseAPIService`的多个API调用，实现典型案例查询、筛选、列表展示和详情查看的完整功能。重构查询条件布局，支持案例类型切换联动，并根据不同案例类型（调解案例/判决文书）展示对应的数据和详情内容。

## 动机
当前"典型案例查询"功能使用的是静态mock数据和硬编码的筛选条件，无法提供真实的案例检索服务。需要集成后端API实现：
1. **动态查询条件**：支持案例类型切换，联动加载纠纷类型、发生时间、纠纷发生地筛选数据
2. **真实数据展示**：根据查询条件获取调解案例或判决文书列表
3. **分类详情展示**：点击案例时根据类型展示不同的详情内容和字段映射
4. **优化用户体验**：改进查询表单布局，提供Loading状态和错误处理机制

## 影响范围

### 修改文件
- `web-app/src/components/tools/CaseSearchContent.jsx` - 重构查询条件、集成API调用和动态数据渲染
- `web-app/src/components/tools/TypicalCaseDetailContent.jsx` - 根据案例类型展示不同详情内容
- `web-app/src/components/tools/TypicalCaseSearch.css` - 新增关键词全宽样式

### 使用API
- `CaseAPIService.getDisputeTypes(caseSource)` - 获取纠纷类型下拉数据
- `CaseAPIService.getYearStatistics()` - 获取判决文书年份统计
- `CaseAPIService.getMediationYearStatistics()` - 获取调解案例年份统计
- `CaseAPIService.getAreaStatistics(caseSource)` - 获取纠纷发生地统计
- `CaseAPIService.getCourtCases(params)` - 查询判决文书列表
- `CaseAPIService.getMediationCases(params)` - 查询调解案例列表
- `CaseAPIService.getCourtCaseDetail(id)` - 获取判决文书详情
- `CaseAPIService.getMediationCaseDetail(id)` - 获取调解案例详情

## 用户故事

### 作为调解员
- **我想要**：通过案例类型切换按钮选择查询调解案例或判决文书
- **以便于**：快速定位到我需要的案例类型

### 作为调解员
- **我想要**：选择案例类型后，纠纷类型、发生时间、发生地等筛选条件自动加载对应数据
- **以便于**：根据实际数据分布进行精确筛选

### 作为调解员
- **我想要**：点击案例时能看到完整的案例详情，且调解案例和判决文书显示不同的字段
- **以便于**：获取针对不同案例类型的关键信息

## 关键技术决策

### 1. 查询条件布局重构
**变更内容**：
- 移除：纠纷发生时间RangePicker组件、案例类型筛选卡片
- 新增：案例类型单选按钮组（判决文书/调解案例），默认选中"判决文书"
- 调整：关键词拉长占满第一行，第二行显示案例类型+纠纷类型+查询/重置按钮

**理由**：
- 简化查询界面，主要筛选条件（发生时间、发生地）使用树形卡片更直观
- 案例类型作为核心切换维度，使用单选按钮组更符合交互习惯
- 避免表单组件过多导致的视觉混乱

### 2. 案例类型切换联动策略
**实现方案**：使用`useEffect`监听`caseType`变化，自动触发三个API调用
```javascript
useEffect(() => {
  const caseSource = caseType === 'judgment' ? 'judgment' : 'mediation';
  loadDisputeTypes(caseSource);      // 纠纷类型下拉框
  loadYearStatistics();               // 发生时间树形卡片
  loadAreaStatistics(caseSource);     // 纠纷发生地树形卡片
}, [caseType]);
```

**理由**：
- 确保筛选数据与案例类型保持一致
- 自动化联动减少用户操作，提升体验

### 3. 数据字段映射策略
**调解案例字段映射**：
```javascript
{
  标题: case_title,
  发生时间: occur_time (格式化为 YYYY年MM月DD日),
  发生地点: que_prov_name + "/" + que_city_name,
  纠纷类型: case_type_first_name,
  案例类型: "调解案例",
  id: id
}
```

**判决文书字段映射**：
```javascript
{
  标题: case_name,
  发生时间: judgment_date (格式化为 YYYY年MM月DD日),
  发生地点: court,
  纠纷类型: case_reason,
  案例类型: "判决文书",
  id: cpws_case_info_id
}
```

**理由**：
- API返回的字段名称不同，需要适配
- 日期统一格式化为"YYYY年MM月DD日"提升可读性

### 4. 详情内容分类展示策略
**调解案例详情展示**：
- 弹窗标题：典型案例详情
- 第一行：案件标题（case_title）
- 第二行：纠纷发生时间（occur_time）、发生地点（que_prov_name/que_city_name）、纠纷类型（case_type_first_name）
- 移除：调解组织字段
- 详情内容：仅显示案例概述（case_des）、原告诉讼请求（case_claim）、调解结果（agree_content）

**判决文书详情展示**：
- 弹窗标题：判决文书详情
- 第一行：案件标题（case_name）、案号（case_number）
- 第二行：判决日期（judgment_date）、发生地点（court）、纠纷类型（case_reason）
- 详情内容：案例概述（basic_case_info）、原告介绍（plaintiff）、被告介绍（defendant）、法院审理与判决（trial_finding）、审理经过（trial_process）、审理程序（trial_procedure）、调解结果（judgment）、案例相关法律条文（legal_basis）
- 移除：调解背景、双方立场

**理由**：
- 调解案例和判决文书的数据结构和关注点不同
- 精简调解案例详情，突出核心信息
- 判决文书详情更完整，满足专业用户需求

### 5. 错误处理策略
- API调用失败时显示友好的错误提示（使用message.error）
- 控制台输出详细错误信息供调试
- 不使用mock数据作为降级方案

## 数据流设计

```
用户打开典型案例查询弹窗
  ↓
组件挂载，默认案例类型=judgment
  ↓
并行调用三个API加载筛选数据
  ├─ getDisputeTypes('judgment')
  ├─ getYearStatistics()
  └─ getAreaStatistics('judgment')
  ↓
首次加载：调用getCourtCases获取列表数据
  ↓
用户切换案例类型为mediation
  ↓
重新加载筛选数据
  ├─ getDisputeTypes('mediation')
  ├─ getMediationYearStatistics()
  └─ getAreaStatistics('mediation')
  ↓
用户选择筛选条件，点击查询
  ↓
根据案例类型调用对应API
  ├─ judgment → getCourtCases
  └─ mediation → getMediationCases
  ↓
展示列表数据（根据案例类型映射字段）
  ↓
用户点击某个案例
  ↓
根据案例类型调用详情API
  ├─ judgment → getCourtCaseDetail
  └─ mediation → getMediationCaseDetail
  ↓
弹窗展示详情（根据案例类型显示不同内容）
```

## 非目标
- 本次不添加案例收藏功能
- 本次不实现案例对比功能
- 本次不处理案例详情的导出或打印
- 本次不修改分页组件样式
- 本次不添加高级搜索功能（如全文检索）

## 依赖关系
- ✅ CaseAPIService所有方法已存在（已在d:\cmw\work_space\hejiu_dev\cloud-melody-front\web-app\src\services\CaseAPIService.js中定义）
- ✅ 现有CaseSearchContent和TypicalCaseDetailContent UI结构可复用
- ✅ Ant Design组件库支持Radio.Group

## 验收标准
1. ✅ 查询条件布局符合需求：第一行关键词，第二行案例类型+纠纷类型+按钮
2. ✅ 移除纠纷发生时间RangePicker和案例类型筛选卡片
3. ✅ 切换案例类型时，纠纷类型、发生时间、发生地数据自动重新加载
4. ✅ 首次打开弹窗时默认加载判决文书列表数据
5. ✅ 点击查询时根据案例类型调用正确的API
6. ✅ 列表数据根据案例类型正确映射字段显示
7. ✅ 日期时间格式化为"YYYY年MM月DD日"
8. ✅ 点击案例时根据类型调用正确的详情API
9. ✅ 调解案例详情弹窗标题为"典型案例详情"，显示指定字段
10. ✅ 判决文书详情弹窗标题为"判决文书详情"，显示指定字段
11. ✅ API调用过程中显示Loading状态
12. ✅ API调用失败时显示错误提示
13. ✅ 分页功能正常工作，使用API返回的total和size计算

## 风险评估
- **中等风险**：涉及多个API集成和复杂的字段映射逻辑
- **测试重点**：案例类型切换联动、字段映射正确性、详情分类展示、错误处理机制
- **兼容性风险**：需确保API返回数据结构符合预期，建议添加数据验证

## 时间估算
- 开发时间：4-5小时
- 测试时间：2小时
- 总计：6-7小时