当前位置:Gxlcms > PHP教程 > javascript-讨论个通知列表和详情的API设计

javascript-讨论个通知列表和详情的API设计

时间:2021-07-01 10:21:17 帮助过:24人阅读

想做一个通知组件,基于MVVM,所有数据走json。列表页带过滤和搜索功能。通知详情带上一条下一条切换。

希望能实现在无过滤和搜索条件下时,在详情页内直接做到全局的上一条下一条切换;而在有过滤条件或搜索条件时,上一条下一条在搜索结果列表中切换。

方案1:

这是我自己想出来的方案。
在整个组件初始化时,就把本用户下的所有通知(ID)取到本地,记到全局[store.list.all],之后当点击详情页时,前端把要点击的条目id作为参数做ajax请求,这样详情页就有当前通知id,所有通知id列表。这样的话详情页就可以很轻松的知道上一条的id、下一条的id。
当有过滤或搜索条件时,记到全局[store.list.filter],方法同上。

  • 优点:上一条下一条会变得非常容易实现,而且列表页每次翻页不需要请求数据。

  • 缺点:如果这个用户的通知列表非常长,那么初始化和搜索的时候,需要请求并记录到[store.list]中的数据就会非常大,首页速度可能会非常慢,而且性能会变糟。

方案2:

公司以前产品的方案。
列表页做分页查询,每次请求使用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。列表页带过滤和搜索功能。通知详情带上一条下一条切换。

希望能实现在无过滤和搜索条件下时,在详情页内直接做到全局的上一条下一条切换;而在有过滤条件或搜索条件时,上一条下一条在搜索结果列表中切换。

方案1:

这是我自己想出来的方案。
在整个组件初始化时,就把本用户下的所有通知(ID)取到本地,记到全局[store.list.all],之后当点击详情页时,前端把要点击的条目id作为参数做ajax请求,这样详情页就有当前通知id,所有通知id列表。这样的话详情页就可以很轻松的知道上一条的id、下一条的id。
当有过滤或搜索条件时,记到全局[store.list.filter],方法同上。

  • 优点:上一条下一条会变得非常容易实现,而且列表页每次翻页不需要请求数据。

  • 缺点:如果这个用户的通知列表非常长,那么初始化和搜索的时候,需要请求并记录到[store.list]中的数据就会非常大,首页速度可能会非常慢,而且性能会变糟。

方案2:

公司以前产品的方案。
列表页做分页查询,每次请求使用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

人气教程排行