實(shí)戰(zhàn)：前端分頁(yè)與服務(wù)端分頁(yè)完整指南)
1. 分頁(yè)到底在解決什么問(wèn)題先想清楚場(chǎng)景再動(dòng)手先講個(gè)現(xiàn)象。我見(jiàn)過(guò)不少剛接觸 View UI以前叫 iView的開(kāi)發(fā)者拿到 Table 和 Page 組件后第一件事就是照著文檔抄一遍代碼抄完發(fā)現(xiàn)表格能顯示數(shù)據(jù)、頁(yè)碼也能點(diǎn)以為萬(wàn)事大吉。結(jié)果一上生產(chǎn)環(huán)境就出問(wèn)題數(shù)據(jù)量到了幾千條頁(yè)面直接卡頓、翻頁(yè)時(shí)請(qǐng)求重復(fù)發(fā)送、搜索之后頁(yè)碼還停留在舊位置、刪掉當(dāng)前頁(yè)最后一條數(shù)據(jù)后表格變成空白頁(yè)……每一個(gè)都是線上事故級(jí)別的體驗(yàn)問(wèn)題。其實(shí)分頁(yè)這件事本質(zhì)上不是把數(shù)據(jù)切開(kāi)一頁(yè)頁(yè)展示那么簡(jiǎn)單它背后有兩層邏輯一是減少單次渲染的數(shù)據(jù)量二是把展示狀態(tài)和業(yè)務(wù)狀態(tài)解耦。你不把這兩層想清楚寫(xiě)出來(lái)的分頁(yè)代碼永遠(yuǎn)是在打補(bǔ)丁。用 View UI 的 Table 和 Page 組合做分頁(yè)是 Vue 生態(tài)里很經(jīng)典的一套方案。Table 負(fù)責(zé)展示數(shù)據(jù)Page 負(fù)責(zé)提供交互入口兩者通過(guò) data 和事件串聯(lián)起來(lái)。這套組合在我的項(xiàng)目里用了很多年今天把完整思路、踩過(guò)的坑、以及封裝成通用組件的方案一次性寫(xiě)完希望能幫你省掉一些不必要的折騰。先說(shuō)基礎(chǔ)概念方便后面統(tǒng)一語(yǔ)言current / currentPage當(dāng)前頁(yè)碼從 1 開(kāi)始。pageSize / page-size每頁(yè)顯示條數(shù)。total數(shù)據(jù)總條數(shù)。dataTable 當(dāng)前頁(yè)實(shí)際要渲染的數(shù)據(jù)數(shù)組。on-changePage 組件頁(yè)碼變化時(shí)觸發(fā)的回調(diào)函數(shù)。2. 前端分頁(yè)還是服務(wù)端分頁(yè)這個(gè)選擇題決定代碼結(jié)構(gòu)很多人在第一步就選錯(cuò)了方向。我接到過(guò)的分頁(yè)相關(guān)咨詢里至少有一半人分不清前端分頁(yè)和服務(wù)端分頁(yè)該在什么場(chǎng)景下用。這里直接給結(jié)論數(shù)據(jù)量小幾百到一千條以內(nèi)且一次性從接口拿全量數(shù)據(jù)用前端分頁(yè)。數(shù)據(jù)量大幾千條以上或者接口本身就支持分頁(yè)參數(shù)用服務(wù)端分頁(yè)。什么情況下前端分頁(yè)會(huì)出問(wèn)題舉個(gè)例子一次接口返回 5000 條數(shù)據(jù)你把它們?nèi)M(jìn) Table雖然 Table 會(huì)一次性渲染出所有行但 Page 組件的頁(yè)碼計(jì)算、瀏覽器 DOM 節(jié)點(diǎn)數(shù)量、重排重繪帶來(lái)的性能消耗都會(huì)讓你在低端設(shè)備上體驗(yàn)到明顯的卡頓。更嚴(yán)重的是如果表格列的字段很多5000 行乘以 10 列那就是 5 萬(wàn)個(gè)單元格瀏覽器直接崩給你看。服務(wù)端分頁(yè)則是把當(dāng)前頁(yè)顯示哪些數(shù)據(jù)這個(gè)責(zé)任交給后端前端只告訴后端我要第幾頁(yè)、每頁(yè)多少條后端返回當(dāng)前頁(yè)的數(shù)據(jù)和總數(shù)。這種方式的優(yōu)點(diǎn)是前端性能壓力小缺點(diǎn)是每次翻頁(yè)都要等網(wǎng)絡(luò)請(qǐng)求交互上必須處理好 loading 狀態(tài)和錯(cuò)誤重試。我個(gè)人的判斷標(biāo)準(zhǔn)很簡(jiǎn)單如果接口返回的數(shù)據(jù)總量超過(guò) 1000 條或者接口本身已經(jīng)給了 page 和 size 參數(shù)就毫不猶豫走服務(wù)端分頁(yè)。分頁(yè)的本質(zhì)是數(shù)據(jù)訪問(wèn)的邊界控制這個(gè)邊界越靠前系統(tǒng)的可擴(kuò)展性越好。下面這張表是我選型時(shí)的常用參考標(biāo)準(zhǔn)供你直接抄作業(yè)對(duì)比維度前端分頁(yè)服務(wù)端分頁(yè)數(shù)據(jù)量建議1000 條以內(nèi)任意數(shù)量尤其適合大數(shù)據(jù)量接口請(qǐng)求次數(shù)1 次頁(yè)面加載時(shí)每次翻頁(yè) 1 次交互響應(yīng)速度快無(wú)網(wǎng)絡(luò)等待慢依賴網(wǎng)絡(luò)延遲加載狀態(tài)處理基本不需要必須處理后端改動(dòng)無(wú)需要支持分頁(yè)參數(shù)維護(hù)成本低中推薦場(chǎng)景數(shù)據(jù)字典、配置列表、報(bào)表預(yù)覽用戶列表、訂單列表、操作日志3. Table 和 Page 的基礎(chǔ)組合從一份能跑通的代碼說(shuō)起確定了分頁(yè)方式后我們直接寫(xiě)代碼。這里先用一份前端分頁(yè)的完整示例來(lái)拆解核心邏輯因?yàn)樗拇a鏈路最短最適合理解 Table 和 Page 的協(xié)作關(guān)系。假設(shè)我們從接口拿回一份 200 條數(shù)據(jù)的用戶列表每頁(yè)顯示 10 條需要在表格底部用 Page 組件控制翻頁(yè)。先看完整代碼template div classuser-list Table :columnscolumns :datapageData stripe/Table Page :totalmockData.length :currentcurrentPage :page-sizepageSize show-total on-changehandlePageChange stylemargin-top: 16px; text-align: right / /div /template script export default { name: UserList, data() { return { columns: [ { title: ID, key: id, width: 80 }, { title: 姓名, key: name, minWidth: 120 }, { title: 郵箱, key: email, minWidth: 200 }, { title: 創(chuàng)建時(shí)間, key: created_at, minWidth: 180 } ], // 模擬全量數(shù)據(jù)實(shí)際場(chǎng)景中來(lái)自接口 mockData: [], currentPage: 1, pageSize: 10 } }, computed: { pageData() { const start (this.currentPage - 1) * this.pageSize const end start this.pageSize return this.mockData.slice(start, end) } }, created() { this.loadMockData() }, methods: { async loadMockData() { // 模擬接口請(qǐng)求 const res await fetch(/api/user/list) this.mockData await res.json() }, handlePageChange(page) { this.currentPage page } } } /script這套代碼的核心邏輯只有三步全量數(shù)據(jù)存在 mockData 里作為分頁(yè)的數(shù)據(jù)源。computed 里的 pageData 負(fù)責(zé)切頁(yè)根據(jù)當(dāng)前頁(yè)碼和每頁(yè)條數(shù)動(dòng)態(tài)算出當(dāng)前頁(yè)該顯示哪些數(shù)據(jù)。Page 組件的 on-change 事件負(fù)責(zé)更新 currentPagepageData 隨之重新計(jì)算表格自動(dòng)刷新。這里有個(gè)關(guān)鍵設(shè)計(jì)Table 綁定的是pageData而不是mockData。這個(gè)slice的動(dòng)作就是前端分頁(yè)的核心它保證了 Table 每次只拿到 10 條數(shù)據(jù)而不是把 200 條全部渲染出來(lái)。這樣做的直接好處是 DOM 節(jié)點(diǎn)數(shù)量大幅減少頁(yè)面重排開(kāi)銷(xiāo)明顯下降。但如果你只看到了這一步那還沒(méi)入門(mén)。我前兩年接手過(guò)一個(gè)項(xiàng)目同事把這段邏輯寫(xiě)成了handlePageChange(page) { this.mockData this.mockData.slice(page * 10) // 錯(cuò)誤寫(xiě)法 }他以為翻頁(yè)就是把數(shù)據(jù)切掉一段結(jié)果翻到第 3 頁(yè)后每翻一次數(shù)據(jù)就少掉一部分再往回翻全亂了。正確做法永遠(yuǎn)是保留全量數(shù)據(jù)源用計(jì)算屬性去切當(dāng)前頁(yè)而不是去修改數(shù)據(jù)源本身。數(shù)據(jù)源是全集當(dāng)前頁(yè)是視圖這個(gè)邊界不能破。4. 服務(wù)端分頁(yè)的完整鏈路參數(shù)、loading、競(jìng)態(tài)控制一次說(shuō)清服務(wù)端分頁(yè)是實(shí)際業(yè)務(wù)中占比最高的形態(tài)因?yàn)樗苷嬲鉀Q大數(shù)據(jù)量場(chǎng)景下的性能瓶頸。我用一個(gè)訂單列表的案例來(lái)講透完整鏈路。4.1 請(qǐng)求參數(shù)的組裝服務(wù)端分頁(yè)的第一件事是把分頁(yè)參數(shù)傳給接口。View UI 的 Page 組件在頁(yè)碼變化時(shí)觸發(fā)on-change這個(gè)回調(diào)參數(shù)就是新的頁(yè)碼我們需要把它同步給后端。這里要注意字段名對(duì)齊的問(wèn)題。不同后端團(tuán)隊(duì)定義的分頁(yè)參數(shù)不一樣有的用pageNum、pageSize有的用page、limit還有的用current、size。建議前端在封裝請(qǐng)求層時(shí)統(tǒng)一做一層參數(shù)轉(zhuǎn)換不要在每個(gè)頁(yè)面里散落各種字段名。我在項(xiàng)目中通常這樣處理methods: { buildPageParams() { return { page: this.currentPage, // 頁(yè)碼從 1 開(kāi)始 pageSize: this.pageSize, // 每頁(yè)條數(shù) // 其他查詢條件... keyword: this.keyword, status: this.status } }, async fetchOrderList() { this.loading true try { const params this.buildPageParams() const res await getOrderList(params) this.tableData res.data.records || [] this.total res.data.total } catch (error) { // 統(tǒng)一錯(cuò)誤處理 this.$Message.error(訂單列表加載失敗) } finally { this.loading false } } }這里有個(gè)非常容易踩的坑接口返回的字段名不一致。有的后端返回{ list: [], totalCount: 100 }有的返回{ rows: [], total: 100 }還有的包裝成{ data: { records: [], total: 0 } }。建議把接口返回結(jié)構(gòu)統(tǒng)一收斂到一個(gè)normalizeResponse方法里把字段名都轉(zhuǎn)換成語(yǔ)義明確的內(nèi)部結(jié)構(gòu)。4.2 頁(yè)碼變化時(shí)的完整邏輯服務(wù)端分頁(yè)的handlePageChange不能像前端分頁(yè)那樣只更新一個(gè)頁(yè)碼變量它要觸發(fā)重新請(qǐng)求數(shù)據(jù)async handlePageChange(page) { if (page this.currentPage) return this.currentPage page await this.fetchOrderList() }這段代碼看似簡(jiǎn)單實(shí)際生產(chǎn)環(huán)境里還會(huì)遇到更多情況我展開(kāi)講三個(gè)我反復(fù)踩過(guò)的坑。4.3 競(jìng)態(tài)問(wèn)題快速翻頁(yè)時(shí)響應(yīng)順序會(huì)錯(cuò)亂這是我在真實(shí)項(xiàng)目中遇到的最隱蔽的 bug。用戶快速點(diǎn)擊下一頁(yè)、下一頁(yè)、下一頁(yè)前端會(huì)發(fā)出三個(gè)并發(fā)的異步請(qǐng)求。由于網(wǎng)絡(luò)延遲不同先發(fā)的請(qǐng)求未必先返回。如果最后一次點(diǎn)擊的響應(yīng)先回來(lái)了把表格數(shù)據(jù)更新為第 3 頁(yè)的內(nèi)容但緊接著第一次點(diǎn)擊的響應(yīng)才姍姍來(lái)遲又把表格覆蓋成第 1 頁(yè)的內(nèi)容——而此時(shí)的頁(yè)碼按鈕卻停留在第 3 頁(yè)。數(shù)據(jù)和頁(yè)碼錯(cuò)位用戶看到的就是頁(yè)碼是 3表格內(nèi)容卻是第一頁(yè)的靈異現(xiàn)象。解決方式有幾種我推薦用一個(gè)簡(jiǎn)單的請(qǐng)求序號(hào)標(biāo)記methods: { async fetchOrderList() { const requestId this.requestSequence // 每次請(qǐng)求自增 this.loading true try { const res await getOrderList(this.buildPageParams()) // 如果已經(jīng)不是最新的請(qǐng)求直接丟棄這次結(jié)果 if (requestId ! this.requestSequence) return this.tableData res.data.records this.total res.data.total } finally { if (requestId this.requestSequence) { this.loading false } } } }原理就是每次請(qǐng)求前用一個(gè)自增序號(hào)標(biāo)記這是第幾個(gè)請(qǐng)求當(dāng)響應(yīng)回來(lái)時(shí)如果當(dāng)前的序號(hào)已經(jīng)不是自己發(fā)出的那次了說(shuō)明有更新的請(qǐng)求已經(jīng)發(fā)出這次舊響應(yīng)直接丟棄不再更新數(shù)據(jù)。這個(gè)方法比axios的CancelToken更輕量也不需要額外引入庫(kù)已經(jīng)足夠應(yīng)對(duì)大部分業(yè)務(wù)場(chǎng)景。4.4 loading 狀態(tài)的正確打開(kāi)方式服務(wù)端分頁(yè)必須處理 loading因?yàn)榉?yè)時(shí)有一段網(wǎng)絡(luò)空白期。不處理的話用戶翻頁(yè)后會(huì)看到表格內(nèi)容停留在舊數(shù)據(jù)上容易誤以為是不是自己點(diǎn)錯(cuò)了。View UI 的 Table 組件自帶一個(gè)loading屬性傳入布爾值即可Table :columnscolumns :datatableData :loadingloading/Table翻頁(yè)的時(shí)候建議使用 Page 組件的on-change回調(diào)里第一時(shí)間把 loading 置為 true并在請(qǐng)求 finally 中置為 false。這樣可以保證翻頁(yè)交互期間表格上方出現(xiàn) loading 遮罩避免用戶誤操作。4.5 總數(shù)獲取與展示Page 組件的total屬性是數(shù)據(jù)總條數(shù)不是總頁(yè)數(shù)。它需要從接口返回的 total 字段中獲取。很多人初學(xué)時(shí)會(huì)犯一個(gè)錯(cuò)誤把total設(shè)置為當(dāng)頁(yè)返回的數(shù)據(jù)條數(shù)導(dǎo)致 Page 組件永遠(yuǎn)只有一頁(yè)。這個(gè)坑我見(jiàn)得太多了必須單獨(dú)拎出來(lái)說(shuō)。接口返回的 total 是服務(wù)端根據(jù)查詢條件統(tǒng)計(jì)出來(lái)的完整數(shù)據(jù)量Page 組件拿到 total 后自己會(huì)計(jì)算總頁(yè)數(shù)并在頁(yè)碼欄右側(cè)渲染出共 X 條的文字配合show-total屬性。5. 合并查詢條件的分頁(yè)搜索、頁(yè)碼重置、參數(shù)同步一個(gè)都不能少真實(shí)項(xiàng)目里表格分頁(yè)幾乎總是和搜索條件綁在一起的。這一章的坑比基礎(chǔ)分頁(yè)多得多值得單獨(dú)開(kāi)一節(jié)來(lái)說(shuō)。5.1 搜索時(shí)頁(yè)碼必須重置到第一頁(yè)這是一個(gè)看起來(lái)是小事、做錯(cuò)了就是事故的點(diǎn)。假設(shè)用戶正在瀏覽第 8 頁(yè)的數(shù)據(jù)此時(shí)他在搜索框里輸入了新的關(guān)鍵詞點(diǎn)擊查詢按鈕。如果查詢邏輯只是簡(jiǎn)單地把tableData重新賦值為新接口的返回結(jié)果而currentPage還停留在 8會(huì)出現(xiàn)兩種情況接口返回的是第 8 頁(yè)的數(shù)據(jù)但符合條件的數(shù)據(jù)總共可能只有 2 頁(yè)前端拿到的就是第 8 頁(yè)不存在的數(shù)據(jù)——往往是空數(shù)組。即使后端對(duì)超出總頁(yè)數(shù)的頁(yè)碼做了容錯(cuò)返回最后一頁(yè)用戶體驗(yàn)依然是混亂的我明明搜的是新關(guān)鍵詞為什么頁(yè)碼還停在第 8正確做法是搜索條件變化時(shí)把 currentPage 重置為 1同時(shí)把查詢參數(shù)傳給后端。handleSearch() { this.currentPage 1 this.fetchOrderList() }如果把搜索框和頁(yè)碼聯(lián)動(dòng)封裝到一個(gè)統(tǒng)一的handleQuery方法里還可以進(jìn)一步簡(jiǎn)化handleQuery(resetPage true) { if (resetPage) { this.currentPage 1 } this.fetchOrderList() }5.2 查詢參數(shù)的深拷貝陷阱前端傳搜索條件給后端時(shí)如果直接把響應(yīng)綁定的對(duì)象傳給請(qǐng)求函數(shù)這些參數(shù)對(duì)象其實(shí)是 Vue 的響應(yīng)式代理內(nèi)部帶著各種 getter/setter。在序列化傳輸時(shí)某些情況下會(huì)出現(xiàn)參數(shù)丟失或附加多余字段的問(wèn)題。具體表現(xiàn)是搜索條件明明在界面上看得見(jiàn)但后端收到的請(qǐng)求參數(shù)里卻沒(méi)有。這個(gè)坑在 axios 結(jié)合 Vue 2 的響應(yīng)式系統(tǒng)時(shí)偶有發(fā)生排查起來(lái)非常隱蔽。我的建議是組裝請(qǐng)求參數(shù)時(shí)使用一個(gè)新對(duì)象buildPageParams() { return { page: this.currentPage, pageSize: this.pageSize, keyword: this.keyword ? this.keyword.trim() : , status: this.status, dateRange: this.dateRange ? [...this.dateRange] : [] } }不要直接把this.searchForm整個(gè)傳給請(qǐng)求函數(shù)而是手動(dòng)選取需要的字段組裝新對(duì)象。這樣既避免了響應(yīng)式代理的序列化坑也讓請(qǐng)求參數(shù)變得可控和可調(diào)試。5.3 搜索后頁(yè)碼是保留了但查詢參數(shù)對(duì)不上還有一種常見(jiàn) bug搜索關(guān)鍵詞為 A結(jié)果用戶翻頁(yè)時(shí)把關(guān)鍵詞改成了 B然后點(diǎn)下一頁(yè)請(qǐng)求參數(shù)卻是關(guān)鍵詞 B 第 2 頁(yè)。如果后端不校驗(yàn)頁(yè)碼和查詢條件組合的合法性就會(huì)返回一個(gè)混合結(jié)果。這個(gè)問(wèn)題的根源在于頁(yè)碼和關(guān)鍵詞是兩個(gè)來(lái)源不同、更新時(shí)機(jī)不同的狀態(tài)。解決思路是在翻頁(yè)回調(diào)時(shí)確保用的是當(dāng)前最新的查詢條件async handlePageChange(page) { this.currentPage page await this.fetchOrderList() }只要fetchOrderList每次讀取的是最新的this.keyword、this.status等數(shù)據(jù)而不是在搜索那一刻就拍扁的快照這個(gè)問(wèn)題就不會(huì)出現(xiàn)。所以組裝請(qǐng)求參數(shù)時(shí)務(wù)必在請(qǐng)求方法內(nèi)動(dòng)態(tài)讀取組件狀態(tài)而不是在某個(gè)初始化階段把參數(shù)固化下來(lái)。6. 邊界場(chǎng)景與真實(shí)事故復(fù)盤(pán)刪除、編輯后頁(yè)碼漂移怎么處理分頁(yè)代碼寫(xiě)完之后考驗(yàn)功力的是邊界場(chǎng)景。這部分內(nèi)容網(wǎng)上很難找到系統(tǒng)性總結(jié)大多是從一次次的線上問(wèn)題里摸爬滾打出來(lái)的在這里一并分享。6.1 刪除當(dāng)前頁(yè)最后一條數(shù)據(jù)后的頁(yè)碼回退假設(shè)當(dāng)前是第 3 頁(yè)每頁(yè) 10 條這頁(yè)有 3 條數(shù)據(jù)。用戶刪掉了其中 2 條此時(shí)第 3 頁(yè)可能只剩下 1 條數(shù)據(jù)甚至刪掉最后一條后整頁(yè)變空。如果你只是簡(jiǎn)單刷新當(dāng)前頁(yè)表格很可能顯示暫無(wú)數(shù)據(jù)而實(shí)際上前面還有第 1、2 頁(yè)的數(shù)據(jù)。用戶會(huì)以為數(shù)據(jù)被刪光了實(shí)際上是被空頁(yè)給擋住了。我的經(jīng)驗(yàn)是刪除后重新請(qǐng)求數(shù)據(jù)并且根據(jù)返回的總數(shù)判斷當(dāng)前頁(yè)碼是否越界。更穩(wěn)妥的做法是先刪數(shù)據(jù)成功后重新請(qǐng)求總數(shù)如果當(dāng)前頁(yè)的起始索引大于等于總數(shù)就把頁(yè)碼回退一頁(yè)。async handleDelete(row) { const success await deleteOrder(row.id) if (!success) return // 重新拉取數(shù)據(jù)判斷頁(yè)碼是否需要回退 await this.fetchOrderList() const maxPage Math.max(1, Math.ceil(this.total / this.pageSize)) if (this.currentPage maxPage) { this.currentPage maxPage await this.fetchOrderList() } }注意判斷條件是currentPage maxPage而不是簡(jiǎn)單的total 0。因?yàn)榭赡艹霈F(xiàn)當(dāng)前頁(yè) 5 條刪了 1 條還剩 4 條的情況不需要回退但如果是當(dāng)前頁(yè)最后一條被刪就必須往回退一頁(yè)否則用戶就看不到前面的數(shù)據(jù)了。6.2 編輯數(shù)據(jù)后必須當(dāng)前頁(yè)碼重新拉取編輯場(chǎng)景和刪除不一樣用戶在第 2 頁(yè)編輯了一條數(shù)據(jù)保存后如果直接跳到第一頁(yè)重查用戶的閱讀位置就丟了體驗(yàn)很糟糕。正確做法是停留在當(dāng)前頁(yè)碼重新拉取數(shù)據(jù)。async handleEditSave(formData) { await updateOrder(formData) await this.fetchOrderList() // 保持 currentPage 不變 }這樣既刷新了表格內(nèi)容也保留了用戶的瀏覽位置。這里要特別提醒編輯成功后不要順手把 currentPage 重置為 1除非業(yè)務(wù)方明確要求編輯后回到第一頁(yè)。很多產(chǎn)品經(jīng)理不會(huì)明說(shuō)這個(gè)細(xì)節(jié)但作為開(kāi)發(fā)你要有判斷力。6.3 多 Tab 切換后分頁(yè)狀態(tài)的保持與重置如果頁(yè)面里用了 Tabs 組件每個(gè) Tab 都是一個(gè)列表每個(gè)列表都有獨(dú)立的分頁(yè)狀態(tài)。這里有個(gè)微妙的設(shè)計(jì)取舍有的產(chǎn)品希望切換 Tab 后保留每個(gè) Tab 的頁(yè)碼方便用戶回來(lái)繼續(xù)看。有的產(chǎn)品希望切換 Tab 后重置為第一頁(yè)認(rèn)為用戶重新進(jìn)入某個(gè) Tab 就是一次新的瀏覽。我建議在data中為每個(gè) Tab 維護(hù)獨(dú)立的分頁(yè)狀態(tài)而不是共用一個(gè)currentPagedata() { return { pagerMap: { tabA: { currentPage: 1, pageSize: 10, total: 0 }, tabB: { currentPage: 1, pageSize: 10, total: 0 } }, activeTab: tabA } }, computed: { activePager() { return this.pagerMap[this.activeTab] } }這樣每個(gè) Tab 的頁(yè)碼互不干擾切換回來(lái)時(shí)用戶能回到原來(lái)的位置。滿足 保留瀏覽位置 這一體驗(yàn)要求。6.4 Page 組件尺寸和顯示優(yōu)化的幾個(gè)細(xì)節(jié)View UI 的 Page 組件在業(yè)務(wù)中的使用頻率很高有幾個(gè)屬性配置建議直接借鑒show-total在左側(cè)顯示共 X 條比單獨(dú)放一行文字更直觀。show-elevator顯示跳頁(yè)輸入框數(shù)據(jù)量大、頁(yè)碼多時(shí)很有用。show-sizer顯示每頁(yè)條數(shù)選擇器讓用戶自主調(diào)整 pageSize。placement在有 show-sizer 且組件空間受限時(shí)可以通過(guò) placement 控制 poptip 彈出方向。加上這些屬性后的基礎(chǔ)寫(xiě)法Page :totaltotal :currentcurrentPage :page-sizepageSize show-total show-elevator show-sizer :page-size-opts[10, 20, 50, 100] on-changehandlePageChange on-page-size-changehandlePageSizeChange /6.5 pageSize 切換時(shí)也要回到第一頁(yè)當(dāng)用戶通過(guò) show-sizer 將每頁(yè)條數(shù)從 10 改成 50 時(shí)當(dāng)前頁(yè)碼不能保持原樣。舉個(gè)例子用戶在 10 條/頁(yè)時(shí)停留在第 8 頁(yè)此時(shí)改成 50 條/頁(yè)第 8 頁(yè)其實(shí)只對(duì)應(yīng)原來(lái)的第 5 頁(yè)左右數(shù)據(jù)內(nèi)容會(huì)完全錯(cuò)位。必須把頁(yè)碼重置為 1 再重新查詢才能保證展示邏輯自洽handlePageSizeChange(newSize) { this.pageSize newSize this.currentPage 1 this.fetchOrderList() }7. 封裝一個(gè)通用分頁(yè)表格組件把重復(fù)勞動(dòng)一次解決當(dāng)一個(gè)項(xiàng)目里有十幾個(gè)列表頁(yè)都需要分頁(yè)時(shí)每次都復(fù)制粘貼currentPage、pageSize、total、loading、fetchXxx這五件套會(huì)非常痛苦。我在實(shí)際項(xiàng)目中會(huì)封裝一個(gè)通用組件PagedTable把 Table 和 Page 的組合邏輯收納進(jìn)去業(yè)務(wù)頁(yè)面只關(guān)心怎么取數(shù)。7.1 組件設(shè)計(jì)思路組件的核心設(shè)計(jì)是讓父組件決定數(shù)據(jù)從哪來(lái)讓子組件統(tǒng)一管理分頁(yè)狀態(tài)和交互。我選擇用「?jìng)魅胍粋€(gè)返回 Promise 的取數(shù)函數(shù) 查詢參數(shù)對(duì)象」這樣的組合方式template div classpaged-table Table :columnscolumns :datatableData :loadingloading v-bind$attrs / div classpaged-table__footer Page :totaltotal :currentcurrentPage :page-sizepageSize show-total show-elevator show-sizer :page-size-optspageSizeOpts on-changehandlePageChange on-page-size-changehandlePageSizeChange / /div /div /template組件的 props 可以這樣設(shè)計(jì)屬性名類型說(shuō)明columnsArray表格列配置fetchDataFunction接收分頁(yè)參數(shù)返回 PromisequeryParamsObject查詢條件對(duì)象pageSizeNumber每頁(yè)條數(shù)默認(rèn) 10pageSizeOptsArray可選的每頁(yè)條數(shù)列表immediateLoadBoolean是否創(chuàng)建時(shí)立即加載組件的核心邏輯要感知查詢參數(shù)的變化當(dāng)父組件傳入的queryParams變化時(shí)自動(dòng)重置頁(yè)碼并重新請(qǐng)求數(shù)據(jù)。這一步可以通過(guò)在組件內(nèi)監(jiān)聽(tīng)watch: { queryParams: { deep: true, handler() { this.currentPage 1 this.loadTableData() } } }這里有個(gè)細(xì)節(jié)deep: true的成本不低如果項(xiàng)目中有大量這樣的組件同時(shí)監(jiān)聽(tīng)對(duì)象會(huì)有性能壓力。我的做法是在業(yè)務(wù)頁(yè)面主動(dòng)調(diào)用組件的reload()方法來(lái)替代深監(jiān)聽(tīng)見(jiàn)下方的 7.3 小節(jié)。7.2 組件的完整邏輯實(shí)現(xiàn)下面是我在項(xiàng)目中使用過(guò)的完整PagedTable業(yè)務(wù)組件實(shí)現(xiàn)。它是一個(gè)「行為收斂」的封裝適用于基于 Promise 接口的中后臺(tái) CRUD 列表場(chǎng)景。export default { name: PagedTable, props: { columns: { type: Array, required: true }, fetchData: { type: Function, required: true }, queryParams: { type: Object, default: () ({}) }, defaultPageSize: { type: Number, default: 10 }, pageSizeOpts: { type: Array, default: () [10, 20, 50, 100] }, immediateLoad: { type: Boolean, default: true } }, data() { return { tableData: [], total: 0, currentPage: 1, pageSize: this.defaultPageSize, loading: false, requestSequence: 0 } }, created() { if (this.immediateLoad) { this.loadTableData() } }, methods: { async loadTableData() { const requestId this.requestSequence this.loading true try { const res await this.fetchData({ page: this.currentPage, pageSize: this.pageSize, ...this.queryParams }) if (requestId ! this.requestSequence) return this.tableData res.records this.total res.total // 額外處理若當(dāng)前頁(yè)已經(jīng)被刪空自動(dòng)回退頁(yè)碼 if (this.tableData.length 0 this.currentPage 1) { this.currentPage - 1 return this.loadTableData() } } catch (e) { this.$Message.error(數(shù)據(jù)加載失敗) } finally { if (requestId this.requestSequence) { this.loading false } } }, handlePageChange(page) { this.currentPage page this.loadTableData() }, handlePageSizeChange(size) { this.pageSize size this.currentPage 1 this.loadTableData() }, reload() { this.loadTableData() }, reset() { this.currentPage 1 this.loadTableData() } } }在「當(dāng)前頁(yè)已被刪空」的處理上我在前面 6.1 小節(jié)提到的是「刪除后判斷頁(yè)碼是否越界再回退」而封裝組件時(shí)我傾向于用更穩(wěn)的兜底策略如果接口返回的當(dāng)前頁(yè)數(shù)據(jù)為空且當(dāng)前頁(yè)碼大于 1就自動(dòng)往前退一頁(yè)并重新加載。這樣即使是批量刪除、排序后行數(shù)變化、多端同時(shí)操作導(dǎo)致的數(shù)據(jù)量突變也能自動(dòng)修正頁(yè)碼不會(huì)出現(xiàn)空白頁(yè)。7.3 父組件怎么用這個(gè)組件父組件里只需要把取數(shù)函數(shù)和查詢條件對(duì)象傳進(jìn)去template div div classfilter-bar Input v-modelkeyword placeholder搜索訂單號(hào) clearable on-enterhandleSearch / Button typeprimary clickhandleSearch查詢/Button /div PagedTable refpagedTable :columnscolumns :fetch-datafetchOrderList :query-params{ keyword, status } / /div /template script import PagedTable from /components/PagedTable export default { components: { PagedTable }, methods: { // 注意這個(gè)函數(shù)要保證 this 正確返回 { records, total } fetchOrderList({ page, pageSize, ...rest }) { return getOrderList({ page, pageSize, ...rest }) }, handleSearch() { this.$refs.pagedTable.reset() } } } /script這樣封裝的好處是業(yè)務(wù)頁(yè)面不再需要關(guān)心 currentPage、total、loading 這些狀態(tài)只需要關(guān)注接口怎么調(diào)、列怎么配。當(dāng)項(xiàng)目里列表變多時(shí)這種封裝的復(fù)利效應(yīng)會(huì)非常明顯。不過(guò)要注意封裝組件不要過(guò)度設(shè)計(jì)。如果你的項(xiàng)目只有兩個(gè)列表頁(yè)硬套這個(gè)組件反而增加了理解和維護(hù)成本。我在實(shí)際項(xiàng)目中通常先在兩個(gè)頁(yè)面里跑通這種寫(xiě)法覺(jué)得順了再抽成組件屬于先重復(fù)再抽象的節(jié)奏。8. 實(shí)測(cè)中容易忽略的性能與體驗(yàn)細(xì)節(jié)代碼能跑通只是第一步線上體驗(yàn)才是分頁(yè)的真正考場(chǎng)。這一章集中講我實(shí)測(cè)中重點(diǎn)注意的幾處性能與交互細(xì)節(jié)。8.1 大數(shù)據(jù)量下避免一次性渲染過(guò)多表格行即使走了服務(wù)端分頁(yè)如果 pageSize 設(shè)置成 100 甚至更大Table 要在一幀內(nèi)渲染 100 行乘以若干列的 DOM在低端設(shè)備上依然會(huì)產(chǎn)生明顯的白屏。比如你的報(bào)表頁(yè)允許用戶選擇每頁(yè) 200 條在移動(dòng)端或者性能一般的電腦上視覺(jué)上會(huì)感覺(jué)點(diǎn)了翻頁(yè)之后卡了半秒多。我建議開(kāi)發(fā)階段做一次性能壓測(cè)打開(kāi)瀏覽器的 Performance 面板把 pageSize 調(diào)到 100連續(xù)快速切換 5 頁(yè)觀察每一幀的耗時(shí)。如果 Long Task 超過(guò) 100ms就需要考慮控制 pageSize 上限比如最高 100或者引導(dǎo)用戶使用更高粒度的過(guò)濾條件來(lái)縮小結(jié)果集。8.2 快速翻頁(yè)時(shí)的節(jié)流策略前面 4.3 節(jié)用 requestSequence 解決了響應(yīng)順序錯(cuò)亂的問(wèn)題但如果你連頻繁點(diǎn)擊翻頁(yè)都不希望發(fā)生前端可以再加一層節(jié)流。最簡(jiǎn)單的方式是在handlePageChange里加一個(gè)時(shí)間鎖handlePageChange(page) { if (this.isFetching) return this.currentPage page this.loadTableData() }在loadTableData開(kāi)始和結(jié)束的地方分別把isFetching置為 true 和 false這樣在請(qǐng)求未返回時(shí)用戶點(diǎn)擊任何頁(yè)碼都會(huì)被忽略。這在操作頻繁的管理后臺(tái)里非常實(shí)用能顯著降低后端請(qǐng)求壓力。8.3 頁(yè)碼變化但總分頁(yè)數(shù)為 1 時(shí)的 UI 處理如果接口返回的 total 本來(lái)就是小于等于 pageSize 的值Page 組件會(huì)渲染出 1 頁(yè)。這沒(méi)問(wèn)題但如果同時(shí)開(kāi)啟了 show-sizer用戶把 pageSize 改大后total 可能依然不變。要注意 Page 組件的 total 始終是符合條件的總條數(shù)而不是當(dāng)前頁(yè)的總數(shù)?？倵l數(shù)不會(huì)因?yàn)楦?pageSize 而變化的。另外total 是提前知道還是請(qǐng)求返回才知道在服務(wù)端分頁(yè)中首次請(qǐng)求前 total 為空Page 組件渲染出來(lái)是空的這會(huì)造成一點(diǎn)布局抖動(dòng)。如果對(duì)布局穩(wěn)定性有要求可以給 Page 組件加一個(gè)初始 total 為 0并在 table 外層容器給一個(gè)最小高度。8.4 空數(shù)據(jù) vs 總數(shù)為 0 的文案區(qū)分表格數(shù)據(jù)為空時(shí)View UI 的 Table 默認(rèn)顯示暫無(wú)數(shù)據(jù)。但如果 total 為 0 且當(dāng)前頁(yè)為 1屬于正常空態(tài)如果 total 大于 0 但當(dāng)前頁(yè)數(shù)據(jù)為空說(shuō)明頁(yè)碼越界或存在臟數(shù)據(jù)。這兩種情況要分開(kāi)處理正?？諔B(tài)保持暫無(wú)數(shù)據(jù)不需要任何操作。頁(yè)碼越界空態(tài)觸發(fā)頁(yè)碼回退邏輯如第 7 章組件中的兜底策略并建議在控制臺(tái)打印一條日志方便排查是哪個(gè)環(huán)節(jié)造成的越界。我之前排查過(guò)一個(gè)線上問(wèn)題某個(gè)訂單列表在切換 Tab 后偶爾出現(xiàn)空白頁(yè)就是Tab 切換后保留了當(dāng)前第 8 頁(yè)的頁(yè)碼但新 Tab 的數(shù)據(jù)總量只有 3 頁(yè)導(dǎo)致的。加上頁(yè)碼回退邏輯后問(wèn)題直接消失。9. 最后再分享兩個(gè)小技巧第一個(gè)技巧關(guān)于請(qǐng)求參數(shù)的調(diào)試。服務(wù)端分頁(yè)的交互鏈路長(zhǎng)定位問(wèn)題時(shí)要學(xué)會(huì)用 curl 復(fù)現(xiàn) 的方法。在 Chrome 的 Network 面板里拿到分頁(yè)請(qǐng)求的完整 URL然后復(fù)制成 curl 命令在終端執(zhí)行看響應(yīng)結(jié)構(gòu)。這比在代碼里打斷點(diǎn)更直接能快速分清是前端參數(shù)問(wèn)題還是后端返回問(wèn)題。第二個(gè)技巧關(guān)于 Table 組件的行高一致性。分頁(yè)后表格每頁(yè)的渲染高度可能不同翻頁(yè)時(shí)頁(yè)面會(huì)出現(xiàn)跳動(dòng)?？梢栽?Table 外層設(shè)置一個(gè)固定最小高度比如把數(shù)據(jù)區(qū)域的 min-height 定為(pageSize 1) * 行高這樣翻頁(yè)時(shí)頁(yè)面不會(huì)突然變矮或變高。這個(gè)細(xì)節(jié)在小屏幕終端上特別明顯值得為它做一次適配。分頁(yè)這個(gè)功能說(shuō)難不難說(shuō)簡(jiǎn)單也絕不簡(jiǎn)單。核心還是想清楚數(shù)據(jù)流的來(lái)源與出口把前端展示狀態(tài)和服務(wù)端數(shù)據(jù)請(qǐng)求的邊界理干凈。配合 View UI 的 Table 和 Page 組件只要把頁(yè)碼狀態(tài)、查詢參數(shù)、請(qǐng)求競(jìng)態(tài)、邊界兜底這四件事處理扎實(shí)線上的分頁(yè)體驗(yàn)基本就能穩(wěn)住。希望這篇分享能幫你少踩幾個(gè)坑。 View UI Table 與 Page 組件分頁(yè)實(shí)戰(zhàn)：前端分頁(yè)與服務(wù)端分頁(yè)完整指南
1. 分頁(yè)到底在解決什么問(wèn)題先想清楚場(chǎng)景再動(dòng)手先講個(gè)現(xiàn)象。我見(jiàn)過(guò)不少剛接觸 View UI以前叫 iView的開(kāi)發(fā)者拿到 Table 和 Page 組件后第一件事就是照著文檔抄一遍代碼抄完發(fā)現(xiàn)表格能顯示數(shù)據(jù)、頁(yè)碼也能點(diǎn)以為萬(wàn)事大吉。結(jié)果一上生產(chǎn)環(huán)境就出問(wèn)題數(shù)據(jù)量到了幾千條頁(yè)面直接卡頓、翻頁(yè)時(shí)請(qǐng)求重復(fù)發(fā)送、搜索之后頁(yè)碼還停留在舊位置、刪掉當(dāng)前頁(yè)最后一條數(shù)據(jù)后表格變成空白頁(yè)……每一個(gè)都是線上事故級(jí)別的體驗(yàn)問(wèn)題。其實(shí)分頁(yè)這件事本質(zhì)上不是把數(shù)據(jù)切開(kāi)一頁(yè)頁(yè)展示那么簡(jiǎn)單它背后有兩層邏輯一是減少單次渲染的數(shù)據(jù)量二是把展示狀態(tài)和業(yè)務(wù)狀態(tài)解耦。你不把這兩層想清楚寫(xiě)出來(lái)的分頁(yè)代碼永遠(yuǎn)是在打補(bǔ)丁。用 View UI 的 Table 和 Page 組合做分頁(yè)是 Vue 生態(tài)里很經(jīng)典的一套方案。Table 負(fù)責(zé)展示數(shù)據(jù)Page 負(fù)責(zé)提供交互入口兩者通過(guò) data 和事件串聯(lián)起來(lái)。這套組合在我的項(xiàng)目里用了很多年今天把完整思路、踩過(guò)的坑、以及封裝成通用組件的方案一次性寫(xiě)完希望能幫你省掉一些不必要的折騰。先說(shuō)基礎(chǔ)概念方便后面統(tǒng)一語(yǔ)言current / currentPage當(dāng)前頁(yè)碼從 1 開(kāi)始。pageSize / page-size每頁(yè)顯示條數(shù)。total數(shù)據(jù)總條數(shù)。dataTable 當(dāng)前頁(yè)實(shí)際要渲染的數(shù)據(jù)數(shù)組。on-changePage 組件頁(yè)碼變化時(shí)觸發(fā)的回調(diào)函數(shù)。2. 前端分頁(yè)還是服務(wù)端分頁(yè)這個(gè)選擇題決定代碼結(jié)構(gòu)很多人在第一步就選錯(cuò)了方向。我接到過(guò)的分頁(yè)相關(guān)咨詢里至少有一半人分不清前端分頁(yè)和服務(wù)端分頁(yè)該在什么場(chǎng)景下用。這里直接給結(jié)論數(shù)據(jù)量小幾百到一千條以內(nèi)且一次性從接口拿全量數(shù)據(jù)用前端分頁(yè)。數(shù)據(jù)量大幾千條以上或者接口本身就支持分頁(yè)參數(shù)用服務(wù)端分頁(yè)。什么情況下前端分頁(yè)會(huì)出問(wèn)題舉個(gè)例子一次接口返回 5000 條數(shù)據(jù)你把它們?nèi)M(jìn) Table雖然 Table 會(huì)一次性渲染出所有行但 Page 組件的頁(yè)碼計(jì)算、瀏覽器 DOM 節(jié)點(diǎn)數(shù)量、重排重繪帶來(lái)的性能消耗都會(huì)讓你在低端設(shè)備上體驗(yàn)到明顯的卡頓。更嚴(yán)重的是如果表格列的字段很多5000 行乘以 10 列那就是 5 萬(wàn)個(gè)單元格瀏覽器直接崩給你看。服務(wù)端分頁(yè)則是把當(dāng)前頁(yè)顯示哪些數(shù)據(jù)這個(gè)責(zé)任交給后端前端只告訴后端我要第幾頁(yè)、每頁(yè)多少條后端返回當(dāng)前頁(yè)的數(shù)據(jù)和總數(shù)。這種方式的優(yōu)點(diǎn)是前端性能壓力小缺點(diǎn)是每次翻頁(yè)都要等網(wǎng)絡(luò)請(qǐng)求交互上必須處理好 loading 狀態(tài)和錯(cuò)誤重試。我個(gè)人的判斷標(biāo)準(zhǔn)很簡(jiǎn)單如果接口返回的數(shù)據(jù)總量超過(guò) 1000 條或者接口本身已經(jīng)給了 page 和 size 參數(shù)就毫不猶豫走服務(wù)端分頁(yè)。分頁(yè)的本質(zhì)是數(shù)據(jù)訪問(wèn)的邊界控制這個(gè)邊界越靠前系統(tǒng)的可擴(kuò)展性越好。下面這張表是我選型時(shí)的常用參考標(biāo)準(zhǔn)供你直接抄作業(yè)對(duì)比維度前端分頁(yè)服務(wù)端分頁(yè)數(shù)據(jù)量建議1000 條以內(nèi)任意數(shù)量尤其適合大數(shù)據(jù)量接口請(qǐng)求次數(shù)1 次頁(yè)面加載時(shí)每次翻頁(yè) 1 次交互響應(yīng)速度快無(wú)網(wǎng)絡(luò)等待慢依賴網(wǎng)絡(luò)延遲加載狀態(tài)處理基本不需要必須處理后端改動(dòng)無(wú)需要支持分頁(yè)參數(shù)維護(hù)成本低中推薦場(chǎng)景數(shù)據(jù)字典、配置列表、報(bào)表預(yù)覽用戶列表、訂單列表、操作日志3. Table 和 Page 的基礎(chǔ)組合從一份能跑通的代碼說(shuō)起確定了分頁(yè)方式后我們直接寫(xiě)代碼。這里先用一份前端分頁(yè)的完整示例來(lái)拆解核心邏輯因?yàn)樗拇a鏈路最短最適合理解 Table 和 Page 的協(xié)作關(guān)系。假設(shè)我們從接口拿回一份 200 條數(shù)據(jù)的用戶列表每頁(yè)顯示 10 條需要在表格底部用 Page 組件控制翻頁(yè)。先看完整代碼template div classuser-list Table :columnscolumns :datapageData stripe/Table Page :totalmockData.length :currentcurrentPage :page-sizepageSize show-total on-changehandlePageChange stylemargin-top: 16px; text-align: right / /div /template script export default { name: UserList, data() { return { columns: [ { title: ID, key: id, width: 80 }, { title: 姓名, key: name, minWidth: 120 }, { title: 郵箱, key: email, minWidth: 200 }, { title: 創(chuàng)建時(shí)間, key: created_at, minWidth: 180 } ], // 模擬全量數(shù)據(jù)實(shí)際場(chǎng)景中來(lái)自接口 mockData: [], currentPage: 1, pageSize: 10 } }, computed: { pageData() { const start (this.currentPage - 1) * this.pageSize const end start this.pageSize return this.mockData.slice(start, end) } }, created() { this.loadMockData() }, methods: { async loadMockData() { // 模擬接口請(qǐng)求 const res await fetch(/api/user/list) this.mockData await res.json() }, handlePageChange(page) { this.currentPage page } } } /script這套代碼的核心邏輯只有三步全量數(shù)據(jù)存在 mockData 里作為分頁(yè)的數(shù)據(jù)源。computed 里的 pageData 負(fù)責(zé)切頁(yè)根據(jù)當(dāng)前頁(yè)碼和每頁(yè)條數(shù)動(dòng)態(tài)算出當(dāng)前頁(yè)該顯示哪些數(shù)據(jù)。Page 組件的 on-change 事件負(fù)責(zé)更新 currentPagepageData 隨之重新計(jì)算表格自動(dòng)刷新。這里有個(gè)關(guān)鍵設(shè)計(jì)Table 綁定的是pageData而不是mockData。這個(gè)slice的動(dòng)作就是前端分頁(yè)的核心它保證了 Table 每次只拿到 10 條數(shù)據(jù)而不是把 200 條全部渲染出來(lái)。這樣做的直接好處是 DOM 節(jié)點(diǎn)數(shù)量大幅減少頁(yè)面重排開(kāi)銷(xiāo)明顯下降。但如果你只看到了這一步那還沒(méi)入門(mén)。我前兩年接手過(guò)一個(gè)項(xiàng)目同事把這段邏輯寫(xiě)成了handlePageChange(page) { this.mockData this.mockData.slice(page * 10) // 錯(cuò)誤寫(xiě)法 }他以為翻頁(yè)就是把數(shù)據(jù)切掉一段結(jié)果翻到第 3 頁(yè)后每翻一次數(shù)據(jù)就少掉一部分再往回翻全亂了。正確做法永遠(yuǎn)是保留全量數(shù)據(jù)源用計(jì)算屬性去切當(dāng)前頁(yè)而不是去修改數(shù)據(jù)源本身。數(shù)據(jù)源是全集當(dāng)前頁(yè)是視圖這個(gè)邊界不能破。4. 服務(wù)端分頁(yè)的完整鏈路參數(shù)、loading、競(jìng)態(tài)控制一次說(shuō)清服務(wù)端分頁(yè)是實(shí)際業(yè)務(wù)中占比最高的形態(tài)因?yàn)樗苷嬲鉀Q大數(shù)據(jù)量場(chǎng)景下的性能瓶頸。我用一個(gè)訂單列表的案例來(lái)講透完整鏈路。4.1 請(qǐng)求參數(shù)的組裝服務(wù)端分頁(yè)的第一件事是把分頁(yè)參數(shù)傳給接口。View UI 的 Page 組件在頁(yè)碼變化時(shí)觸發(fā)on-change這個(gè)回調(diào)參數(shù)就是新的頁(yè)碼我們需要把它同步給后端。這里要注意字段名對(duì)齊的問(wèn)題。不同后端團(tuán)隊(duì)定義的分頁(yè)參數(shù)不一樣有的用pageNum、pageSize有的用page、limit還有的用current、size。建議前端在封裝請(qǐng)求層時(shí)統(tǒng)一做一層參數(shù)轉(zhuǎn)換不要在每個(gè)頁(yè)面里散落各種字段名。我在項(xiàng)目中通常這樣處理methods: { buildPageParams() { return { page: this.currentPage, // 頁(yè)碼從 1 開(kāi)始 pageSize: this.pageSize, // 每頁(yè)條數(shù) // 其他查詢條件... keyword: this.keyword, status: this.status } }, async fetchOrderList() { this.loading true try { const params this.buildPageParams() const res await getOrderList(params) this.tableData res.data.records || [] this.total res.data.total } catch (error) { // 統(tǒng)一錯(cuò)誤處理 this.$Message.error(訂單列表加載失敗) } finally { this.loading false } } }這里有個(gè)非常容易踩的坑接口返回的字段名不一致。有的后端返回{ list: [], totalCount: 100 }有的返回{ rows: [], total: 100 }還有的包裝成{ data: { records: [], total: 0 } }。建議把接口返回結(jié)構(gòu)統(tǒng)一收斂到一個(gè)normalizeResponse方法里把字段名都轉(zhuǎn)換成語(yǔ)義明確的內(nèi)部結(jié)構(gòu)。4.2 頁(yè)碼變化時(shí)的完整邏輯服務(wù)端分頁(yè)的handlePageChange不能像前端分頁(yè)那樣只更新一個(gè)頁(yè)碼變量它要觸發(fā)重新請(qǐng)求數(shù)據(jù)async handlePageChange(page) { if (page this.currentPage) return this.currentPage page await this.fetchOrderList() }這段代碼看似簡(jiǎn)單實(shí)際生產(chǎn)環(huán)境里還會(huì)遇到更多情況我展開(kāi)講三個(gè)我反復(fù)踩過(guò)的坑。4.3 競(jìng)態(tài)問(wèn)題快速翻頁(yè)時(shí)響應(yīng)順序會(huì)錯(cuò)亂這是我在真實(shí)項(xiàng)目中遇到的最隱蔽的 bug。用戶快速點(diǎn)擊下一頁(yè)、下一頁(yè)、下一頁(yè)前端會(huì)發(fā)出三個(gè)并發(fā)的異步請(qǐng)求。由于網(wǎng)絡(luò)延遲不同先發(fā)的請(qǐng)求未必先返回。如果最后一次點(diǎn)擊的響應(yīng)先回來(lái)了把表格數(shù)據(jù)更新為第 3 頁(yè)的內(nèi)容但緊接著第一次點(diǎn)擊的響應(yīng)才姍姍來(lái)遲又把表格覆蓋成第 1 頁(yè)的內(nèi)容——而此時(shí)的頁(yè)碼按鈕卻停留在第 3 頁(yè)。數(shù)據(jù)和頁(yè)碼錯(cuò)位用戶看到的就是頁(yè)碼是 3表格內(nèi)容卻是第一頁(yè)的靈異現(xiàn)象。解決方式有幾種我推薦用一個(gè)簡(jiǎn)單的請(qǐng)求序號(hào)標(biāo)記methods: { async fetchOrderList() { const requestId this.requestSequence // 每次請(qǐng)求自增 this.loading true try { const res await getOrderList(this.buildPageParams()) // 如果已經(jīng)不是最新的請(qǐng)求直接丟棄這次結(jié)果 if (requestId ! this.requestSequence) return this.tableData res.data.records this.total res.data.total } finally { if (requestId this.requestSequence) { this.loading false } } } }原理就是每次請(qǐng)求前用一個(gè)自增序號(hào)標(biāo)記這是第幾個(gè)請(qǐng)求當(dāng)響應(yīng)回來(lái)時(shí)如果當(dāng)前的序號(hào)已經(jīng)不是自己發(fā)出的那次了說(shuō)明有更新的請(qǐng)求已經(jīng)發(fā)出這次舊響應(yīng)直接丟棄不再更新數(shù)據(jù)。這個(gè)方法比axios的CancelToken更輕量也不需要額外引入庫(kù)已經(jīng)足夠應(yīng)對(duì)大部分業(yè)務(wù)場(chǎng)景。4.4 loading 狀態(tài)的正確打開(kāi)方式服務(wù)端分頁(yè)必須處理 loading因?yàn)榉?yè)時(shí)有一段網(wǎng)絡(luò)空白期。不處理的話用戶翻頁(yè)后會(huì)看到表格內(nèi)容停留在舊數(shù)據(jù)上容易誤以為是不是自己點(diǎn)錯(cuò)了。View UI 的 Table 組件自帶一個(gè)loading屬性傳入布爾值即可Table :columnscolumns :datatableData :loadingloading/Table翻頁(yè)的時(shí)候建議使用 Page 組件的on-change回調(diào)里第一時(shí)間把 loading 置為 true并在請(qǐng)求 finally 中置為 false。這樣可以保證翻頁(yè)交互期間表格上方出現(xiàn) loading 遮罩避免用戶誤操作。4.5 總數(shù)獲取與展示Page 組件的total屬性是數(shù)據(jù)總條數(shù)不是總頁(yè)數(shù)。它需要從接口返回的 total 字段中獲取。很多人初學(xué)時(shí)會(huì)犯一個(gè)錯(cuò)誤把total設(shè)置為當(dāng)頁(yè)返回的數(shù)據(jù)條數(shù)導(dǎo)致 Page 組件永遠(yuǎn)只有一頁(yè)。這個(gè)坑我見(jiàn)得太多了必須單獨(dú)拎出來(lái)說(shuō)。接口返回的 total 是服務(wù)端根據(jù)查詢條件統(tǒng)計(jì)出來(lái)的完整數(shù)據(jù)量Page 組件拿到 total 后自己會(huì)計(jì)算總頁(yè)數(shù)并在頁(yè)碼欄右側(cè)渲染出共 X 條的文字配合show-total屬性。5. 合并查詢條件的分頁(yè)搜索、頁(yè)碼重置、參數(shù)同步一個(gè)都不能少真實(shí)項(xiàng)目里表格分頁(yè)幾乎總是和搜索條件綁在一起的。這一章的坑比基礎(chǔ)分頁(yè)多得多值得單獨(dú)開(kāi)一節(jié)來(lái)說(shuō)。5.1 搜索時(shí)頁(yè)碼必須重置到第一頁(yè)這是一個(gè)看起來(lái)是小事、做錯(cuò)了就是事故的點(diǎn)。假設(shè)用戶正在瀏覽第 8 頁(yè)的數(shù)據(jù)此時(shí)他在搜索框里輸入了新的關(guān)鍵詞點(diǎn)擊查詢按鈕。如果查詢邏輯只是簡(jiǎn)單地把tableData重新賦值為新接口的返回結(jié)果而currentPage還停留在 8會(huì)出現(xiàn)兩種情況接口返回的是第 8 頁(yè)的數(shù)據(jù)但符合條件的數(shù)據(jù)總共可能只有 2 頁(yè)前端拿到的就是第 8 頁(yè)不存在的數(shù)據(jù)——往往是空數(shù)組。即使后端對(duì)超出總頁(yè)數(shù)的頁(yè)碼做了容錯(cuò)返回最后一頁(yè)用戶體驗(yàn)依然是混亂的我明明搜的是新關(guān)鍵詞為什么頁(yè)碼還停在第 8正確做法是搜索條件變化時(shí)把 currentPage 重置為 1同時(shí)把查詢參數(shù)傳給后端。handleSearch() { this.currentPage 1 this.fetchOrderList() }如果把搜索框和頁(yè)碼聯(lián)動(dòng)封裝到一個(gè)統(tǒng)一的handleQuery方法里還可以進(jìn)一步簡(jiǎn)化handleQuery(resetPage true) { if (resetPage) { this.currentPage 1 } this.fetchOrderList() }5.2 查詢參數(shù)的深拷貝陷阱前端傳搜索條件給后端時(shí)如果直接把響應(yīng)綁定的對(duì)象傳給請(qǐng)求函數(shù)這些參數(shù)對(duì)象其實(shí)是 Vue 的響應(yīng)式代理內(nèi)部帶著各種 getter/setter。在序列化傳輸時(shí)某些情況下會(huì)出現(xiàn)參數(shù)丟失或附加多余字段的問(wèn)題。具體表現(xiàn)是搜索條件明明在界面上看得見(jiàn)但后端收到的請(qǐng)求參數(shù)里卻沒(méi)有。這個(gè)坑在 axios 結(jié)合 Vue 2 的響應(yīng)式系統(tǒng)時(shí)偶有發(fā)生排查起來(lái)非常隱蔽。我的建議是組裝請(qǐng)求參數(shù)時(shí)使用一個(gè)新對(duì)象buildPageParams() { return { page: this.currentPage, pageSize: this.pageSize, keyword: this.keyword ? this.keyword.trim() : , status: this.status, dateRange: this.dateRange ? [...this.dateRange] : [] } }不要直接把this.searchForm整個(gè)傳給請(qǐng)求函數(shù)而是手動(dòng)選取需要的字段組裝新對(duì)象。這樣既避免了響應(yīng)式代理的序列化坑也讓請(qǐng)求參數(shù)變得可控和可調(diào)試。5.3 搜索后頁(yè)碼是保留了但查詢參數(shù)對(duì)不上還有一種常見(jiàn) bug搜索關(guān)鍵詞為 A結(jié)果用戶翻頁(yè)時(shí)把關(guān)鍵詞改成了 B然后點(diǎn)下一頁(yè)請(qǐng)求參數(shù)卻是關(guān)鍵詞 B 第 2 頁(yè)。如果后端不校驗(yàn)頁(yè)碼和查詢條件組合的合法性就會(huì)返回一個(gè)混合結(jié)果。這個(gè)問(wèn)題的根源在于頁(yè)碼和關(guān)鍵詞是兩個(gè)來(lái)源不同、更新時(shí)機(jī)不同的狀態(tài)。解決思路是在翻頁(yè)回調(diào)時(shí)確保用的是當(dāng)前最新的查詢條件async handlePageChange(page) { this.currentPage page await this.fetchOrderList() }只要fetchOrderList每次讀取的是最新的this.keyword、this.status等數(shù)據(jù)而不是在搜索那一刻就拍扁的快照這個(gè)問(wèn)題就不會(huì)出現(xiàn)。所以組裝請(qǐng)求參數(shù)時(shí)務(wù)必在請(qǐng)求方法內(nèi)動(dòng)態(tài)讀取組件狀態(tài)而不是在某個(gè)初始化階段把參數(shù)固化下來(lái)。6. 邊界場(chǎng)景與真實(shí)事故復(fù)盤(pán)刪除、編輯后頁(yè)碼漂移怎么處理分頁(yè)代碼寫(xiě)完之后考驗(yàn)功力的是邊界場(chǎng)景。這部分內(nèi)容網(wǎng)上很難找到系統(tǒng)性總結(jié)大多是從一次次的線上問(wèn)題里摸爬滾打出來(lái)的在這里一并分享。6.1 刪除當(dāng)前頁(yè)最后一條數(shù)據(jù)后的頁(yè)碼回退假設(shè)當(dāng)前是第 3 頁(yè)每頁(yè) 10 條這頁(yè)有 3 條數(shù)據(jù)。用戶刪掉了其中 2 條此時(shí)第 3 頁(yè)可能只剩下 1 條數(shù)據(jù)甚至刪掉最后一條后整頁(yè)變空。如果你只是簡(jiǎn)單刷新當(dāng)前頁(yè)表格很可能顯示暫無(wú)數(shù)據(jù)而實(shí)際上前面還有第 1、2 頁(yè)的數(shù)據(jù)。用戶會(huì)以為數(shù)據(jù)被刪光了實(shí)際上是被空頁(yè)給擋住了。我的經(jīng)驗(yàn)是刪除后重新請(qǐng)求數(shù)據(jù)并且根據(jù)返回的總數(shù)判斷當(dāng)前頁(yè)碼是否越界。更穩(wěn)妥的做法是先刪數(shù)據(jù)成功后重新請(qǐng)求總數(shù)如果當(dāng)前頁(yè)的起始索引大于等于總數(shù)就把頁(yè)碼回退一頁(yè)。async handleDelete(row) { const success await deleteOrder(row.id) if (!success) return // 重新拉取數(shù)據(jù)判斷頁(yè)碼是否需要回退 await this.fetchOrderList() const maxPage Math.max(1, Math.ceil(this.total / this.pageSize)) if (this.currentPage maxPage) { this.currentPage maxPage await this.fetchOrderList() } }注意判斷條件是currentPage maxPage而不是簡(jiǎn)單的total 0。因?yàn)榭赡艹霈F(xiàn)當(dāng)前頁(yè) 5 條刪了 1 條還剩 4 條的情況不需要回退但如果是當(dāng)前頁(yè)最后一條被刪就必須往回退一頁(yè)否則用戶就看不到前面的數(shù)據(jù)了。6.2 編輯數(shù)據(jù)后必須當(dāng)前頁(yè)碼重新拉取編輯場(chǎng)景和刪除不一樣用戶在第 2 頁(yè)編輯了一條數(shù)據(jù)保存后如果直接跳到第一頁(yè)重查用戶的閱讀位置就丟了體驗(yàn)很糟糕。正確做法是停留在當(dāng)前頁(yè)碼重新拉取數(shù)據(jù)。async handleEditSave(formData) { await updateOrder(formData) await this.fetchOrderList() // 保持 currentPage 不變 }這樣既刷新了表格內(nèi)容也保留了用戶的瀏覽位置。這里要特別提醒編輯成功后不要順手把 currentPage 重置為 1除非業(yè)務(wù)方明確要求編輯后回到第一頁(yè)。很多產(chǎn)品經(jīng)理不會(huì)明說(shuō)這個(gè)細(xì)節(jié)但作為開(kāi)發(fā)你要有判斷力。6.3 多 Tab 切換后分頁(yè)狀態(tài)的保持與重置如果頁(yè)面里用了 Tabs 組件每個(gè) Tab 都是一個(gè)列表每個(gè)列表都有獨(dú)立的分頁(yè)狀態(tài)。這里有個(gè)微妙的設(shè)計(jì)取舍有的產(chǎn)品希望切換 Tab 后保留每個(gè) Tab 的頁(yè)碼方便用戶回來(lái)繼續(xù)看。有的產(chǎn)品希望切換 Tab 后重置為第一頁(yè)認(rèn)為用戶重新進(jìn)入某個(gè) Tab 就是一次新的瀏覽。我建議在data中為每個(gè) Tab 維護(hù)獨(dú)立的分頁(yè)狀態(tài)而不是共用一個(gè)currentPagedata() { return { pagerMap: { tabA: { currentPage: 1, pageSize: 10, total: 0 }, tabB: { currentPage: 1, pageSize: 10, total: 0 } }, activeTab: tabA } }, computed: { activePager() { return this.pagerMap[this.activeTab] } }這樣每個(gè) Tab 的頁(yè)碼互不干擾切換回來(lái)時(shí)用戶能回到原來(lái)的位置。滿足 保留瀏覽位置 這一體驗(yàn)要求。6.4 Page 組件尺寸和顯示優(yōu)化的幾個(gè)細(xì)節(jié)View UI 的 Page 組件在業(yè)務(wù)中的使用頻率很高有幾個(gè)屬性配置建議直接借鑒show-total在左側(cè)顯示共 X 條比單獨(dú)放一行文字更直觀。show-elevator顯示跳頁(yè)輸入框數(shù)據(jù)量大、頁(yè)碼多時(shí)很有用。show-sizer顯示每頁(yè)條數(shù)選擇器讓用戶自主調(diào)整 pageSize。placement在有 show-sizer 且組件空間受限時(shí)可以通過(guò) placement 控制 poptip 彈出方向。加上這些屬性后的基礎(chǔ)寫(xiě)法Page :totaltotal :currentcurrentPage :page-sizepageSize show-total show-elevator show-sizer :page-size-opts[10, 20, 50, 100] on-changehandlePageChange on-page-size-changehandlePageSizeChange /6.5 pageSize 切換時(shí)也要回到第一頁(yè)當(dāng)用戶通過(guò) show-sizer 將每頁(yè)條數(shù)從 10 改成 50 時(shí)當(dāng)前頁(yè)碼不能保持原樣。舉個(gè)例子用戶在 10 條/頁(yè)時(shí)停留在第 8 頁(yè)此時(shí)改成 50 條/頁(yè)第 8 頁(yè)其實(shí)只對(duì)應(yīng)原來(lái)的第 5 頁(yè)左右數(shù)據(jù)內(nèi)容會(huì)完全錯(cuò)位。必須把頁(yè)碼重置為 1 再重新查詢才能保證展示邏輯自洽handlePageSizeChange(newSize) { this.pageSize newSize this.currentPage 1 this.fetchOrderList() }7. 封裝一個(gè)通用分頁(yè)表格組件把重復(fù)勞動(dòng)一次解決當(dāng)一個(gè)項(xiàng)目里有十幾個(gè)列表頁(yè)都需要分頁(yè)時(shí)每次都復(fù)制粘貼currentPage、pageSize、total、loading、fetchXxx這五件套會(huì)非常痛苦。我在實(shí)際項(xiàng)目中會(huì)封裝一個(gè)通用組件PagedTable把 Table 和 Page 的組合邏輯收納進(jìn)去業(yè)務(wù)頁(yè)面只關(guān)心怎么取數(shù)。7.1 組件設(shè)計(jì)思路組件的核心設(shè)計(jì)是讓父組件決定數(shù)據(jù)從哪來(lái)讓子組件統(tǒng)一管理分頁(yè)狀態(tài)和交互。我選擇用「?jìng)魅胍粋€(gè)返回 Promise 的取數(shù)函數(shù) 查詢參數(shù)對(duì)象」這樣的組合方式template div classpaged-table Table :columnscolumns :datatableData :loadingloading v-bind$attrs / div classpaged-table__footer Page :totaltotal :currentcurrentPage :page-sizepageSize show-total show-elevator show-sizer :page-size-optspageSizeOpts on-changehandlePageChange on-page-size-changehandlePageSizeChange / /div /div /template組件的 props 可以這樣設(shè)計(jì)屬性名類型說(shuō)明columnsArray表格列配置fetchDataFunction接收分頁(yè)參數(shù)返回 PromisequeryParamsObject查詢條件對(duì)象pageSizeNumber每頁(yè)條數(shù)默認(rèn) 10pageSizeOptsArray可選的每頁(yè)條數(shù)列表immediateLoadBoolean是否創(chuàng)建時(shí)立即加載組件的核心邏輯要感知查詢參數(shù)的變化當(dāng)父組件傳入的queryParams變化時(shí)自動(dòng)重置頁(yè)碼并重新請(qǐng)求數(shù)據(jù)。這一步可以通過(guò)在組件內(nèi)監(jiān)聽(tīng)watch: { queryParams: { deep: true, handler() { this.currentPage 1 this.loadTableData() } } }這里有個(gè)細(xì)節(jié)deep: true的成本不低如果項(xiàng)目中有大量這樣的組件同時(shí)監(jiān)聽(tīng)對(duì)象會(huì)有性能壓力。我的做法是在業(yè)務(wù)頁(yè)面主動(dòng)調(diào)用組件的reload()方法來(lái)替代深監(jiān)聽(tīng)見(jiàn)下方的 7.3 小節(jié)。7.2 組件的完整邏輯實(shí)現(xiàn)下面是我在項(xiàng)目中使用過(guò)的完整PagedTable業(yè)務(wù)組件實(shí)現(xiàn)。它是一個(gè)「行為收斂」的封裝適用于基于 Promise 接口的中后臺(tái) CRUD 列表場(chǎng)景。export default { name: PagedTable, props: { columns: { type: Array, required: true }, fetchData: { type: Function, required: true }, queryParams: { type: Object, default: () ({}) }, defaultPageSize: { type: Number, default: 10 }, pageSizeOpts: { type: Array, default: () [10, 20, 50, 100] }, immediateLoad: { type: Boolean, default: true } }, data() { return { tableData: [], total: 0, currentPage: 1, pageSize: this.defaultPageSize, loading: false, requestSequence: 0 } }, created() { if (this.immediateLoad) { this.loadTableData() } }, methods: { async loadTableData() { const requestId this.requestSequence this.loading true try { const res await this.fetchData({ page: this.currentPage, pageSize: this.pageSize, ...this.queryParams }) if (requestId ! this.requestSequence) return this.tableData res.records this.total res.total // 額外處理若當(dāng)前頁(yè)已經(jīng)被刪空自動(dòng)回退頁(yè)碼 if (this.tableData.length 0 this.currentPage 1) { this.currentPage - 1 return this.loadTableData() } } catch (e) { this.$Message.error(數(shù)據(jù)加載失敗) } finally { if (requestId this.requestSequence) { this.loading false } } }, handlePageChange(page) { this.currentPage page this.loadTableData() }, handlePageSizeChange(size) { this.pageSize size this.currentPage 1 this.loadTableData() }, reload() { this.loadTableData() }, reset() { this.currentPage 1 this.loadTableData() } } }在「當(dāng)前頁(yè)已被刪空」的處理上我在前面 6.1 小節(jié)提到的是「刪除后判斷頁(yè)碼是否越界再回退」而封裝組件時(shí)我傾向于用更穩(wěn)的兜底策略如果接口返回的當(dāng)前頁(yè)數(shù)據(jù)為空且當(dāng)前頁(yè)碼大于 1就自動(dòng)往前退一頁(yè)并重新加載。這樣即使是批量刪除、排序后行數(shù)變化、多端同時(shí)操作導(dǎo)致的數(shù)據(jù)量突變也能自動(dòng)修正頁(yè)碼不會(huì)出現(xiàn)空白頁(yè)。7.3 父組件怎么用這個(gè)組件父組件里只需要把取數(shù)函數(shù)和查詢條件對(duì)象傳進(jìn)去template div div classfilter-bar Input v-modelkeyword placeholder搜索訂單號(hào) clearable on-enterhandleSearch / Button typeprimary clickhandleSearch查詢/Button /div PagedTable refpagedTable :columnscolumns :fetch-datafetchOrderList :query-params{ keyword, status } / /div /template script import PagedTable from /components/PagedTable export default { components: { PagedTable }, methods: { // 注意這個(gè)函數(shù)要保證 this 正確返回 { records, total } fetchOrderList({ page, pageSize, ...rest }) { return getOrderList({ page, pageSize, ...rest }) }, handleSearch() { this.$refs.pagedTable.reset() } } } /script這樣封裝的好處是業(yè)務(wù)頁(yè)面不再需要關(guān)心 currentPage、total、loading 這些狀態(tài)只需要關(guān)注接口怎么調(diào)、列怎么配。當(dāng)項(xiàng)目里列表變多時(shí)這種封裝的復(fù)利效應(yīng)會(huì)非常明顯。不過(guò)要注意封裝組件不要過(guò)度設(shè)計(jì)。如果你的項(xiàng)目只有兩個(gè)列表頁(yè)硬套這個(gè)組件反而增加了理解和維護(hù)成本。我在實(shí)際項(xiàng)目中通常先在兩個(gè)頁(yè)面里跑通這種寫(xiě)法覺(jué)得順了再抽成組件屬于先重復(fù)再抽象的節(jié)奏。8. 實(shí)測(cè)中容易忽略的性能與體驗(yàn)細(xì)節(jié)代碼能跑通只是第一步線上體驗(yàn)才是分頁(yè)的真正考場(chǎng)。這一章集中講我實(shí)測(cè)中重點(diǎn)注意的幾處性能與交互細(xì)節(jié)。8.1 大數(shù)據(jù)量下避免一次性渲染過(guò)多表格行即使走了服務(wù)端分頁(yè)如果 pageSize 設(shè)置成 100 甚至更大Table 要在一幀內(nèi)渲染 100 行乘以若干列的 DOM在低端設(shè)備上依然會(huì)產(chǎn)生明顯的白屏。比如你的報(bào)表頁(yè)允許用戶選擇每頁(yè) 200 條在移動(dòng)端或者性能一般的電腦上視覺(jué)上會(huì)感覺(jué)點(diǎn)了翻頁(yè)之后卡了半秒多。我建議開(kāi)發(fā)階段做一次性能壓測(cè)打開(kāi)瀏覽器的 Performance 面板把 pageSize 調(diào)到 100連續(xù)快速切換 5 頁(yè)觀察每一幀的耗時(shí)。如果 Long Task 超過(guò) 100ms就需要考慮控制 pageSize 上限比如最高 100或者引導(dǎo)用戶使用更高粒度的過(guò)濾條件來(lái)縮小結(jié)果集。8.2 快速翻頁(yè)時(shí)的節(jié)流策略前面 4.3 節(jié)用 requestSequence 解決了響應(yīng)順序錯(cuò)亂的問(wèn)題但如果你連頻繁點(diǎn)擊翻頁(yè)都不希望發(fā)生前端可以再加一層節(jié)流。最簡(jiǎn)單的方式是在handlePageChange里加一個(gè)時(shí)間鎖handlePageChange(page) { if (this.isFetching) return this.currentPage page this.loadTableData() }在loadTableData開(kāi)始和結(jié)束的地方分別把isFetching置為 true 和 false這樣在請(qǐng)求未返回時(shí)用戶點(diǎn)擊任何頁(yè)碼都會(huì)被忽略。這在操作頻繁的管理后臺(tái)里非常實(shí)用能顯著降低后端請(qǐng)求壓力。8.3 頁(yè)碼變化但總分頁(yè)數(shù)為 1 時(shí)的 UI 處理如果接口返回的 total 本來(lái)就是小于等于 pageSize 的值Page 組件會(huì)渲染出 1 頁(yè)。這沒(méi)問(wèn)題但如果同時(shí)開(kāi)啟了 show-sizer用戶把 pageSize 改大后total 可能依然不變。要注意 Page 組件的 total 始終是符合條件的總條數(shù)而不是當(dāng)前頁(yè)的總數(shù)?？倵l數(shù)不會(huì)因?yàn)楦?pageSize 而變化的。另外total 是提前知道還是請(qǐng)求返回才知道在服務(wù)端分頁(yè)中首次請(qǐng)求前 total 為空Page 組件渲染出來(lái)是空的這會(huì)造成一點(diǎn)布局抖動(dòng)。如果對(duì)布局穩(wěn)定性有要求可以給 Page 組件加一個(gè)初始 total 為 0并在 table 外層容器給一個(gè)最小高度。8.4 空數(shù)據(jù) vs 總數(shù)為 0 的文案區(qū)分表格數(shù)據(jù)為空時(shí)View UI 的 Table 默認(rèn)顯示暫無(wú)數(shù)據(jù)。但如果 total 為 0 且當(dāng)前頁(yè)為 1屬于正常空態(tài)如果 total 大于 0 但當(dāng)前頁(yè)數(shù)據(jù)為空說(shuō)明頁(yè)碼越界或存在臟數(shù)據(jù)。這兩種情況要分開(kāi)處理正?？諔B(tài)保持暫無(wú)數(shù)據(jù)不需要任何操作。頁(yè)碼越界空態(tài)觸發(fā)頁(yè)碼回退邏輯如第 7 章組件中的兜底策略并建議在控制臺(tái)打印一條日志方便排查是哪個(gè)環(huán)節(jié)造成的越界。我之前排查過(guò)一個(gè)線上問(wèn)題某個(gè)訂單列表在切換 Tab 后偶爾出現(xiàn)空白頁(yè)就是Tab 切換后保留了當(dāng)前第 8 頁(yè)的頁(yè)碼但新 Tab 的數(shù)據(jù)總量只有 3 頁(yè)導(dǎo)致的。加上頁(yè)碼回退邏輯后問(wèn)題直接消失。9. 最后再分享兩個(gè)小技巧第一個(gè)技巧關(guān)于請(qǐng)求參數(shù)的調(diào)試。服務(wù)端分頁(yè)的交互鏈路長(zhǎng)定位問(wèn)題時(shí)要學(xué)會(huì)用 curl 復(fù)現(xiàn) 的方法。在 Chrome 的 Network 面板里拿到分頁(yè)請(qǐng)求的完整 URL然后復(fù)制成 curl 命令在終端執(zhí)行看響應(yīng)結(jié)構(gòu)。這比在代碼里打斷點(diǎn)更直接能快速分清是前端參數(shù)問(wèn)題還是后端返回問(wèn)題。第二個(gè)技巧關(guān)于 Table 組件的行高一致性。分頁(yè)后表格每頁(yè)的渲染高度可能不同翻頁(yè)時(shí)頁(yè)面會(huì)出現(xiàn)跳動(dòng)?？梢栽?Table 外層設(shè)置一個(gè)固定最小高度比如把數(shù)據(jù)區(qū)域的 min-height 定為(pageSize 1) * 行高這樣翻頁(yè)時(shí)頁(yè)面不會(huì)突然變矮或變高。這個(gè)細(xì)節(jié)在小屏幕終端上特別明顯值得為它做一次適配。分頁(yè)這個(gè)功能說(shuō)難不難說(shuō)簡(jiǎn)單也絕不簡(jiǎn)單。核心還是想清楚數(shù)據(jù)流的來(lái)源與出口把前端展示狀態(tài)和服務(wù)端數(shù)據(jù)請(qǐng)求的邊界理干凈。配合 View UI 的 Table 和 Page 組件只要把頁(yè)碼狀態(tài)、查詢參數(shù)、請(qǐng)求競(jìng)態(tài)、邊界兜底這四件事處理扎實(shí)線上的分頁(yè)體驗(yàn)基本就能穩(wěn)住。希望這篇分享能幫你少踩幾個(gè)坑。