写移动端列表时我会先盯一个小地方。下拉刷新和触底加载会不会打架。Web 后台分页的入口很清楚。用户点分页器页码变化重新请求。UniApp 页面不一样。用户手指一滑可能触发下拉刷新继续往下滑又可能触发触底加载。网络慢一点两个请求先后回来列表状态就容易乱。Codex 如果只按current、size写分页它能写出一个看起来完整的列表。真正滑起来以后问题才会出现。移动端分页先分清两个动作下拉刷新和触底加载都在请求列表但两个动作的目标完全不同。下拉刷新要回到第一页。它通常要重置页码、重置是否还有下一页、重新提交查询条件并决定旧列表是否立刻清空。触底加载要接着当前列表往后拼。它不能重置列表也不能在没有更多数据时继续请求。它还要防止用户连续触底短时间内发出两次下一页请求。这两个动作如果都调用同一个getList参数里就要说清楚当前是哪一种动作。只写一个无参getList()Codex 很容易在函数内部凭感觉判断。感觉写出来的分页最怕碰到慢请求。requestState 要真管住请求uni-wx里提到xt-page的listData.pageObj推荐字段里有requestState、hasNext、current、size、total。这些字段要负责控制列表行为不能只把对象补完整。requestState要能回答页面现在是否正在请求。正在请求时触底加载应该停住。否则用户滑到底部页面可能连续发两次同页请求。后回来的那次如果再拼到列表里重复数据就来了。hasNext要能回答后面还有没有数据。已经没有下一页时触底入口应该直接返回。继续请求没有意义还会把空响应当成异常处理。current要能回答下一次请求哪一页。刷新时它回到第一页触底时它进入下一页。这个字段如果在请求前后时机不清楚失败后会很麻烦。请求第二页失败了当前页到底算第一页还是已经变成第二页这个决定会影响下一次触底。我会要求 Codex 在写代码前先说清这些字段的更新时机。旧响应覆盖新列表是隐藏问题移动端列表还有一个不太明显的问题。旧请求可能晚回来。用户进入页面第一页请求发出去了。网络还没回来他下拉刷新又发了一次第一页请求。第二次请求先返回页面展示了新列表。第一次请求后来才返回如果代码没有识别请求顺序它可能把旧数据重新写回去。这个问题在后台分页里也有但移动端更常见因为刷新和触底是手势触发用户不会等按钮恢复以后再操作。Codex 写列表时不能只关心接口成功后怎么赋值。它要说明旧响应是否会被丢弃或者至少要保证同一时刻只有一个列表请求在跑。项目里如果已有useTableMixin就先查它怎么处理请求状态没有确认前不要自己把请求并发放开。空状态要等状态稳定以后再显示移动端列表的空状态也容易写早。页面刚进入时列表为空。这个时候如果直接写list.length 0就展示xt-noData用户会先看到空状态闪一下然后数据才出来。接口失败时列表也可能为空它和正常空数据要分开处理。我会把空状态拆成三种。状态页面该怎么理解首次加载中不展示正常空状态等待请求结束正常空列表请求成功第一页没有数据可以展示xt-noData请求失败展示错误提示或重试入口不能当成正常无数据xt-noData能统一空状态展示但它不能替页面判断为什么空。判断仍然要靠请求状态、页码和接口结果。失败恢复要讲清当前页触底加载失败以后页面不该把旧列表清掉。旧列表是用户已经看到的内容要保留。问题在于当前页怎么恢复。一种写法是在请求成功后再更新current。请求第二页成功current才变成 2。失败时仍停在 1下一次触底继续请求第二页。另一种写法是在请求前先把current加一。这样失败时必须回滚否则下一次触底会跳到第三页。两种写法都能用但 Codex 必须选一种并写清楚。它不能在刷新时先改页码在触底时又后改页码。时机混乱以后列表会漏页或重复页。交给 Codex 前我会先问这几个问题移动端列表任务开始前我会让 Codex 先回答这些问题。问题目的刷新时是否清空旧列表决定用户看到旧内容还是空白等待触底时如何防重复请求防止同页重复拼接当前页在请求前还是请求后更新决定失败后是否需要回滚没有更多数据时怎么停住防止无意义请求首次加载、正常空、失败空怎么区分防止xt-noData显示错是否复用useTableMixin优先遵守项目已有列表逻辑这些问题答完再让 Codex 写页面列表才会稳一点。验收要多做几组连续动作我验收 UniApp 列表分页会连续做几组动作。首次进入页面看加载状态和第一页数据。下拉刷新一次看页码是否回到第一页。快速触底两次看是否只发一次下一页请求。模拟没有更多数据看触底是否停住。模拟接口失败看旧列表是否保留、加载状态是否关闭、下一次操作是否还能继续。这些动作比只看“列表能加载下一页”更接近移动端真实使用。uni-wx在这里提供的是项目规则入口。xt-page、pageObj、useTableMixin、xt-noData都是线索。Codex 要先顺着这些线索读项目再写自己的逻辑。移动端列表要重新处理刷新、触底和状态恢复不能只把后台分页器藏起来。下一篇我会把这套判断整理成一份可以直接交给 Codex 的移动端列表任务模板。本系列持续更新。写移动端时我会继续把重点放在可验证的页面行为上。
写移动端列表时我会先盯一个小地方。下拉刷新和触底加载会不会打架。Web 后台分页的入口很清楚。用户点分页器页码变化重新请求。UniApp 页面不一样。用户手指一滑可能触发下拉刷新继续往下滑又可能触发触底加载。网络慢一点两个请求先后回来列表状态就容易乱。Codex 如果只按current、size写分页它能写出一个看起来完整的列表。真正滑起来以后问题才会出现。移动端分页先分清两个动作下拉刷新和触底加载都在请求列表但两个动作的目标完全不同。下拉刷新要回到第一页。它通常要重置页码、重置是否还有下一页、重新提交查询条件并决定旧列表是否立刻清空。触底加载要接着当前列表往后拼。它不能重置列表也不能在没有更多数据时继续请求。它还要防止用户连续触底短时间内发出两次下一页请求。这两个动作如果都调用同一个getList参数里就要说清楚当前是哪一种动作。只写一个无参getList()Codex 很容易在函数内部凭感觉判断。感觉写出来的分页最怕碰到慢请求。requestState 要真管住请求uni-wx里提到xt-page的listData.pageObj推荐字段里有requestState、hasNext、current、size、total。这些字段要负责控制列表行为不能只把对象补完整。requestState要能回答页面现在是否正在请求。正在请求时触底加载应该停住。否则用户滑到底部页面可能连续发两次同页请求。后回来的那次如果再拼到列表里重复数据就来了。hasNext要能回答后面还有没有数据。已经没有下一页时触底入口应该直接返回。继续请求没有意义还会把空响应当成异常处理。current要能回答下一次请求哪一页。刷新时它回到第一页触底时它进入下一页。这个字段如果在请求前后时机不清楚失败后会很麻烦。请求第二页失败了当前页到底算第一页还是已经变成第二页这个决定会影响下一次触底。我会要求 Codex 在写代码前先说清这些字段的更新时机。旧响应覆盖新列表是隐藏问题移动端列表还有一个不太明显的问题。旧请求可能晚回来。用户进入页面第一页请求发出去了。网络还没回来他下拉刷新又发了一次第一页请求。第二次请求先返回页面展示了新列表。第一次请求后来才返回如果代码没有识别请求顺序它可能把旧数据重新写回去。这个问题在后台分页里也有但移动端更常见因为刷新和触底是手势触发用户不会等按钮恢复以后再操作。Codex 写列表时不能只关心接口成功后怎么赋值。它要说明旧响应是否会被丢弃或者至少要保证同一时刻只有一个列表请求在跑。项目里如果已有useTableMixin就先查它怎么处理请求状态没有确认前不要自己把请求并发放开。空状态要等状态稳定以后再显示移动端列表的空状态也容易写早。页面刚进入时列表为空。这个时候如果直接写list.length 0就展示xt-noData用户会先看到空状态闪一下然后数据才出来。接口失败时列表也可能为空它和正常空数据要分开处理。我会把空状态拆成三种。状态页面该怎么理解首次加载中不展示正常空状态等待请求结束正常空列表请求成功第一页没有数据可以展示xt-noData请求失败展示错误提示或重试入口不能当成正常无数据xt-noData能统一空状态展示但它不能替页面判断为什么空。判断仍然要靠请求状态、页码和接口结果。失败恢复要讲清当前页触底加载失败以后页面不该把旧列表清掉。旧列表是用户已经看到的内容要保留。问题在于当前页怎么恢复。一种写法是在请求成功后再更新current。请求第二页成功current才变成 2。失败时仍停在 1下一次触底继续请求第二页。另一种写法是在请求前先把current加一。这样失败时必须回滚否则下一次触底会跳到第三页。两种写法都能用但 Codex 必须选一种并写清楚。它不能在刷新时先改页码在触底时又后改页码。时机混乱以后列表会漏页或重复页。交给 Codex 前我会先问这几个问题移动端列表任务开始前我会让 Codex 先回答这些问题。问题目的刷新时是否清空旧列表决定用户看到旧内容还是空白等待触底时如何防重复请求防止同页重复拼接当前页在请求前还是请求后更新决定失败后是否需要回滚没有更多数据时怎么停住防止无意义请求首次加载、正常空、失败空怎么区分防止xt-noData显示错是否复用useTableMixin优先遵守项目已有列表逻辑这些问题答完再让 Codex 写页面列表才会稳一点。验收要多做几组连续动作我验收 UniApp 列表分页会连续做几组动作。首次进入页面看加载状态和第一页数据。下拉刷新一次看页码是否回到第一页。快速触底两次看是否只发一次下一页请求。模拟没有更多数据看触底是否停住。模拟接口失败看旧列表是否保留、加载状态是否关闭、下一次操作是否还能继续。这些动作比只看“列表能加载下一页”更接近移动端真实使用。uni-wx在这里提供的是项目规则入口。xt-page、pageObj、useTableMixin、xt-noData都是线索。Codex 要先顺着这些线索读项目再写自己的逻辑。移动端列表要重新处理刷新、触底和状态恢复不能只把后台分页器藏起来。下一篇我会把这套判断整理成一份可以直接交给 Codex 的移动端列表任务模板。本系列持续更新。写移动端时我会继续把重点放在可验证的页面行为上。
