2020-4-27 seo達人
無論是 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)
}