关于列表数据删除时前端展示那些事

今天下午，办公室的民工都在热火朝天的堆代码。突然前端的同志说，删除列表中的一些数据时会造成数据丢失或者重复，我有没有什么看法。作为一个资深不务正业的后端，我决定加入了这场讨论。

交代一下背景：用户个人中心的任务列表需要做批量删除，因为做了分页，根据 limit (page - 1) * page_size, page_size 确实会出现这样的问题。

数据举例： page1：00 01 02 03 04 05 06 07 08 09 page2：10 11 12 13 14 15 16 17 18 19 page320 21 22 23 24 25 26 27 28 29 page4：30 31 32 33 34 35 36 37 38 39 page5：40 41 42 43 44 45 46 47 48 49 

基于这样的背景我们 3 个人（分别称 A 、C 、D （本人），因为感觉小 B 不是很礼貌）提出了几种解决方案：

1 ）做标记

C：或许把删除先做成标记，等到用户退出列表页或者回到个人中心的时候再提交删除.
A & D：这样好像不太稳定，如果用户非正常退出的话不是很好正常提交，造成数据删除失败的现象，而且如果删除失败也不是很好的反馈给用户

总结：NO

2 ）删除部分

D：把删除数据最上页的数据更新，下面的全删除掉呢 例：删除 11 22 23 30 这些数据的话，就重新加载 page2 ，page3 、4 、5 全都删掉。数据变为

page1：00 01 02 03 04 05 06 07 08 09 page2：10 12 13 14 15 16 17 18 19 20 

A & C：这样用户体检不是很好，最好能定位到用户访问数据的最后一项

总结：不适合批量删除，但是单项删除的话好像是可以的，因为删除页就是所在页？

3 ）补齐方式

D：那删除之后，把最后一页做成补齐页记录误差，重新请求最后一页，创建一个新的页放进去呢 例：删除 11 22 23 30 这些数据的话，就把 page5 的前 4 个保留，删除掉后面 6 个，然后重新请求 page5 ，保存在 page6 ，记录误差为 1 ，数据变为

page1：00 01 02 03 04 05 06 07 08 09 page2：10 12 13 14 15 16 17 18 19 page3：20 21 24 25 26 27 28 29 page4： 31 32 33 34 35 36 37 38 39 page5：40 41 42 43 page6: 44 45 46 47 48 49 50 51 52 53 

此时的 page6 的数据为 page5 的数据，page1 + ... + page5 是前 4 页的总和，误差记录为 1 ，请求时页码加上误差即可
A & C：这样会有点问题，如果删除的数据包括 page5 中的数据，那么补齐的数据需要去掉这些数据，如果删除的数据超过了一页，就需要计算最后几页，会比较麻烦

总结：可以实现，但是较复杂

4 ）重新整合

A：基于 3 的方法，在删除完成后把页码重新整合，再请求最后一页的数据，数据变为

page1：00 01 02 03 04 05 06 07 08 09 page2：10 12 13 14 15 16 17 18 19 20 page3： 21 24 25 26 27 28 29 31 32 33 page4： 34 35 36 37 38 39 40 41 42 43 page5: 44 45 46 47 48 49 50 51 52 53 

总结：可以实现，但是数据量较大时可能会渲染卡顿？

5 ）请求时添加偏移量

C：可以请求的时候，加上 delete____count ，数据查询时变为 limit (page - 1) * page_size - delete_count, page_size

总结：可以实现，需要前后端的代码都做一下改动，可能因为数据源的程序不太好改动，那边的同事说实现不了 - -#

写在后面

1.以上讨论都是建立用户操作自己的列表时所做的操作，而且没有考虑到多端登录的问题； 2.如果是在后台管理删除掉数据的话，用户的列表也会出问题，可能需要做缓存或者用别的方式通知用户？ 3.想起之前做的竞价功能，需要最新的出价在上面，然后做分页，列表的数据也会用这种问题，如果加上请求时间就可以解决，如果有需要的同志可以这样实现。 好像还有很多的问题没有解决，但是今天有点晚了，就先这样。 第一次写这种主题，抛砖引玉，如果大家有什么好的解决方法欢迎一起讨论哈