Open wsafight opened 4 years ago
无论是 pc 端还是移动端，无可避免都会涉及到列表查询有关的操作，但对于这两种不同的设备，其列表查询的最佳处理方式也是完全不同。
对于 pc 端列表查询来说，前端通常是给与服务端当前需要获取的数据量(如 pageCount，limit 等参数)以及所需要获取数据的位置(如 pageSize，offset 等参数)作为查询条件。然后服务端然后返回数据总数，以及当前数据，前端再结合这些数据显示页面总数等信息。这里我称为相对位置取数。
对于移动端而言，没有pc 端那么大的空间展示以及操作，所以基本上都会采用下拉取数这种方案。
那么我们在处理移动端列表查询时候使用这种相对位置取数会有什么问题呢？
通过相对位置取数会具有性能问题，因为一旦使用 offset 信息来获取数据，随着页数的增加，响应速度也会变的越来越慢。因为在数据库层面，我们每次所获取的数据都是“从头开始第几条”，每次我们都需要从第一条开始计算，计算后舍弃前面的数据，只取最后多条数据返回前端。
当然了，对于相对位置取数来说，数据库优化是必然的，这里我就不多做赘述了。对于前端开发来说，优秀的的查询条件设计可以在一定方面解决此问题。
事实上，对于一个实际运行的项目而言，数据更新才是常态，如果数据更新的频率很高或者你在当前页停留的时间过久的话，会导致当前获取的数据出现一定的偏差。
例如：当你在获取最开始的 20 条数据后，正准备获取紧接着的后 20 条数据时，在这段时间内 ，发生了数据增加，此时移动端列表就可能会出现重复数据。虽然这个问题在 pc 端也存在，但是 pc 端只会展示当前页的信息，这样就避免了该问题所带来的负面影响。
我们在上面的问题中说明了，移动端下拉加载中使用相对位置查询取数是有问题的。
那么，如果当前不能迅速结合前后端进行修改 api 的情况下，当服务端传递过来的数据与用户想要得的数据不一致，我们必须在前端进行处理，至少处理数据重复问题所带来的负面影响。
因为当前分页请求时无状态的。在分页取到数据之后前端可以对取得的数据进行过滤，过滤掉当前页面已经存在的 key(例如 id 等能够确定的唯一键)。
通过这种处理方式，我们至少可以保证当前用户看到的数据不会出现重复。同时当列表数据可以编辑修改的时候，也不会出现因为 key 值相同而导致数据错乱。
如果不使用相对位置获取数据，前端可以利用当前列表中的最后一条数据作为请求源参数。前端事先记录最后一条数据的信息。例如当前的排序条件为创建时间，那么记录最后一条数据的创建时间为主查询条件(如果列表对应的数据不属于个人，可能创建时间不能唯一决定当前数据位置，同时还需要添加 ID 等信息作为次要查询条件)。
当我们使用绝对位置获取数据时候，虽然我们无法提供类似于从第 1 页直接跳转 100 页的查询请求，但对于下拉加载这种类型的请求，我们不必担心性能以及数据重复显示的问题。
对于相对位置取数来说，前端可以根据返回数据的总数来判断。但当使用绝对位置取数时，即使获取数据总数，也无法判断当前查询是否存在后续数据。
从服务器端实现的角度来说，当用户想要得到 20 条数据时候，服务端如果仅仅只向数据库请求 20 条数据，是无法得知是否有后续数据的。服务端可以尝试获取当前请求的数据条数 + 1, 如向数据库请求 21 条数据，如果成功获得 21 条数据，则说明至少存在着 1 条后续数据，这时候，我们就可以返回 20 条数据以及具有后续数据的信息。但如果我们请求 21 条数据却仅仅只能获取 20 条数据(及以下)，则说明没有后续数据。
如可以通过 “hasMore” 字段来表示是否能够继续下拉加载的信息。
{ data: [], hasMore: true }
事实上，前面我们已经解决了移动端处理列表查询的问题。但是我们做的还不够好，前端还需要结合排序条件来处理并提供请求参数，这个操作对于前端来说也是一种负担。那么我们就聊一下 HATEOAS 。
HATEOAS (Hypermedia As The Engine Of Application State, 超媒体即应用状态引起) 这个概念最早出现在 Roy Fielding 的论文中。REST 设计级别如下所示:
HATEOAS 会在 API 返回的数据中添加下一步要执行的行为，要获取的数据等 URI 的链接信息。客户端只要获取这些信息以及行为链接，就可以根据这些信息进行接下来的操作。
对于当前的请求来说，服务端可以直接返回下一页的信息，如
{ data: [], hasMore: true, nextPageParams: {} }
服务端如此传递数据，前端就不需要对其进行多余的请求处理，如果当前没有修改之前的查询以及排序条件，则只需要直接返回 “nextPageParams” 作为下一页的查询条件即可。
这样做的好处不但符合 REST LEVEL 3,同时也减轻了前端的心智模型。前端无需配置下一页请求参数。只需要在最开始查询的时候提供查询条件即可。
当然，如果前端已经实现了所有排序添加以及查询条件由服务端提供，前端仅仅提供组件，那么该方案更能体现优势。 前端是不需要知道当前业务究竟需要什么查询条件，自然也不需要根据查询条件来组织下一页的条件。同时，该方案的输入和输出都由后端提供，当涉及到业务替换( 查询条件，排序条件修改)时候，前端无需任何修改便可以直接替换和使用。
一旦涉及到移动端请求，不可避免的会有网络问题，当用户在火车或者偏远地区时候，一旦下拉就会涉及取数，但是当前数据没有返回之前，用户多次下拉可能会有多次取数请求，虽然前端可以结合 key 使得渲染不出错，但是还是会在缓慢的网络下请求多次，无疑雪上加霜。这时候我们需要增加条件变量 loading。
伪代码如下所示：
// 查询 function search(cond) { loading = true api.then(res => { loading = false }).catch(err => { loading = false }) } // 获取下一页数据 function queryNextPage() { if (!nextPageParams) return if (!loading) return search(nextPageParams) }
无论是 pc 端还是移动端，无可避免都会涉及到列表查询有关的操作，但对于这两种不同的设备，其列表查询的最佳处理方式也是完全不同。
对于 pc 端列表查询来说，前端通常是给与服务端当前需要获取的数据量(如 pageCount，limit 等参数)以及所需要获取数据的位置(如 pageSize，offset 等参数)作为查询条件。然后服务端然后返回数据总数，以及当前数据，前端再结合这些数据显示页面总数等信息。这里我称为相对位置取数。
对于移动端而言，没有pc 端那么大的空间展示以及操作，所以基本上都会采用下拉取数这种方案。
那么我们在处理移动端列表查询时候使用这种相对位置取数会有什么问题呢？
相对位置取数存在的问题
性能劣势
通过相对位置取数会具有性能问题，因为一旦使用 offset 信息来获取数据，随着页数的增加，响应速度也会变的越来越慢。因为在数据库层面，我们每次所获取的数据都是“从头开始第几条”，每次我们都需要从第一条开始计算，计算后舍弃前面的数据，只取最后多条数据返回前端。
当然了，对于相对位置取数来说，数据库优化是必然的，这里我就不多做赘述了。对于前端开发来说，优秀的的查询条件设计可以在一定方面解决此问题。
数据显示重复
事实上，对于一个实际运行的项目而言，数据更新才是常态，如果数据更新的频率很高或者你在当前页停留的时间过久的话，会导致当前获取的数据出现一定的偏差。
例如：当你在获取最开始的 20 条数据后，正准备获取紧接着的后 20 条数据时，在这段时间内 ，发生了数据增加，此时移动端列表就可能会出现重复数据。虽然这个问题在 pc 端也存在，但是 pc 端只会展示当前页的信息，这样就避免了该问题所带来的负面影响。
结合列表 key 维持渲染正确
我们在上面的问题中说明了，移动端下拉加载中使用相对位置查询取数是有问题的。
那么，如果当前不能迅速结合前后端进行修改 api 的情况下，当服务端传递过来的数据与用户想要得的数据不一致，我们必须在前端进行处理，至少处理数据重复问题所带来的负面影响。
因为当前分页请求时无状态的。在分页取到数据之后前端可以对取得的数据进行过滤，过滤掉当前页面已经存在的 key(例如 id 等能够确定的唯一键)。
通过这种处理方式，我们至少可以保证当前用户看到的数据不会出现重复。同时当列表数据可以编辑修改的时候，也不会出现因为 key 值相同而导致数据错乱。
通过绝对位置获取数据
如果不使用相对位置获取数据，前端可以利用当前列表中的最后一条数据作为请求源参数。前端事先记录最后一条数据的信息。例如当前的排序条件为创建时间，那么记录最后一条数据的创建时间为主查询条件(如果列表对应的数据不属于个人，可能创建时间不能唯一决定当前数据位置，同时还需要添加 ID 等信息作为次要查询条件)。
当我们使用绝对位置获取数据时候，虽然我们无法提供类似于从第 1 页直接跳转 100 页的查询请求，但对于下拉加载这种类型的请求，我们不必担心性能以及数据重复显示的问题。
对于相对位置取数来说，前端可以根据返回数据的总数来判断。但当使用绝对位置取数时，即使获取数据总数，也无法判断当前查询是否存在后续数据。
从服务器端实现的角度来说，当用户想要得到 20 条数据时候，服务端如果仅仅只向数据库请求 20 条数据，是无法得知是否有后续数据的。服务端可以尝试获取当前请求的数据条数 + 1, 如向数据库请求 21 条数据，如果成功获得 21 条数据，则说明至少存在着 1 条后续数据，这时候，我们就可以返回 20 条数据以及具有后续数据的信息。但如果我们请求 21 条数据却仅仅只能获取 20 条数据(及以下)，则说明没有后续数据。
如可以通过 “hasMore” 字段来表示是否能够继续下拉加载的信息。
结合 HATEOAS 设计优化
事实上，前面我们已经解决了移动端处理列表查询的问题。但是我们做的还不够好，前端还需要结合排序条件来处理并提供请求参数，这个操作对于前端来说也是一种负担。那么我们就聊一下 HATEOAS 。
HATEOAS (Hypermedia As The Engine Of Application State, 超媒体即应用状态引起) 这个概念最早出现在 Roy Fielding 的论文中。REST 设计级别如下所示:
HATEOAS 会在 API 返回的数据中添加下一步要执行的行为，要获取的数据等 URI 的链接信息。客户端只要获取这些信息以及行为链接，就可以根据这些信息进行接下来的操作。
对于当前的请求来说，服务端可以直接返回下一页的信息，如
服务端如此传递数据，前端就不需要对其进行多余的请求处理，如果当前没有修改之前的查询以及排序条件，则只需要直接返回 “nextPageParams” 作为下一页的查询条件即可。
这样做的好处不但符合 REST LEVEL 3,同时也减轻了前端的心智模型。前端无需配置下一页请求参数。只需要在最开始查询的时候提供查询条件即可。
当然，如果前端已经实现了所有排序添加以及查询条件由服务端提供，前端仅仅提供组件，那么该方案更能体现优势。 前端是不需要知道当前业务究竟需要什么查询条件，自然也不需要根据查询条件来组织下一页的条件。同时，该方案的输入和输出都由后端提供，当涉及到业务替换( 查询条件，排序条件修改)时候，前端无需任何修改便可以直接替换和使用。
其他注意事项
一旦涉及到移动端请求，不可避免的会有网络问题，当用户在火车或者偏远地区时候，一旦下拉就会涉及取数，但是当前数据没有返回之前，用户多次下拉可能会有多次取数请求，虽然前端可以结合 key 使得渲染不出错，但是还是会在缓慢的网络下请求多次，无疑雪上加霜。这时候我们需要增加条件变量 loading。
伪代码如下所示：