分页列表，删除最后一页的最后一条数据的场景该怎么处理

后台不是会返回 pagecount 吗？跟当前页码比较一下，如果小于当前页码，就把当前页码设置为 pagecount

服务端查不到就返回最后一页吧，前端哪知道你还有没有新的数据了。

每次切换页面的时候也给前端返回总数据量，让前端根据这个数字动态分页

count: xxx
amount: xxx
offset: xxx
data
- obj
- obj

count 为 0 的时候现实一个占位符

一定要前一页的话前端重新请求 offset = offset - count

relay 分页

看错了。

当然是前端处理咯，这个不是分页控件应该实现的功能么？

后端好一点吧，前端处理的话要多请求一次

恰好我前不久碰到这个问题了。最初的想法是后端处理，后端送回最后一页，也送回总数等等，但是发现这个好心帮忙反而容易导致前端状态系统紊乱。后来改成前端处理，也就是后端返回空内容及文档总数，由客户端根据情况再次请求数据。改成前端处理虽然多了一次访问，但是状态流程顺畅了，舒服。

不仅仅是你删除最后一条或一页数据，还可能其他用户删除该数据也导致同样的问题。

这个东西，就是通用性与便捷性的冲突，如果你知道根本不存在数据为 0 的情况，你可以不必处理，如果你要预期这个结果，而且具有通用性，就要数据为 0 的时候就返回数据为 0 的状态，正常数据的时候也要返回额外的正常状态。不管怎么样，前端都要先检查状态，再处理数据。

@hyyou2010 关于这个可以看各大网站的 api 是怎么描述的，确实如 @chinvo 所言。

后端接口不用设计太复杂 按照当前分页、当前页数据数量作为参数就行，其他的前端处理。

删除最后一页的最后一条数据的时候，自动-1 请求。如果当前页只有 1 页就不用请求了。

删除以后刷新页面，pageindex=min(pagesize,querypagesize)

@ssvfdn 自动减 1 可能不行，设想你正浏览第 3 页，版主恰好把第 2 及 3 页都删除了

路由上带后缀的，如果数据发生了变化，那返回时肯定不能是 return back()了。

@hyyou2010 但是可能有这种情况：前端第一次请求之后，第二次请求之前，有另一个用户加了一条数据，结果就是数据总数没变，页码却往前翻了一页

据一个普通网民的经验：有的网站 只有 28 个 page，但?page=99 时也有内容，只不过内容是最后一页的

列表接口要返回

总条数
当前页数
总共页数

其他前端处理就行

前后端分离，前端处理
不分离，后端处理

如果前后端分离：
删除要指定资源 ID，和是否分页无关
最后一页数据不存在的话，返回 404 或者空列表比较合适
分页错误的问题是前端逻辑，前端处理就可以了

@shintendo 嗯，有这个可能，这点还真不容易想到。不过这样的结果我觉得还可以接受。

那个，好奇问问，删除操作后前端不会重新加载列表吗？
后端必须有总分页数，
当前端提交的当前页数>总分页数，就直接把当前页数设置为总分页数。

前端后端处理都是一样的。你所说的场景，实际上是两个连续但相对独立的场景：删除一条数据；重新计算总数和计算分页参数，然后重新加载当前页或最后页（不止是删除后，并发修改的时候，也会出现当前页已经不存在的情况）。

不负责 /没时间负责的前端控件经常丢弃或忽略“重新计算分页参数”。
水平搓 /不负责任 /没时间负责的后端，会用一个函数，就完成“删除，查询当前页数据，然后返回”的整套流程既然是一个函数处理，那自然就超大概率忘了“数据变动后分页页码要重新计算”的场景。

@passerbytiny 不是很认同这个说法。

首先前端如何都是要处理的，无非是怎么处理罢了(试问前端不处理，后端如何处理前端的事？
“删除，查询当前页数据，然后返回” <---基本分前後端后都是接口调用取数据吧？后端没必要在删除操作后再执行一次查询数据吧？后端直接提供->新增、修改、删除、读取四个接口，如果前端删除完，直接调用取 即可了吧？

这东西，，谁有更好的办法吗。。。前端不做 后端要做这个了。。

这个后端处理吧，前端不是知道数据的具体变动，后端才知道真正的最后一页是啥