首页 > 其他分享> > 分页复选设计是怎样让你入坑的

分页复选设计是怎样让你入坑的

2021-05-26 09:30:47 作者：互联网

定义

什么是分页复选设计呢？如下图所示，这是掘金专栏的一个功能，可以选择将同类的文件批量添加到专栏里，随着下拉，会一页一页的返回。
在这里插入图片描述

除了这种设计，还有一种是下面有页数，根据页数跳转的设计，如：
在这里插入图片描述

使用

复选功能有两个，选中和取消。

这种分页复选，我见过两种设计。

第一种，也就是掘金专题上面的用法，已经选好的不会再在分页中显示出来，所以分页复选只实现了增加的功能。已经选中的有单独的列表，在这个列表中可以选中删除。
在这里插入图片描述

成功的将增加和删除分割开来，用户使用起来很通畅。

第二种，选中和取消功能都在分页复选中。有一种场景是用户发起申请，运营推荐一些服务，后面用户再次发起申请，运营需要根据以前推荐的内容进行增减。

坑在哪里

分页复选的坑比较隐秘，大家可以先自己思考一下哪里有问题，如果能够想到，那说明同学还是很细心、敏捷的。

之所以先这篇文章，也是因为做一个项目的时候遇到了这个坑，以前觉得自己经手过太多项目，很多坑都能避免，没想到现实还是会啪啪打脸，需要学到老活到老。

第一种设计将选中和取消分隔开，这种是没有什么坑的。而且产品还很贴心的增加了搜索功能，方便查找。

坑在第二种。

最开始我觉得挺容易的，记录已经推荐的内容，分页的时候，如果分页里有已经被推荐的，则选中状态为true，否则为false，前端根据接口返回的状态来显示选中与否。当用户提交的时候，前端将选中的内容提交，将提交的内容与原本记录的推荐内容做集合操作，找出哪些是新增的，哪些是需要删除的，哪些是不变的，然后更新这些记录。

很多同学可能觉得这个思路比较合理，可能是因为我们都静止的看问题，如果在思考这个设计的时候，能考虑到多页的情况，就能发现其中的坑了。

举个例子，假设能够推荐的内容共100个，每页10个，共10页，第一次推荐的时候推荐每页的第一个和最后一个。类似这个样子：
在这里插入图片描述

运营第二次推荐的时候会导致两个问题：

使用困难：如果要查看以前推荐了哪些，只能看完所有页面，这是很不好的。可以通过将已经推荐的放在首部，一定程度上缓解这个问题，但运营仍然需要查看多页。
产生歧义：第二次推荐的时候，运营只是想把首页的取消掉，将第一页的取消后直接提交，前端提交的内容是啥都不推荐，系统会将所有推荐内容去掉。

解决方案

解决方案我想到两种：

如果推荐内容少，可以只有一页，把已经推荐的内容置顶，这种操作对运营最友好
如果内容过多，只能采用多页方式，提交的时候需要传递增加了哪些、删除了哪些，这需要前端自己进行记录，服务端根据这些数据就能计算出新增哪些、删除哪些、哪些不变。
- 这种操作会导致前端工作量增大，因为复选框可以不断做勾选、不勾选操作，再加上分页，出问题概率会比较大。
- 即使把已推荐的置顶，这种方式仍然会产生一定歧义。举个例子，如果第一次推荐的总数量有三页，第二次推荐时，运营想全部不推荐，运营不熟悉系统，只将第一页完全去掉就提交了，运营认为自己完成了任务，但是系统还留有2页推荐，歧义发生。
- 如果推荐的数据并不存储在自己系统中，是从其它系统通过接口分页获取的，除非接口支持，否则无法实现置顶功能，运营使用时仍然需要遍历所有页面。

总结

个人不是特别建议使用分页复选功能，真要用的话，最好将分页复选功能单一化，只有增加功能，已有的推荐有单独列表展示。

最后

大家如果喜欢我的文章，可以关注我的公众号（程序员麻辣烫）

我的个人博客为：https://shidawuhen.github.io/

往期文章回顾：

招聘

设计模式

语言

架构

存储

网络

工具

读书笔记

思考

标签：分页,推荐,复选,Go,字节,设计模式,怎样
来源： https://blog.csdn.net/shida219/article/details/117279729