edit | blame | history | raw

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

Change ID

integrate-typical-case-api

概述

修改CaseSearchContent.jsxTypicalCaseDetailContent.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小时