前言当任务数量从几条增加到几十条“全部、进行中、已完成”已经不能帮助用户快速定位。分类筛选看似只是多一个按钮实际会影响数据模型、查询条件、空状态、统计数字和新增任务默认值。若把分类结果再保存一份问题会和搜索筛选叠加。这篇文章里我继续完善 Taskflow 待办面板重点处理任务分类与组合筛选。我会结合当前代码说明自己调整了哪些状态、操作入口和界面反馈只保留与这个功能直接相关的实现内容。我先把问题拆成输入、变化和结果把完成状态、关键词和分类看作三个独立查询条件最终使用 AND 组合分类选项从源数据去重或使用产品预设新建任务的分类默认值应由表单提交边界决定。开始写任务分类与组合筛选之前我先把输入、状态变化和界面结果分别列清楚。这里真正需要管理的是分类字段、当前分类、完成状态筛选和关键词操作从切换分类、切换状态和输入关键词进入用户最终看到的是左侧分类入口、选中态、数量和筛选结果摘要。三部分一一对应后我再开始改代码避免按钮已经响应但页面结果没有同步。我没有为任务分类与组合筛选另外复制一套任务数据。分类字段、当前分类、完成状态筛选和关键词按照生命周期分别放在任务模型、页面状态或临时草稿中能由现有数据计算出来的结果就保持派生不再额外保存。这样切换页面条件或重复操作时数据来源始终只有一个。我在当前版本中处理的范围当前 App 已加入独立分类筛选侧栏根据任务源数据生成“全部、收集箱、验证、发布”等分类项点击后会和完成状态、关键词一起进入filterTodos()新增和导入完成后会回到“全部”分类删除后如果当前分类已经没有任务也会自动回退。分类结果仍然是派生数据不会复制成多份数组。本轮已经落地privategetVisibleTodos():TodoItem[]{returnfilterTodos(this.todos,this.filter,this.keyword,this.category);}ForEach(getCategories(this.todos),(category:string):void{this.CategoryItem(category);},(category:string):stringcategory-${category});我已在模拟器中点击“验证”分类布局树显示验证 · 全部列表只保留验证类任务。我的实现步骤第一步梳理任务分类与组合筛选需要的状态第一步我会逐项检查分类字段、当前分类、完成状态筛选和关键词哪些是长期事实哪些只在本次操作中有效哪些可以根据其他字段计算。只有无法可靠推导、并且确实会影响界面的内容才新增状态这能减少后续同步字段的数量。第二步收拢任务分类与组合筛选的操作入口第二步我把切换分类、切换状态和输入关键词收拢到清楚的方法中。组件只传必要参数方法内部按照“校验—更新—反馈”的顺序执行避免同一项功能从多个按钮或组件各自修改数据。第三步让界面结果跟随状态变化第三步我让左侧分类入口、选中态、数量和筛选结果摘要直接读取更新后的状态。列表、计数、提示或按钮禁用状态都不单独缓存因此不论操作从哪个入口触发最终界面都遵循同一套渲染规则。第四步检查任务分类与组合筛选的边界情况第四步我专门检查分类为空、分类与搜索组合、切换后无结果以及新增任务所属分类。这些场景一旦出现异常我会先看输入条件再看数据写入最后看界面绑定按顺序排查而不是同时改动状态、布局和配置。关键代码或数据协议privategetCategories():string[]{constvaluesthis.todos.map((item:TodoItem):stringitem.category);return[全部,...newSet(values)];}constmatchesCategorythis.category全部||item.categorythis.category;returnmatchesFiltermatchesKeywordmatchesCategory;这段代码只保留任务分类与组合筛选真正依赖的字段和方法。我省略了周边布局但没有省略决定行为的状态、参数和写入顺序读代码时可以直接看出动作怎样影响最终结果。我的验证方式先选一个分类再切换完成状态在分类条件下搜索关键词删除当前分类最后一项新增默认“收集箱”任务后切换分类。每个结果都必须能由同一查询方法解释。我验证任务分类与组合筛选时会先准备明确的初始状态再执行切换分类、切换状态和输入关键词随后观察左侧分类入口、选中态、数量和筛选结果摘要是否符合预期。最后再补充分类为空、分类与搜索组合、切换后无结果以及新增任务所属分类确保功能不只在最顺利的路径中成立。当前模拟器画面我的取舍用对象数组保存多个分类结果会引入重复状态分类名大小写和空格不统一会产生重复选项删除最后一项后仍显示旧分类数量会暴露缓存问题分类筛选与搜索条件使用 OR 会扩大结果范围。我最需要避免的误区是只看到左侧分类入口、选中态、数量和筛选结果摘要出现就认为功能已经稳定。分类为空、分类与搜索组合、切换后无结果以及新增任务所属分类往往会暴露隐藏问题所以我每次只改变一个条件并记录最先出现的不一致避免多处修改互相掩盖。是否继续抽象取决于任务分类与组合筛选的实际复杂度。我把分类作为筛选条件之一没有为每个分类维护独立数组。只要当前结构仍能清楚表达状态、入口和结果我就不会为了形式增加新的层级。我接下来还会完善的部分真正接入时建议先把category页面状态加入纯逻辑工具函数再增加一个可滚动的分类选择区。完成后才适合写分类筛选的设备截图不要用当前“分类可搜索”截图替代。后续继续扩展时我仍会把功能拆成小步骤先调整模型或工具函数再接入页面最后检查实际交互结果。每一步都保持入口和结果清楚出现问题时也更容易回退。我怎样把这项功能接入现有页面我没有把任务分类与组合筛选当成一个孤立页面重新开发而是先回到现有待办面板中寻找最合适的接入点。页面原来已经有任务数组、筛选条件、输入状态和卡片操作我先确认新功能应该复用哪些状态再决定是否真的需要增加字段。这样做可以避免两个功能分别保存同一事实也能保证已有的筛选、计数和列表渲染继续正常工作。具体到状态设计我把分类字段、当前分类、完成状态筛选和关键词逐项列出来并为每一项写清生命周期它从哪里产生什么时候改变页面关闭或操作结束后是否还需要保留。长期事实进入任务模型或持久化结构当前操作产生的草稿、提示和选择则留在页面状态中。这个判断看起来简单却直接决定了后面会不会出现编辑串值、筛选失效或重启后恢复出错误界面的情况。接入动作时我先沿着切换分类、切换状态和输入关键词走一遍完整链路。我会确认按钮或输入框传入的参数是否足够方法内部是否先校验再写入以及写入后哪些派生结果应该随之变化。只要链路中有一步需要组件自己猜测数据我就把这一步重新收回页面或 Store避免展示组件承担不属于它的职责。完成数据更新后我再检查左侧分类入口、选中态、数量和筛选结果摘要。我不会额外调用一个“刷新页面”的方法而是让这些区域直接读取最新状态。这样无论动作来自鼠标、键盘、弹窗还是恢复流程界面都遵循同一套渲染逻辑。对我来说这比为每种操作分别写一套显示代码更容易维护也能减少不同入口产生不同结果的问题。我还会把关键方法按职责分成三类纯计算方法只接收数据并返回结果写入方法只完成一次明确的数据变化反馈方法只负责更新用户可见状态。三类方法彼此组合但不互相隐藏副作用。这样在检查分类为空、分类与搜索组合、切换后无结果以及新增任务所属分类时我能够快速判断是输入条件不正确、数据写入失败还是界面表达不完整。围绕任务分类与组合筛选我只保留与分类字段、当前分类、完成状态筛选和关键词、切换分类、切换状态和输入关键词和左侧分类入口、选中态、数量和筛选结果摘要直接相关的内容。每个段落都对应一个实际问题避免技术说明被其他流程打断。最后我会从维护者视角再看一次这项改动。如果以后新增任务字段、增加第二个页面或替换存储方案当前代码是否仍有清楚的扩展位置如果一个新需求必须同时改很多不相关文件我会优先重新检查边界而不是继续叠加条件。我把分类作为筛选条件之一没有为每个分类维护独立数组这也是我在这个项目里一直坚持的节奏。我在这一功能上的具体处理在这项改动里我主要完善的是任务分类与组合筛选。我先把分类字段、当前分类、完成状态筛选和关键词单独梳理出来区分哪些内容属于任务事实哪些内容只是当前页面的临时状态。这样页面发生变化时我能直接追到对应的数据来源不需要在多个数组或组件之间猜测哪一份才是最新结果。在交互入口上我把切换分类、切换状态和输入关键词集中到明确的方法中处理。组件只负责把当前任务、输入值或操作类型交给页面真正的校验、数组更新和反馈状态由统一入口完成。这样写比直接在按钮回调里改字段多了一层但新增持久化、撤销或测试时我不需要到处寻找修改点。在界面表现上我重点处理了左侧分类入口、选中态、数量和筛选结果摘要。我希望每次操作完成后用户都能立刻看见状态变化因此相关列表、计数、提示和按钮状态都会读取最新数据。界面展示不是额外维护的一份结果而是从任务数据和页面条件实时计算出来的。我按“准备分类字段、当前分类、完成状态筛选和关键词—执行切换分类、切换状态和输入关键词—检查左侧分类入口、选中态、数量和筛选结果摘要”的顺序组织实现。这个顺序既对应用户操作也对应代码调用链出现问题时可以从当前步骤直接向前追踪。我重点检查了分类为空、分类与搜索组合、切换后无结果以及新增任务所属分类。这些情况最容易暴露状态串扰、重复数据、错误覆盖或布局裁切。如果结果不符合预期我先检查动作是否进入正确方法再检查源数据是否更新最后检查组件读取的字段和条件而不是同时修改多个地方。为了让任务分类与组合筛选便于维护我让字段名称直接表达状态让方法名称直接表达动作并让展示组件只关心左侧分类入口、选中态、数量和筛选结果摘要。隔一段时间再回看时我仍能从命名和调用顺序理解这项功能。这次我没有为了追求功能数量而一次加入过多结构。我把分类作为筛选条件之一没有为每个分类维护独立数组。我更看重当前功能能独立讲清楚、代码入口明确、界面反馈直观后面继续扩展时也能沿用同一套边界。小结这篇文章围绕“鸿蒙ArkUI实战为任务增加分类筛选与组合条件”讨论的不是一个孤立控件而是一条从用户问题到工程证据的完整路径。当前已实现的部分可以直接在待办项目中复查尚未实现的部分则给出了状态边界、代码入口和验收条件。保持这种区分文章才真正有助于读者复现也能让项目后续进度保持可信。