60 lines
4.0 KiB
Markdown
60 lines
4.0 KiB
Markdown
|
# 搜索结果页 (SearchResultView) 重构方案提案
|
|||
|
|
|
|||
|
|
**项目ID:** shihuashishuo-ui
|
|||
|
|
**任务:** 重构 `shihuashishuo-ui/src/views/核心体验页/SearchResultView-搜索结果页.vue`
|
|||
|
|
**阶段:** 创新 (INNOVATE)
|
|||
|
|
**创建者:** AR/LD
|
|||
|
|
**时间:** 2025-07-25
|
|||
|
|
|
|||
|
|
## 1. 背景
|
|||
|
|
|
|||
|
|
`SearchResultView-搜索结果页.vue` 文件已超过900行，将UI布局、业务逻辑、多种不同类型的数据展示（预包装、添加剂、食材等）全部耦合在一起。这严重违反了单一职责原则，导致可维护性差、复用性低，并存在潜在的性能问题。
|
|||
|
|
|
|||
|
|
## 2. 候选解决方案
|
|||
|
|
|
|||
|
|
### 方案 1: 基础组件化 (按列表拆分)
|
|||
|
|
|
|||
|
|
* **核心思想:** 将每个Tab对应的内容区域拆分为独立的列表组件。
|
|||
|
|
* **组件结构:**
|
|||
|
|
* `SearchResultView.vue` (父组件/容器):
|
|||
|
|
* **职责:** 保留页面顶部的搜索栏、Tab导航和筛选器。管理所有共享状态（如 `activeTab`、筛选条件）和业务逻辑（如 `performSearch`、`confirmFilters`）。根据 `activeTab` 动态加载下方的子组件。
|
|||
|
|
* `components/SearchResult/PrepackagedList.vue`:
|
|||
|
|
* **职责:** 接收“预包装”食品的数据数组作为prop，并渲染其列表。
|
|||
|
|
* `components/SearchResult/AdditiveList.vue`:
|
|||
|
|
* **职责:** 接收“添加剂”的数据数组作为prop，并渲染其列表。
|
|||
|
|
* `components/SearchResult/MaterialList.vue`:
|
|||
|
|
* **职责:** 接收“食材”的数据数组作为prop，并渲染其列表。
|
|||
|
|
* *(其他列表组件以此类推...)*
|
|||
|
|
* **优点:**
|
|||
|
|
* 实现相对简单快捷，能快速解决主文件过长的问题。
|
|||
|
|
* 模板逻辑被有效分离，提高了可维护性。
|
|||
|
|
* **缺点:**
|
|||
|
|
* 结果卡片（Card）的UI和逻辑仍然耦合在各自的列表组件中，未能实现最大化复用。
|
|||
|
|
|
|||
|
|
### 方案 2: 深度组件化 (按列表和卡片拆分) - 【推荐】
|
|||
|
|
|
|||
|
|
* **核心思想:** 在方案1的基础上，将可复用的“结果卡片”也抽取为独立的组件。
|
|||
|
|
* **组件结构:**
|
|||
|
|
* **视图层 (View):**
|
|||
|
|
* `SearchResultView.vue`: 职责与方案1相同，作为容器和逻辑控制器。
|
|||
|
|
* **列表组件 (List Components):**
|
|||
|
|
* `components/SearchResult/PrepackagedList.vue`: 接收数据数组，循环渲染 `PrepackagedCard.vue` 组件。
|
|||
|
|
* `components/SearchResult/AdditiveList.vue`: 接收数据数组，循环渲染 `AdditiveCard.vue` 组件。
|
|||
|
|
* *(...其他列表组件)*
|
|||
|
|
* **卡片组件 (Card Components):**
|
|||
|
|
* `components/SearchResult/PrepackagedCard.vue`: 接收**单个**“预包装”食品对象作为prop，负责该卡片的全部UI展示。
|
|||
|
|
* `components/SearchResult/AdditiveCard.vue`: 接收**单个**“添加剂”对象作为prop，负责其UI展示。
|
|||
|
|
* `components/SearchResult/MaterialCard.vue`: 接收**单个**“食材”对象作为prop，负责其UI展示。
|
|||
|
|
* `components/SearchResult/SummaryCard.vue`: 一个通用的摘要卡片，可用于“食谱”和“资讯”。
|
|||
|
|
* **优点:**
|
|||
|
|
* **极致的复用性:** 卡片组件（如 `PrepackagedCard`）成为独立的UI单元，未来可在任何需要展示此信息的地方复用（如首页推荐、用户收藏列表等）。
|
|||
|
|
* **严格的单一职责:** 每个组件的职责都非常清晰。视图管布局和逻辑，列表管循环，卡片管展示。
|
|||
|
|
* **最佳的可维护性与可扩展性:** 修改卡片样式只需编辑对应的小文件，影响范围可控。未来新增结果类型也只需创建新的列表和卡片组件，对现有代码无侵入。
|
|||
|
|
* **缺点:**
|
|||
|
|
* 初始创建的文件数量较多。
|
|||
|
|
|
|||
|
|
## 3. 结论与建议
|
|||
|
|
|
|||
|
|
作为架构师和首席开发，我**强烈推荐采用方案2：深度组件化**。
|
|||
|
|
|
|||
|
|
虽然该方案的初始工作量略高，但它带来的高内聚、低耦合的架构优势是巨大的。这不仅是对当前代码质量的提升，更是对项目未来可维护性和团队协作效率的长期投资。它完全符合现代前端工程化的最佳实践。
|