“不吹不黑”说一说列表页多"简单"

前言

相信随着前端职业的兴起，有很多后端或者项目经理以为前端不就那么回事么？甚至于有些时候，后端一看这么个简单的东西也要作一天？那么本文就带你们了解一下一个还算正常的手机列表页须要那些工做量。

入口

分析列表页首先要看入口，由于一个好的列表页确定是可复用的，入口的不一样将致使列表的数据展现不一样以及处理的不一样。

作过不止一次从不一样入口到同一个列表页，但展现倒是不一样的，这里多是由于业务不一样，多是由于权限不一样，多是由于历史操做不一样。那么你的入口逻辑就要区分下了，区分不一样的入口致使的差异，以及首次和非首次进入的区别。

也有一种特殊处理，就是当是列表页进入详情再返回列表的时候，须要记忆上一步列表的状态。对于app是很简单的事情也许，但对于前端就须要记录比较多的关键点了。可能包括：用户的过滤选择，关键字，请求到的分页信息，请求到的缓存数据，滚动到的位置。对，很明确行业是有明确的方案的，但注意我这里是说的工做量，有这部分需求就须要去实现，去细化，以及测试的。

返回

列表进来了，我不想看，返回了个人入口页面。这里也有很重要的逻辑判断。大部分人以为返回不就是返回上一个页面么。有时候的确能够如此考虑，但要看你的页面流是什么。

相信不少人知道页面历史记录，在pc端你能够经过多入口很方便的进入到任何一个可操做性的业务入口，可是手机端只能经过返回、关闭以及指定的主页或者其余按钮脱离本页面。

曾经深度研究过网易云音乐app的播放页。它能够是不少页面点击进来的，每种不一样渠道的进入，在音乐播放页返回都要返回指定的页而不是简单的历史记录页。因此不要简单的认为手机端的返回就和浏览器的返回前进是同样的。当你的应用须要的时候，这个返回逻辑能够包含不一样的业务判断。

也有些逻辑是借助于返回进行的，好比离开页面的风险提示，让你确认操做而后再离开。而有的返回只是当前页某些展现的去掉。

常规列表支持的交互

全量列表 && 分页列表

虽然都是列表，但实际上有不少时候咱们的列表数据却多是总量肯定的，可能涉及到某我的某个业务的数据量的时候，就只有不到一屏，或者最多两页，那这种时候，其实全量列表对于用户来讲是最合适最友好的，而对于全量列表也就不存在加载更多或者没有更多的状况了。

底部上拉加载 && 无限滚动加载

底部上拉是比较常规的交互方式，如今比较经常使用的是无限滚动加载直到没有数据可加载。

下拉刷新 && 顶部双击刷新

下拉刷新是比较常规的交互方式，不过已经愈来愈少用了。如今更多的是顶部双击能够同时达到快速回到顶部而且刷新的做用，对微信朋友圈的交互就是这样的。

没有数据 && 没有更多数据

这两点是彻底不一样的页面展现，而对于没有数据在特定场景下都有特定的含义。

好比有些状况下，产品须要作一些指引，须要在没有数据的时候引导用户，你能够经过新建数据从而有数据，或者是由于你缺乏某些操做、资质之类的缘由致使你没有数据能够看。

也有意外状况是由于你的弱网，断网环境致使了你的没有数据。还有一些异常状况也会致使，而针对异常状况是否作单独说明也是须要和产品确认的点。好比服务器网关报错引发的或者程序员开小差了。

而没有更多数据，其展现也愈来愈趋于简单，正经的文案多是写，没有更多数据了，调皮一点的会写我是有底线的。

当没有更多数据的时候，做为性能交互优化的角度，也须要在逻辑判断上取消其请求数据的部分，甚至取消上拉自己的逻辑操做。

分页的页数

做为分页的常规逻辑，须要清除的知道每次请求的准确页数。我能够简单分享下本身的逻辑，假设用户是初始状态进入的，那么默认pageNo是1，当触发的时候去请求第二页么？不，不是这样的。

在你请求有数据拿到第一页的时候，其实你就知道总条数以及总页数了。因此在每一次数据请求以前，就能够经过比较pageNo与pageTotal的关系来决定加载触发操做的时候是否有必要请求下一页的数据，其是否还有下一页。

实际上，当咱们的当前的pageNo == pageTotal的时候，已经不用请求了；

小于的时候，就须要请求，对应的加载动画，请求接口，取消动画。而后将页数加1 以后，进行从新的判断，若是发现此时，等于了就要下面显示没有更多数据；若是仍是小于就能够仍然触发其加载操做。

特别的是，须要你们注意当原本就只有一页数据的时候，你就要显示出没有更多数据了。这种状况基本都会被忽略，由于通常状况下好像生产环境的列表数据不会这么少，而致使测试或者开发测不到这种异常状况的。

加载动画

就是咱们常说的loading图，不少交互会认为你不加这个就交互很差呢。我本身的观点是看你接口的请求时间以及对应的操做内是否有数据可看。

具体例子说明下：好比上面提到的无限滚动加载，其实大多数时候，咱们是看不到其无限滚动加载的触发动画的，由于其会定义在当你举例底部还有50-100px的时候，就已经去请求数据了，其加载交互在你没看到的底部位置，快的话1s-2s就把下面的数据请求并渲染好了，这样反而是体验好的。但若是你的设置是让其闪现1s出现加载框而后消失那才尴尬呢。那么，为何开始进来的时候须要加载动画是中央的loading呢，由于此时你没有数据可看。

相似的例子还出如今列表项上支持的某些操做，当你点击请求服务器进行功能的时候，其实你关注点是功能的执行结果，而不是继续看数据，也不想丢失这部分的操做，而在产品设计的角度，也会尽可能减小此时其余的没必要要操做，因此才会有这样一个交互，告知用户我在处理你的请求里，请稍等。一则是友好，二则避免用户重复点击，形成服务器没必要要的负担，以及一些后端逻辑处理上多高并发的问题瓶颈，还有就是多请求多返回的冲突提示。

列表项骚操做

左滑 && 右滑

项目的滑动能够展现更多操做或者信息。也有一些列表在切换类型的tab部分是经过滑动的，而也有列表是经过页面滑动切换列表的。慢慢的这种切换列表的方式会变为主流。

拖拽

不少时候会遇到列表的拖拽来调整顺序，从而达到来调整你的优先级或者喜欢程度等。

双击

双击进行的操做会比较少，但慢慢的也会充当为手机手势经常使用的一种。

搜索功能

搜索范围

目前的搜索有不少种类型，有本地搜索，有远程搜索。本地搜索指的是以显示的列表中进行关键字过滤，不用请求接口；而远程搜索则是根据关键字进行远程搜索。

搜索触发条件

随着前端交互的增长，触发条件也增长了不少，简单分为如下几种：

• 动态搜索，每当输入发生变化的时候
• 离开焦点的时候
• 输入法回车的时候
• 点击其后面的搜索按钮
• 搜索图标

搜索帮助

作的好的产品会针对以前搜索过的结果进行搜素记录提示，这个提示是个性化的，动态根据历史记录更新的。能够输入部分后再提供的联想搜索结果中进行选择从而搜索。

搜索与常规展现矛盾点

这里简单讲下搜索与常规展现的逻辑处理，以搜索页和常规列表页为一个页面考虑。

搜索列表与常规列表关系

若是你的搜索请求接口和常规列表接口是同一个，通常状况下都是同一个，当进行搜索的时候，获得有效关键字以后，请求数据，须要将页数重置为1，须要提供关键字， 获得搜索结果以后，须要判断其是否有数据，其展现的没有数据和常规列表的没有数据提示是不同的，不同在你须要告诉用户：1 搜索的关键字是什么 2 是搜索无结果，区别于常规的无结果。

而当你将关键字去掉，切换为常规列表的时候，须要把关键字去空，页数也重置为1 。这里也延伸的拓展下，若是你还涉及到多个tab列表的切换，那么你的tab可能就是对应到不一样的type值的传参，这部分也须要根据对应的部分进行重置。甚至于你可能须要同时进行几种状态的记忆管理，这是很常见的需求。

搜索列表是否和常规列表做为同一个页面

对于这种交互是打问号的，自从有第一个产品在搜索框点击打开新页面以后，搜索页单独打开页面就变成了app交互的一种不成文的习惯。

列表中的懒加载

小谈图片

列表中的图片如今都要支持必定的懒加载，在云音乐的处理中都是开始是默认图，而后是实际缩略图代替。

缩略图规则，通常都是按照比例排版的缩略图。不知道你们有没有研究过微信的缩略图，它可不是简单的把原图尺寸用那么小的尺寸显示那样简单。缩略图涉及到的点这里稍微列举下：

1 缩略图的列表占比，主要做用 2 缩略图通常不是原图，但有必定的转换关系。在阿里的图床中会根据你穿的图片提供至少3中规格的正方形缩略图让你进行选择规格。 3 显示的内容，通常状况下都是原图内容的100%展示，但若是原图宽比不符合缩略图的长宽比，很常见的把，那么就会把原图中间的百分之多少截图做为缩略图展现的部分。 4 控制原图的比例，固然更多时候为了保证产品的统一，可能会控制原图的比例。但若是业务自己是控制不了的，或者原本就不但愿控制，也不用控制的。

小谈骨架屏

第一次感觉到骨架屏是简书的用户体验，初次感受没特别的，再反过来对比的时候，发现这样的体验好不少。相信骨架屏会是页面懒加载技术以后，前端体验优化又一个必备必现的技术点。

其核心体验是：先出轮廓，再详细渲染。

总结

其实这里仅仅列举了一个手机列表页的部分逻辑，尚未列举完整，到这里你还以为作一个列表是很简单的事情么，其实若是从没有很成熟的经验开始作的话，也没有那么容易，须要考虑比较多的事情吧，毕竟列表页是承载不少业务展示形式的载体。

若是你以为本文还不错，加个喜欢，没有主讲代码技术，但满满的前端逻辑。