第 41 课：任务详情抽屉里的快速筛选联动

第 41 课：任务详情抽屉里的快速筛选联动

这一课我们继续沿着"任务管理页主线"往前推，把已经具备：

• 查看详情
• 快捷改状态
• 上一条 / 下一条切换
• 编辑 / 删除联动

这些能力的 任务详情抽屉 再往真实后台推进一步。

这次要补的是一个很常见、也很实用的后台能力：

• 从详情抽屉里直接 只看同状态
• 从详情抽屉里直接 只看同优先级

同时还要保证：

• 列表筛选状态立刻变化
• 地址栏查询参数同步更新
• 当前详情任务上下文不丢
• 位置摘要跟着筛选结果重新计算
• 刷新后还能一起恢复

---

这一课一句话在做什么？

这一课本质上是在做：

让任务详情抽屉不只是"看当前一条"，而是能直接把当前任务变成"继续处理同类任务"的入口。

也就是说，用户在抽屉里看某条任务时，不需要先关掉抽屉，再去筛选栏重新操作。

而是可以直接说：

• 我想继续看和它同状态的任务
• 我想继续看和它同优先级的任务

这就是典型的后台工作台体验：

当前详情上下文，可以直接转成下一步列表处理上下文。

---

为什么这个能力很像真实后台？

因为真实后台里，用户很少是"只处理一条就结束"。

更常见的是：

1. 先打开一条任务详情
2. 理解这条任务当前处于什么阶段
3. 发现自己接下来想继续看同一批类型的任务
4. 于是直接进入同状态或同优先级的任务子集

例如：

• 看完一条 待开始 任务后，想继续处理其他 待开始 任务
• 看完一条 高优先级 任务后，想继续处理其他 高优先级 任务

如果这时还要：

• 先关详情
• 再回筛选栏手动点状态
• 再点优先级

会很打断节奏。

所以这节课做的其实不是"多两个按钮"。

而是在做：

把当前任务详情，变成列表工作流里的快捷入口。

---

这节课最关键的设计结论

1. 详情抽屉可以发起动作，但不直接改列表状态

这一课里，TaskDetailDrawer.vue 新增了两个事件：

• filter-status
• filter-priority

它只负责告诉父组件：

• 用户想看当前任务同状态的任务
• 用户想看当前任务同优先级的任务

但它自己不直接修改：

• statusFilter
• priorityFilter
• currentPage
• URL query

这说明一个很重要的分层原则：

展示层可以发起"意图"，但跨区域的真实状态协调仍然应该交给页面层。

2. 页面层负责统一协调"筛选 + 分页 + 详情上下文 + 提示文案"

这一课真正的联动逻辑仍然放在：

• src/views/TasksView.vue

页面层做了两件事：

1. 把状态筛选或优先级筛选改成当前任务对应的值
2. 主动把页码回到第 1 页

为什么要放在页面层？

因为这一步涉及的是多块区域同时变化：

• 顶部筛选栏
• 分页状态
• 详情抽屉位置摘要
• 地址栏 query
• 页面提示文案

这已经不是某一个组件自己的事情了。

3. 当前详情任务不应该因为"快速筛选"而丢失

这一课里点击：

• 只看同状态
• 只看同优先级

用的都是当前任务自己的状态和优先级，所以当前任务一定还在新的筛选结果里。

因此更合理的体验不是关掉详情，而是：

• 让详情继续保持打开
• 让位置摘要重新计算

例如：

• 原来可能是完整列表里的某一条
• 只看同状态 后变成 第 1 / 3 条
• 再 只看同优先级 后变成 第 1 / 1 条

这就是很典型的：

详情上下文不变，但它所在的列表上下文发生了变化。

---

这次主要改了哪些文件？

这一课主要涉及这些文件：

1. src/components/tasks/TaskDetailDrawer.vue
2. src/views/TasksView.vue
3. src/components/tasks/__tests__/taskDetailDrawer.spec.ts
4. e2e/pages/TasksPage.ts
5. e2e/app.spec.ts
6. docs/README.md

另外新增了本节文档：

• docs/41-task-detail-drawer-quick-filters.md

---

在 src/components/tasks/TaskDetailDrawer.vue 里学什么？

这一课里，详情抽屉新增了一个 快速筛选 区块。

这个区块做了三件事：

1. 提供两个明确动作入口

• 只看同状态
• 只看同优先级

这两个按钮的价值是：

把"当前任务信息"直接转成"后续列表处理动作"。

2. 继续保持展示层组件的职责边界

组件里没有直接改：

• statusFilter
• priorityFilter

而是只抛出：

• filter-status
• filter-priority

这让你能继续看到一个很清晰的分层：

• 详情抽屉负责呈现和抛事件
• 页面层负责真协调

3. 把当前会带入筛选的上下文明确展示出来

区块里还新增了一条说明：

• 当前任务会把列表带到 状态：xxx / 优先级：xxx 的子集

这类摘要在真实后台里很重要。

因为复杂页面不能只给按钮，不给用户解释按钮会造成什么影响。

---

在 src/views/TasksView.vue 里学什么？

这一课页面层新增了两条很典型的"详情入口联动列表状态"的处理函数：

• handleFilterTasksByActiveDetailStatus
• handleFilterTasksByActiveDetailPriority

你要重点学会它们背后的思路。

1. 先从详情上下文里拿到当前任务

这两个函数都先读取：

• activeTaskDetail

这说明：

详情抽屉里发起的动作，真正依赖的仍然是页面层正在维护的详情上下文。

2. 再把列表筛选切换到对应值

比如：

• 当前任务状态是 待开始
• 当前任务优先级是 高

那么点击对应动作后，就分别调用：

• handleStatusChange('待开始')
• handlePriorityChange('高')

这样做的好处是：

新入口复用旧逻辑。

不用重新发明一套"详情专用筛选逻辑"。

3. 同时把页码主动重置到第一页

这是这一课非常值得你记住的一点。

如果筛选上下文变了，但页码还留在老页码上，会有两个问题：

• 用户不一定第一眼看到新的筛选结果起点
• 列表会停在旧分页上下文里，不利于继续批量处理

所以这里页面层主动做了：

• currentPage.value = 1

这就是典型的后台列表体验优化：

筛选变了，分页通常也应该回到起点。

4. 详情上下文保持不丢，让位置摘要自动重算

这一课没有主动关闭详情抽屉。

原因是：

• 当前任务本来就属于同状态 / 同优先级结果
• 没必要把用户从当前上下文里踢出去

所以点击快速筛选后会发生的是：

• 列表筛选变了
• 地址栏 query 变了
• 详情仍然开着
• 详情位置摘要重新计算

这是一种非常典型的"多区域围绕同一业务对象继续联动"的后台前端能力。

---

为什么这里不把快速筛选直接塞进 composable？

这一课刻意把"详情入口动作"留在页面层，有两个原因。

1. 这次重点不是"定义一个新的全局筛选 API"

而是：

定义一个新的详情入口，并让它接回现有列表筛选逻辑。

所以页面层包装一下现有 handleStatusChange / handlePriorityChange 更清楚。

2. 这次还要一起协调提示文案和页码跳转

页面层同时负责：

• 调整筛选状态
• 重置页码
• 保持详情上下文
• 给出用户提示

这些本来就是页面层更适合做的事情。

所以这节课最值得你记住的是：

不是所有逻辑都要继续往 composable 里迁；如果是"新入口协调已有页面状态"，页面层往往更合适。

---

单元测试这次补了什么？

文件：

• src/components/tasks/__tests__/taskDetailDrawer.spec.ts

这一课补了两类验证。

1. 快速筛选区确实渲染出来了

验证：

• 快速筛选 标题出现
• 只看同状态 按钮出现
• 只看同优先级 按钮出现

2. 组件会把当前任务上下文正确抛给父组件

验证：

• 点击 只看同状态 后，会抛出当前任务状态
• 点击 只看同优先级 后，会抛出当前任务优先级

这里你要重点学会的是：

展示层组件测试的重点，是"有没有正确渲染"和"有没有正确抛事件"，而不是去测页面级联动结果。

---

E2E 这次补了什么？

文件：

• e2e/pages/TasksPage.ts
• e2e/app.spec.ts

Page Object 新增了两个方法

• filterTasksByCurrentDetailStatus
• filterTasksByCurrentDetailPriority

这样测试代码就可以直接表达：

• 从详情里按同状态继续处理
• 从详情里按同优先级继续处理

新增的端到端测试做了什么？

这一课新增了一条完整 E2E：

• user can narrow task list from detail drawer by current status and priority

它验证了完整链路：

1. 打开第 4 条任务详情
2. 点击 只看同状态
3. 地址栏同步出 status=待开始
4. 详情抽屉保持在当前任务
5. 位置摘要更新成 第 1 / 3 条
6. 再点击 只看同优先级
7. 地址栏同步出 priority=高
8. 位置摘要更新成 第 1 / 1 条
9. 刷新后 status + priority + taskId 还能一起恢复

这条测试很重要。

因为它测的是：

• 详情动作入口
• 列表筛选状态
• URL 同步
• 刷新恢复
• 详情位置联动

已经非常接近真实后台页面的复杂交互了。

---

你现在真正应该学会什么？

学完这一课，你不应该只记住"详情抽屉里多了两个按钮"。

更重要的是理解下面 4 件事：

1. 详情可以是列表工作流的起点，不只是终点

详情不只是"看信息"。

它也可以直接把用户带回新的列表处理上下文。

2. 新入口最好复用已有页面状态逻辑

快速筛选没有重新发明筛选器，而是复用了已有：

• 状态筛选
• 优先级筛选
• 地址栏同步

3. 多区域联动时，页面层最适合做总协调

详情抽屉、筛选栏、分页、URL、位置摘要一起变化时，页面层是最稳妥的总调度点。

4. 列表上下文变了，不代表详情上下文一定要关掉

如果当前任务仍然属于新的结果集，就应该保留详情，并让它自动重算在新上下文里的位置。