前端用什么技术，才能合理缓存分页结果？

@3dwelcome #3 再说。你这样要么用 http 的缓存，要么每次都要向后端请求 ver 之类的信息去检查。

每次请求的话可以传个 map 去检查{index: id}，然后返回对应新的{index: id}。然后你再比较那个电影详情数据没获取，你再单独获取那个电影的信息就行了。

@vanton 我用的是第一个方案，想找一些类似参考代码，自己写差分算法，总觉得很山寨。

可惜好像大家很少这样做，代码不太好找。

@wunonglin 我是想把这个功能给抽象出来，未来适配所有的列表查询代码。

在移动互联网时代，能减少一点网络流量，那也是好的。

你提供的信息有点少。我只能根据我看到的提出我的方案。
## 后段接口：
* 参数：updatTime-已有数据的最大更新时间。
* 逻辑：
1. 如果 updateTime 不是空，则查询数据时，根据 updateTime 筛选，并给出最大的 updateTime 。
2. 如果 updateTime 是空，则响应 1000 条数据，并给出最大的 updateTime 。
当有数据更新时，需要更新数据的 updateTime

## 前段
* 首次请求，没有 updateTime 参数，会得到 1000 条数据，以及 updateTime 。
* 下次请求，把 updateTime 传给后段，得到差异数据。并在此缓存 updateTime 。

@cp19890714 抱歉，用平板打字，好多错字

@cp19890714 updateTime 可以查询有没有新数据。

可如果服务器删除了 1000 条里其中几条记录，怎么去通知前端也删除呢？

@3dwelcome websocket

@3dwelcome
后端删除通常是逻辑删除，那么还是会有更新时间的。
如果你的后端必须是物理删除，那么就需要传所有数据的 id ，进行对比了。
------------------------
另外，我认为这个需求是伪需求。
1. 使用压缩算法后，响应流量可以大大减少，1000 条数据，应该不会耗费多少流量。
2. 即使每条数据有 100 个字段，流量真的较大，那么应该分为两个接口，1 个接口拿列表，1 个接口拿详情。列表接口的响应流量还是会极少，详情接口的结果进行缓存。

react-query 有实现

都展示 top 1k 了，就没考虑流量问题啊，也不知道考虑过 filter 的问题没有。
维护 2 个数据集，一个是 top 1k + version ，一个是变化数据（ id|action|version ），剩下的懂的

swr 了解一下

后端预先做好 delta 呗

@cyrbuzz 是的，只是这样需要前端向后端提交列表有效 ID ，也不能用 GET ，基础查询全部要改用 POST 方法。

Restful 在流泪。

@3dwelcome

可以做一下改进，前端只传缓存的最新一个 ID ，后端根据传过来的 ID 查询出这个 ID 之后的内容。前端合并一下结果做下分片，在约定一个参数用来标识出改变分页大小的情况。

搭一个 git 或者 svn 吧

@fwindcore 你还别说，我还真想过类似的。

昨晚在谷歌上找方案，顺藤摸瓜发现 nodejs 里有给 apk 打补丁的差分算法。

分两步，第一步盲测找不同，叫 diff 。第二部打补丁，叫 patch 。

那个算法很强，针对二进制。但是源代码太复杂了点，甚至还有专门的论文。

最后思索半天，还是手写了一个山寨版的。两个 ID 集合不匹配总共有三种可能性，一种是旧数据覆盖更新，一种是插入新数据，一种是删除数据，都判断和处理一次就可以了。