定义
什么是分页复选设计呢？如下图所示，这是掘金专栏的一个功能，可以选择将同类的文件批量添加到专栏里，随着下拉，会一页一页的返回。
除了这种设计，还有一种是下面有页数，根据页数跳转的设计，如：
使用
复选功能有两个，选中和取消。
这种分页复选，我见过两种设计。
第一种，也就是掘金专题上面的用法，已经选好的不会再在分页中显示出来，所以分页复选只实现了增加的功能。已经选中的有单独的列表，在这个列表中可以选中删除。
成功的将增加和删除分割开来，用户使用起来很通畅。
第二种，选中和取消功能都在分页复选中。有一种场景是用户发起申请，运营推荐一些服务，后面用户再次发起申请，运营需要根据以前推荐的内容进行增减。
坑在哪里
分页复选的坑比较隐秘，大家可以先自己思考一下哪里有问题，如果能够想到，那说明同学还是很细心、敏捷的。
之所以写这篇文章，也是因为做一个项目的时候遇到了这个坑，以前觉得自己经手过太多项目，很多坑都能避免，没想到现实还是会啪啪打脸，需要学到老活到老。
第一种设计将选中和取消分隔开，这种是没有什么坑的。而且产品还很贴心的增加了搜索功能，方便查找。
坑在第二种。
最开始我觉得挺容易的，记录已经推荐的内容，分页的时候，如果分页里有已经被推荐的，则选中状态为true，否则为false，前端根据接口返回的状态来显示选中与否。当用户提交的时候，前端将选中的内容提交，将提交的内容与原本记录的推荐内容做集合操作，找出哪些是新增的，哪些是需要删除的，哪些是不变的，然后更新这些记录。
很多同学可能觉得这个思路比较合理，可能是因为我们都静止的看问题，如果在思考这个设计的时候，能考虑到多页的情况，就能发现其中的坑了。
举个例子，假设能够推荐的内容共100个，每页10个，共10页，第一次推荐的时候推荐每页的第一个和最后一个。类似这个样子：
运营第二次推荐的时候会导致两个问题：
- 使用困难：如果要查看以前推荐了哪些，只能看完所有页面，这是很不好的。可以通过将已经推荐的放在首部，一定程度上缓解这个问题，但运营仍然需要查看多页。
- 产生歧义：第二次推荐的时候，运营只是想把首页的取消掉，将第一页的取消后直接提交，前端提交的内容是啥都不推荐，系统会将所有推荐内容去掉。
解决方案
解决方案我想到两种：
- 如果推荐内容少，可以只有一页，把已经推荐的内容置顶，这种操作对运营最友好
- 如果内容过多，只能采用多页方式，提交的时候需要传递增加了哪些、删除了哪些，这需要前端自己进行记录，服务端根据这些数据就能计算出新增哪些、删除哪些、哪些不变。
- 这种操作会导致前端工作量增大，因为复选框可以不断做勾选、不勾选操作，再加上分页，出问题概率会比较大。
- 即使把已推荐的置顶，这种方式仍然会产生一定歧义。举个例子，如果第一次推荐的总数量有三页，第二次推荐时，运营想全部不推荐，运营不熟悉系统，只将第一页完全去掉就提交了，运营认为自己完成了任务，但是系统还留有2页推荐，歧义发生。
- 如果推荐的数据并不存储在自己系统中，是从其它系统通过接口分页获取的，除非接口支持，否则无法实现置顶功能，运营使用时仍然需要遍历所有页面。
总结
个人不是特别建议使用分页复选功能，真要用的话，最好将分页复选功能单一化，只有增加功能，已有的推荐有单独列表展示。
最后
大家如果喜欢我的文章，可以关注我的公众号（程序员麻辣烫）
我的个人博客为：https://shidawuhen.github.io/
往期文章回顾：
招聘
- 字节跳动|内推大放送
- 字节跳动|今日头条广州服务端研发工程师内推
- 字节跳动|抖音电商急招上海前端开发工程
- 字节跳动|抖音电商上海资深服务端开发工程师-交易
- 字节跳动|抖音电商武汉服务端（高级）开发工程师
- 字节跳动|飞书大客户产品经理内推咯
- 字节跳动|抖音电商服务端技术岗位虚位以待
- 字节跳动招聘专题
设计模式
- Go设计模式(11)-代理模式
- Go设计模式(10)-原型模式
- Go设计模式(9)-建造者模式
- Go设计模式(8)-抽象工厂
- Go设计模式(7)-工厂模式
- Go设计模式(6)-单例模式
- Go设计模式(5)-类图符号表示法
- Go设计模式(4)-代码编写优化
- Go设计模式(4)-代码编写
- Go设计模式(3)-设计原则
- Go设计模式(2)-面向对象分析与设计
- Go设计模式(1)-语法
语言
架构
存储
网络
工具
读书笔记
思考
