無論是 pc 端還是移動端，無可避免都會涉及到列表查詢有關(guān)的操作，但對于這兩種不同的設(shè)備，其列表查詢的最佳處理方式也是完全不同。

對于 pc 端列表查詢來說，前端通常是給與服務(wù)端當前需要獲取的數(shù)據(jù)量(如 pageCount，limit 等參數(shù))以及所需要獲取數(shù)據(jù)的位置(如 pageSize，offset 等參數(shù))作為查詢條件。然后服務(wù)端然后返回數(shù)據(jù)總數(shù)，以及當前數(shù)據(jù)，前端再結(jié)合這些數(shù)據(jù)顯示頁面總數(shù)等信息。這里我稱為相對位置取數(shù)。

對于移動端而言，沒有pc 端那么大的空間展示以及操作，所以基本上都會采用下拉取數(shù)這種方案。

那么我們在處理移動端列表查詢時候使用這種相對位置取數(shù)會有什么問題呢？

相對位置取數(shù)存在的問題

性能劣勢

通過相對位置取數(shù)會具有性能問題，因為一旦使用 offset 信息來獲取數(shù)據(jù)，隨著頁數(shù)的增加，響應(yīng)速度也會變的越來越慢。因為在數(shù)據(jù)庫層面，我們每次所獲取的數(shù)據(jù)都是“從頭開始第幾條”，每次我們都需要從第一條開始計算，計算后舍棄前面的數(shù)據(jù)，只取最后多條數(shù)據(jù)返回前端。

當然了，對于相對位置取數(shù)來說，數(shù)據(jù)庫優(yōu)化是必然的，這里我就不多做贅述了。對于前端開發(fā)來說，優(yōu)秀的的查詢條件設(shè)計可以在一定方面解決此問題。

數(shù)據(jù)顯示重復(fù)

事實上，對于一個實際運行的項目而言，數(shù)據(jù)更新才是常態(tài)，如果數(shù)據(jù)更新的頻率很高或者你在當前頁停留的時間過久的話，會導(dǎo)致當前獲取的數(shù)據(jù)出現(xiàn)一定的偏差。

例如：當你在獲取最開始的 20 條數(shù)據(jù)后，正準備獲取緊接著的后 20 條數(shù)據(jù)時，在這段時間內(nèi) ，發(fā)生了數(shù)據(jù)增加，此時移動端列表就可能會出現(xiàn)重復(fù)數(shù)據(jù)。雖然這個問題在 pc 端也存在，但是 pc 端只會展示當前頁的信息，這樣就避免了該問題所帶來的負面影響。

結(jié)合列表 key 維持渲染正確

我們在上面的問題中說明了，移動端下拉加載中使用相對位置查詢?nèi)?shù)是有問題的。

那么，如果當前不能迅速結(jié)合前后端進行修改 api 的情況下，當服務(wù)端傳遞過來的數(shù)據(jù)與用戶想要得的數(shù)據(jù)不一致，我們必須在前端進行處理，至少處理數(shù)據(jù)重復(fù)問題所帶來的負面影響。

因為當前分頁請求時無狀態(tài)的。在分頁取到數(shù)據(jù)之后前端可以對取得的數(shù)據(jù)進行過濾，過濾掉當前頁面已經(jīng)存在的 key(例如 id 等能夠確定的唯一鍵)。

通過這種處理方式，我們至少可以保證當前用戶看到的數(shù)據(jù)不會出現(xiàn)重復(fù)。同時當列表數(shù)據(jù)可以編輯修改的時候，也不會出現(xiàn)因為 key 值相同而導(dǎo)致數(shù)據(jù)錯亂。

通過絕對位置獲取數(shù)據(jù)

如果不使用相對位置獲取數(shù)據(jù)，前端可以利用當前列表中的最后一條數(shù)據(jù)作為請求源參數(shù)。前端事先記錄最后一條數(shù)據(jù)的信息。例如當前的排序條件為創(chuàng)建時間，那么記錄最后一條數(shù)據(jù)的創(chuàng)建時間為主查詢條件(如果列表對應(yīng)的數(shù)據(jù)不屬于個人，可能創(chuàng)建時間不能唯一決定當前數(shù)據(jù)位置，同時還需要添加 ID 等信息作為次要查詢條件)。

當我們使用絕對位置獲取數(shù)據(jù)時候，雖然我們無法提供類似于從第 1 頁直接跳轉(zhuǎn) 100 頁的查詢請求，但對于下拉加載這種類型的請求，我們不必擔心性能以及數(shù)據(jù)重復(fù)顯示的問題。

對于相對位置取數(shù)來說，前端可以根據(jù)返回數(shù)據(jù)的總數(shù)來判斷。但當使用絕對位置取數(shù)時，即使獲取數(shù)據(jù)總數(shù)，也無法判斷當前查詢是否存在后續(xù)數(shù)據(jù)。

從服務(wù)器端實現(xiàn)的角度來說，當用戶想要得到 20 條數(shù)據(jù)時候，服務(wù)端如果僅僅只向數(shù)據(jù)庫請求 20 條數(shù)據(jù)，是無法得知是否有后續(xù)數(shù)據(jù)的。服務(wù)端可以嘗試獲取當前請求的數(shù)據(jù)條數(shù) + 1, 如向數(shù)據(jù)庫請求 21 條數(shù)據(jù)，如果成功獲得 21 條數(shù)據(jù)，則說明至少存在著 1 條后續(xù)數(shù)據(jù)，這時候，我們就可以返回 20 條數(shù)據(jù)以及具有后續(xù)數(shù)據(jù)的信息。但如果我們請求 21 條數(shù)據(jù)卻僅僅只能獲取 20 條數(shù)據(jù)(及以下)，則說明沒有后續(xù)數(shù)據(jù)。

如可以通過 “hasMore” 字段來表示是否能夠繼續(xù)下拉加載的信息。

{ data: [], hasMore: true }

結(jié)合 HATEOAS 設(shè)計優(yōu)化

事實上，前面我們已經(jīng)解決了移動端處理列表查詢的問題。但是我們做的還不夠好，前端還需要結(jié)合排序條件來處理并提供請求參數(shù)，這個操作對于前端來說也是一種負擔。那么我們就聊一下 HATEOAS 。

HATEOAS (Hypermedia As The Engine Of Application State, 超媒體即應(yīng)用狀態(tài)引起) 這個概念最早出現(xiàn)在 Roy Fielding 的論文中。REST 設(shè)計級別如下所示:

• REST LEVEL 0: 使用 HTTP 作為傳輸方式
• REST LEVEL 1: 引入資源的概念(每一個資源都有對應(yīng)的標識符和表達)
• REST LEVEL 2: 引入 HTTP 動詞(GET 獲取資源/POST 創(chuàng)建資源/PUT 更新或者創(chuàng)建字樣/DELETE 刪除資源 等)
• REST LEVEL 3: 引入 HATEOAS (在資源的表達中包含了鏈接信息?？蛻舳丝梢愿鶕?jù)鏈接來發(fā)現(xiàn)可以執(zhí)行的動作)

HATEOAS 會在 API 返回的數(shù)據(jù)中添加下一步要執(zhí)行的行為，要獲取的數(shù)據(jù)等 URI 的鏈接信息?？蛻舳酥灰@取這些信息以及行為鏈接，就可以根據(jù)這些信息進行接下來的操作。

對于當前的請求來說，服務(wù)端可以直接返回下一頁的信息，如

{ data: [], hasMore: true, nextPageParams: {}    
}

服務(wù)端如此傳遞數(shù)據(jù)，前端就不需要對其進行多余的請求處理，如果當前沒有修改之前的查詢以及排序條件，則只需要直接返回 “nextPageParams” 作為下一頁的查詢條件即可。

這樣做的好處不但符合 REST LEVEL 3,同時也減輕了前端的心智模型。前端無需配置下一頁請求參數(shù)。只需要在最開始查詢的時候提供查詢條件即可。

當然，如果前端已經(jīng)實現(xiàn)了所有排序添加以及查詢條件由服務(wù)端提供，前端僅僅提供組件，那么該方案更能體現(xiàn)優(yōu)勢。 前端是不需要知道當前業(yè)務(wù)究竟需要什么查詢條件，自然也不需要根據(jù)查詢條件來組織下一頁的條件。同時，該方案的輸入和輸出都由后端提供，當涉及到業(yè)務(wù)替換( 查詢條件，排序條件修改)時候，前端無需任何修改便可以直接替換和使用。

其他注意事項

一旦涉及到移動端請求，不可避免的會有網(wǎng)絡(luò)問題，當用戶在火車或者偏遠地區(qū)時候，一旦下拉就會涉及取數(shù)，但是當前數(shù)據(jù)沒有返回之前，用戶多次下拉可能會有多次取數(shù)請求，雖然前端可以結(jié)合 key 使得渲染不出錯，但是還是會在緩慢的網(wǎng)絡(luò)下請求多次，無疑雪上加霜。這時候我們需要增加條件變量 loading。

偽代碼如下所示：

// 查詢 function search(cond) {
  loading = true api.then(res => {
      loading = false }).catch(err => {
      loading = false })
} // 獲取下一頁數(shù)據(jù) function queryNextPage() { if (!nextPageParams) return if (!loading) return search(nextPageParams)
}