时间：2021-07-01 10:21:17 帮助过：24人阅读
希望能实现在无过滤和搜索条件下时，在详情页内直接做到全局的上一条下一条切换；而在有过滤条件或搜索条件时，上一条下一条在搜索结果列表中切换。
这是我自己想出来的方案。
在整个组件初始化时，就把本用户下的所有通知(ID)取到本地，记到全局[store.list.all]，之后当点击详情页时，前端把要点击的条目id作为参数做ajax请求，这样详情页就有当前通知id，所有通知id列表。这样的话详情页就可以很轻松的知道上一条的id、下一条的id。
当有过滤或搜索条件时，记到全局[store.list.filter]，方法同上。
优点：上一条下一条会变得非常容易实现，而且列表页每次翻页不需要请求数据。
缺点：如果这个用户的通知列表非常长，那么初始化和搜索的时候，需要请求并记录到[store.list]中的数据就会非常大，首页速度可能会非常慢，而且性能会变糟。
公司以前产品的方案。
列表页做分页查询，每次请求使用page+row做参数，以一页row条，查询第page页的方式进行查询（比如page=3,row=10，就意味着查询第31-40条）。过滤和搜索功能同样。
之前的产品未实现上一条下一条切换。
不过按照这个思路继续搞下去的话，大概会这样：
无过滤搜索条件下，发送当前id作为参数，并带上next或previous参数，这样数据库查询时可以依靠select * from foo where id = (select min(id) from foo where id > 4)这个方式去查询。
有过滤搜索条件下，这个就比较恶心了，自己没想出什么好主意，大概是在从列表页点进详情页时保存一下搜索状态（这个可以做到，返回按钮就有保存这个状态），之后在上一条下一条时，除了id、next，也带上搜索条件做查询。就是ajax请求api写起来会比较恶心。
优点：列表页分页，用户有多少条通知都不怕。
缺点：列表页翻页时还要请求和查询，查询条件复杂，后端负担大，详情页上一条下一跳的ajax请求会比较难写。
目前就这两种思路，各有优缺点。
大家还有没有其他思路？
想做一个通知组件，基于MVVM，所有数据走json。列表页带过滤和搜索功能。通知详情带上一条下一条切换。
希望能实现在无过滤和搜索条件下时，在详情页内直接做到全局的上一条下一条切换；而在有过滤条件或搜索条件时，上一条下一条在搜索结果列表中切换。
这是我自己想出来的方案。
在整个组件初始化时，就把本用户下的所有通知(ID)取到本地，记到全局[store.list.all]，之后当点击详情页时，前端把要点击的条目id作为参数做ajax请求，这样详情页就有当前通知id，所有通知id列表。这样的话详情页就可以很轻松的知道上一条的id、下一条的id。
当有过滤或搜索条件时，记到全局[store.list.filter]，方法同上。
优点：上一条下一条会变得非常容易实现，而且列表页每次翻页不需要请求数据。
缺点：如果这个用户的通知列表非常长，那么初始化和搜索的时候，需要请求并记录到[store.list]中的数据就会非常大，首页速度可能会非常慢，而且性能会变糟。
公司以前产品的方案。
列表页做分页查询，每次请求使用page+row做参数，以一页row条，查询第page页的方式进行查询（比如page=3,row=10，就意味着查询第31-40条）。过滤和搜索功能同样。
之前的产品未实现上一条下一条切换。
不过按照这个思路继续搞下去的话，大概会这样：
无过滤搜索条件下，发送当前id作为参数，并带上next或previous参数，这样数据库查询时可以依靠select * from foo where id = (select min(id) from foo where id > 4)这个方式去查询。
有过滤搜索条件下，这个就比较恶心了，自己没想出什么好主意，大概是在从列表页点进详情页时保存一下搜索状态（这个可以做到，返回按钮就有保存这个状态），之后在上一条下一条时，除了id、next，也带上搜索条件做查询。就是ajax请求api写起来会比较恶心。
优点：列表页分页，用户有多少条通知都不怕。
缺点：列表页翻页时还要请求和查询，查询条件复杂，后端负担大，详情页上一条下一跳的ajax请求会比较难写。
目前就这两种思路，各有优缺点。
大家还有没有其他思路？
方案一的致命一击： 如果一个用户用10W条通知。
方案二的致命一击：不停的增加查询条件的复杂度，对存储压力增大。
======
中庸方案
一次读取N天数据（前提是N天的数据量基本可控，否则该方案不实现）。
靠谱方案
使用Elasticsearch