上一篇说过列表页的“忙”不是一个是几个。这一篇把这些“忙”落成三层每一层有自己的归属和关门条件。分层以后交给 Codex 的任务就从“加个 loading”变成“给这个页面找出几个等待每个等待归谁管”。分层不是命名游戏。真正的依据是生命周期谁触发的、等谁的、谁有权结束。页面级遮罩只认首屏不认每一次请求页面级的等待起点是页面挂载终点是首屏数据就绪。它的作用是把整页空白挡在后面遮罩一关页面就进入可用状态。这一层最容易写错的地方是让它跟着后续每一次翻页、查询开开关关。首屏过后再查一遍数据页面本身不需要重新遮罩遮罩反复出现反而打断操作。结构示意const firstLoad ref(true); const list ref([]); const initList async () { firstLoad.value true; try { list.value await listApi({ page: 1, size: 10 }); } finally { firstLoad.value false; } };finally只是确保这个状态一定会复位不代表它解决了并发。首屏和翻页如果共用同一个请求入口还需要请求资格判断这一点上一篇已经拆过。按钮级节流和去重是两件事按钮级的等待属于一次提交起点是点击终点是这次提交的响应。它要解决的是用户手快连点两次。const saving ref(false); const onSave async (form) { if (saving.value) return; saving.value true; try { await saveApi(form); } finally { saving.value false; } };这里挡住的只是“同一时间只发一次”。还有一类问题它挡不住请求已经发出、响应也回来了用户刷新页面或后退后再点一次同一份表单又提交了一份。那是幂等和去重的事不是节流的事。web-skills把按钮节流交给btnState配置在请求拦截器里打开、响应或异常里关闭。它管的是节流这一段不负责业务幂等。给 Codex 描述按钮状态时要先分清这次要解决的是连点还是重复数据两个目标对应两套机制。局部级表格区域和弹框各自关门局部级的等待发生在页面已经可用之后只影响一小块区域。典型的是表格查询和弹框内加载。const listLoading ref(false); const dialogLoading ref(false); const loadList async (params) { listLoading.value true; try { return await listApi(params); } finally { listLoading.value false; } };表格的listLoading只跟随列表请求弹框的dialogLoading只跟随弹框请求。它们不该互相覆盖也不该去动页面级的遮罩。web-skills用loading和dialogLoading两个独立配置项把这两段分开。目标项目若没有这套封装至少要保证一个区域的状态不会因为另一个区域的请求结束而被关掉。局部级还有一个并发细节。两次翻页快速切换时第一次请求后返回也会执行finally把listLoading提前关掉。所以局部状态同样要配请求资格判断否则分层了遮罩还是会被旧响应提前收走。三层之间的关闭条件先写清楚再让 Codex 动手层级触发者关闭条件常见错写页面级页面挂载首屏数据 settle跟随每次查询反复遮罩按钮级用户点击本次提交 settle用全局 loading 代替按钮状态局部级区域请求该区域最新请求 settle被其它区域或旧响应关闭这张表交给 Codex 之前先确认“settle”在项目里的含义。有的团队只要请求返回就关有的要求数据已写入状态再关。口径不统一分层再清楚也会在交接处出缝。分层后的验收一半靠读代码一半靠跑页面加载状态没法只靠静态审查交付有一部分必须打开页面才能确认。静态能查的每个 loading 状态有没有独立的来源关闭发生在响应成功、失败还是finally有没有哪个状态被多个请求共用。要跑页面的并发翻页时遮罩会不会被旧响应提前关掉保存期间表格查询的 loading 是否被误关首屏遮罩关掉后表格是否已就绪。这些需要一次真实操作或者明确记为未验证不能靠读代码下结论。交给 Codex 的任务模板请为这张列表页整理加载状态不先改代码 1. 列出页面里所有“忙”的场景首屏、翻页、查询、刷新、保存、弹框加载等。 2. 为每个场景标出层级页面级、按钮级还是局部级。 3. 记录每个状态当前由谁写入、在哪个请求或生命周期里关闭。 4. 找出被两个以上请求共用的状态说明谁先返回会影响谁。 5. 区分按钮节流和业务幂等指出本项目当前只解决了哪个。 先给出分层表和关闭条件再给最小修改方案。不要新增一个统一 loading 把现有状态包起来也不要绕开项目已有的请求封装。这条任务的第一句就是“不先改代码”。加载状态的混乱大多是因为动手之前没人把“几个忙、各归谁”数清楚。数清楚了改哪里通常是显而易见的。写在最后分层解决的不是命名问题是关门权。页面遮罩、按钮状态、区域加载各有各的生命周期把它们塞进一个布尔值遮罩就会在错误的时间消失。按页面、按钮、局部三层划清归属和关闭条件再配合请求资格判断加载状态才从“加了个变量”变成“每条等待都有出处”。下一篇进到按钮这一层专门讲重复提交连点、双击、提交后刷新、接口重试分别该用节流、去重还是幂等来挡而不是一律塞进btnState。本系列持续更新。列表页的加载和提交状态收束后会回到页面异常路径看接口失败时列表应该如何退化。参考资料OpenAI Codex 用例理解代码库中的请求流、模块职责与隐藏依赖
上一篇说过列表页的“忙”不是一个是几个。这一篇把这些“忙”落成三层每一层有自己的归属和关门条件。分层以后交给 Codex 的任务就从“加个 loading”变成“给这个页面找出几个等待每个等待归谁管”。分层不是命名游戏。真正的依据是生命周期谁触发的、等谁的、谁有权结束。页面级遮罩只认首屏不认每一次请求页面级的等待起点是页面挂载终点是首屏数据就绪。它的作用是把整页空白挡在后面遮罩一关页面就进入可用状态。这一层最容易写错的地方是让它跟着后续每一次翻页、查询开开关关。首屏过后再查一遍数据页面本身不需要重新遮罩遮罩反复出现反而打断操作。结构示意const firstLoad ref(true); const list ref([]); const initList async () { firstLoad.value true; try { list.value await listApi({ page: 1, size: 10 }); } finally { firstLoad.value false; } };finally只是确保这个状态一定会复位不代表它解决了并发。首屏和翻页如果共用同一个请求入口还需要请求资格判断这一点上一篇已经拆过。按钮级节流和去重是两件事按钮级的等待属于一次提交起点是点击终点是这次提交的响应。它要解决的是用户手快连点两次。const saving ref(false); const onSave async (form) { if (saving.value) return; saving.value true; try { await saveApi(form); } finally { saving.value false; } };这里挡住的只是“同一时间只发一次”。还有一类问题它挡不住请求已经发出、响应也回来了用户刷新页面或后退后再点一次同一份表单又提交了一份。那是幂等和去重的事不是节流的事。web-skills把按钮节流交给btnState配置在请求拦截器里打开、响应或异常里关闭。它管的是节流这一段不负责业务幂等。给 Codex 描述按钮状态时要先分清这次要解决的是连点还是重复数据两个目标对应两套机制。局部级表格区域和弹框各自关门局部级的等待发生在页面已经可用之后只影响一小块区域。典型的是表格查询和弹框内加载。const listLoading ref(false); const dialogLoading ref(false); const loadList async (params) { listLoading.value true; try { return await listApi(params); } finally { listLoading.value false; } };表格的listLoading只跟随列表请求弹框的dialogLoading只跟随弹框请求。它们不该互相覆盖也不该去动页面级的遮罩。web-skills用loading和dialogLoading两个独立配置项把这两段分开。目标项目若没有这套封装至少要保证一个区域的状态不会因为另一个区域的请求结束而被关掉。局部级还有一个并发细节。两次翻页快速切换时第一次请求后返回也会执行finally把listLoading提前关掉。所以局部状态同样要配请求资格判断否则分层了遮罩还是会被旧响应提前收走。三层之间的关闭条件先写清楚再让 Codex 动手层级触发者关闭条件常见错写页面级页面挂载首屏数据 settle跟随每次查询反复遮罩按钮级用户点击本次提交 settle用全局 loading 代替按钮状态局部级区域请求该区域最新请求 settle被其它区域或旧响应关闭这张表交给 Codex 之前先确认“settle”在项目里的含义。有的团队只要请求返回就关有的要求数据已写入状态再关。口径不统一分层再清楚也会在交接处出缝。分层后的验收一半靠读代码一半靠跑页面加载状态没法只靠静态审查交付有一部分必须打开页面才能确认。静态能查的每个 loading 状态有没有独立的来源关闭发生在响应成功、失败还是finally有没有哪个状态被多个请求共用。要跑页面的并发翻页时遮罩会不会被旧响应提前关掉保存期间表格查询的 loading 是否被误关首屏遮罩关掉后表格是否已就绪。这些需要一次真实操作或者明确记为未验证不能靠读代码下结论。交给 Codex 的任务模板请为这张列表页整理加载状态不先改代码 1. 列出页面里所有“忙”的场景首屏、翻页、查询、刷新、保存、弹框加载等。 2. 为每个场景标出层级页面级、按钮级还是局部级。 3. 记录每个状态当前由谁写入、在哪个请求或生命周期里关闭。 4. 找出被两个以上请求共用的状态说明谁先返回会影响谁。 5. 区分按钮节流和业务幂等指出本项目当前只解决了哪个。 先给出分层表和关闭条件再给最小修改方案。不要新增一个统一 loading 把现有状态包起来也不要绕开项目已有的请求封装。这条任务的第一句就是“不先改代码”。加载状态的混乱大多是因为动手之前没人把“几个忙、各归谁”数清楚。数清楚了改哪里通常是显而易见的。写在最后分层解决的不是命名问题是关门权。页面遮罩、按钮状态、区域加载各有各的生命周期把它们塞进一个布尔值遮罩就会在错误的时间消失。按页面、按钮、局部三层划清归属和关闭条件再配合请求资格判断加载状态才从“加了个变量”变成“每条等待都有出处”。下一篇进到按钮这一层专门讲重复提交连点、双击、提交后刷新、接口重试分别该用节流、去重还是幂等来挡而不是一律塞进btnState。本系列持续更新。列表页的加载和提交状态收束后会回到页面异常路径看接口失败时列表应该如何退化。参考资料OpenAI Codex 用例理解代码库中的请求流、模块职责与隐藏依赖
