2020-4-27 seo達(dá)人
無論是 pc 端還是移動端，無可避免都會涉及到列表查詢有關(guān)的操作，但對于這兩種不同的設(shè)備，其列表查詢的最佳處理方式也是完全不同。
對于 pc 端列表查詢來說，前端通常是給與服務(wù)端當(dāng)前需要獲取的數(shù)據(jù)量(如 pageCount，limit 等參數(shù))以及所需要獲取數(shù)據(jù)的位置(如 pageSize，offset 等參數(shù))作為查詢條件。然后服務(wù)端然后返回?cái)?shù)據(jù)總數(shù)，以及當(dāng)前數(shù)據(jù)，前端再結(jié)合這些數(shù)據(jù)顯示頁面總數(shù)等信息。這里我稱為相對位置取數(shù)。
對于移動端而言，沒有pc 端那么大的空間展示以及操作，所以基本上都會采用下拉取數(shù)這種方案。
那么我們在處理移動端列表查詢時候使用這種相對位置取數(shù)會有什么問題呢？
通過相對位置取數(shù)會具有性能問題，因?yàn)橐坏┦褂?offset 信息來獲取數(shù)據(jù)，隨著頁數(shù)的增加，響應(yīng)速度也會變的越來越慢。因?yàn)樵跀?shù)據(jù)庫層面，我們每次所獲取的數(shù)據(jù)都是“從頭開始第幾條”，每次我們都需要從第一條開始計(jì)算，計(jì)算后舍棄前面的數(shù)據(jù)，只取最后多條數(shù)據(jù)返回前端。
當(dāng)然了，對于相對位置取數(shù)來說，數(shù)據(jù)庫優(yōu)化是必然的，這里我就不多做贅述了。對于前端開發(fā)來說，優(yōu)秀的的查詢條件設(shè)計(jì)可以在一定方面解決此問題。
事實(shí)上，對于一個實(shí)際運(yùn)行的項(xiàng)目而言，數(shù)據(jù)更新才是常態(tài)，如果數(shù)據(jù)更新的頻率很高或者你在當(dāng)前頁停留的時間過久的話，會導(dǎo)致當(dāng)前獲取的數(shù)據(jù)出現(xiàn)一定的偏差。
例如：當(dāng)你在獲取最開始的 20 條數(shù)據(jù)后，正準(zhǔn)備獲取緊接著的后 20 條數(shù)據(jù)時，在這段時間內(nèi) ，發(fā)生了數(shù)據(jù)增加，此時移動端列表就可能會出現(xiàn)重復(fù)數(shù)據(jù)。雖然這個問題在 pc 端也存在，但是 pc 端只會展示當(dāng)前頁的信息，這樣就避免了該問題所帶來的負(fù)面影響。
我們在上面的問題中說明了，移動端下拉加載中使用相對位置查詢?nèi)?shù)是有問題的。
那么，如果當(dāng)前不能迅速結(jié)合前后端進(jìn)行修改 api 的情況下，當(dāng)服務(wù)端傳遞過來的數(shù)據(jù)與用戶想要得的數(shù)據(jù)不一致，我們必須在前端進(jìn)行處理，至少處理數(shù)據(jù)重復(fù)問題所帶來的負(fù)面影響。
因?yàn)楫?dāng)前分頁請求時無狀態(tài)的。在分頁取到數(shù)據(jù)之后前端可以對取得的數(shù)據(jù)進(jìn)行過濾，過濾掉當(dāng)前頁面已經(jīng)存在的 key(例如 id 等能夠確定的唯一鍵)。
通過這種處理方式，我們至少可以保證當(dāng)前用戶看到的數(shù)據(jù)不會出現(xiàn)重復(fù)。同時當(dāng)列表數(shù)據(jù)可以編輯修改的時候，也不會出現(xiàn)因?yàn)?key 值相同而導(dǎo)致數(shù)據(jù)錯亂。
如果不使用相對位置獲取數(shù)據(jù)，前端可以利用當(dāng)前列表中的最后一條數(shù)據(jù)作為請求源參數(shù)。前端事先記錄最后一條數(shù)據(jù)的信息。例如當(dāng)前的排序條件為創(chuàng)建時間，那么記錄最后一條數(shù)據(jù)的創(chuàng)建時間為主查詢條件(如果列表對應(yīng)的數(shù)據(jù)不屬于個人，可能創(chuàng)建時間不能唯一決定當(dāng)前數(shù)據(jù)位置，同時還需要添加 ID 等信息作為次要查詢條件)。
當(dāng)我們使用絕對位置獲取數(shù)據(jù)時候，雖然我們無法提供類似于從第 1 頁直接跳轉(zhuǎn) 100 頁的查詢請求，但對于下拉加載這種類型的請求，我們不必?fù)?dān)心性能以及數(shù)據(jù)重復(fù)顯示的問題。
對于相對位置取數(shù)來說，前端可以根據(jù)返回?cái)?shù)據(jù)的總數(shù)來判斷。但當(dāng)使用絕對位置取數(shù)時，即使獲取數(shù)據(jù)總數(shù)，也無法判斷當(dāng)前查詢是否存在后續(xù)數(shù)據(jù)。
從服務(wù)器端實(shí)現(xiàn)的角度來說，當(dāng)用戶想要得到 20 條數(shù)據(jù)時候，服務(wù)端如果僅僅只向數(shù)據(jù)庫請求 20 條數(shù)據(jù)，是無法得知是否有后續(xù)數(shù)據(jù)的。服務(wù)端可以嘗試獲取當(dāng)前請求的數(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 }事實(shí)上，前面我們已經(jīng)解決了移動端處理列表查詢的問題。但是我們做的還不夠好，前端還需要結(jié)合排序條件來處理并提供請求參數(shù)，這個操作對于前端來說也是一種負(fù)擔(dān)。那么我們就聊一下 HATEOAS 。
HATEOAS (Hypermedia As The Engine Of Application State, 超媒體即應(yīng)用狀態(tài)引起) 這個概念最早出現(xiàn)在 Roy Fielding 的論文中。REST 設(shè)計(jì)級別如下所示:
HATEOAS 會在 API 返回的數(shù)據(jù)中添加下一步要執(zhí)行的行為，要獲取的數(shù)據(jù)等 URI 的鏈接信息。客戶端只要獲取這些信息以及行為鏈接，就可以根據(jù)這些信息進(jìn)行接下來的操作。
對于當(dāng)前的請求來說，服務(wù)端可以直接返回下一頁的信息，如
{ data: [], hasMore: true, nextPageParams: {}
}服務(wù)端如此傳遞數(shù)據(jù)，前端就不需要對其進(jìn)行多余的請求處理，如果當(dāng)前沒有修改之前的查詢以及排序條件，則只需要直接返回 “nextPageParams” 作為下一頁的查詢條件即可。
這樣做的好處不但符合 REST LEVEL 3,同時也減輕了前端的心智模型。前端無需配置下一頁請求參數(shù)。只需要在最開始查詢的時候提供查詢條件即可。
當(dāng)然，如果前端已經(jīng)實(shí)現(xiàn)了所有排序添加以及查詢條件由服務(wù)端提供，前端僅僅提供組件，那么該方案更能體現(xiàn)優(yōu)勢。 前端是不需要知道當(dāng)前業(yè)務(wù)究竟需要什么查詢條件，自然也不需要根據(jù)查詢條件來組織下一頁的條件。同時，該方案的輸入和輸出都由后端提供，當(dāng)涉及到業(yè)務(wù)替換( 查詢條件，排序條件修改)時候，前端無需任何修改便可以直接替換和使用。
一旦涉及到移動端請求，不可避免的會有網(wǎng)絡(luò)問題，當(dāng)用戶在火車或者偏遠(yuǎn)地區(qū)時候，一旦下拉就會涉及取數(shù)，但是當(dāng)前數(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)
}藍(lán)藍(lán)設(shè)計(jì)的小編 http://m.skdbbs.com