1.3 真實(shí)配置對比配置項(xiàng)默認(rèn)全選跨頁全選數(shù)據(jù)范圍當(dāng)前頁pageData全部查詢結(jié)果觸發(fā)事件源toggleAllSelection內(nèi)部遍歷手動toggleRowSelectionselectedMap已選結(jié)果翻頁后丟失翻頁后保留提交邏輯從當(dāng)前頁拿selection從業(yè)務(wù)層拿selectedMap組件狀態(tài)恢復(fù)不關(guān)心直接換data翻頁后按key回顯勾選這樣一列方案就清晰了跨頁全選不是“讓表格記住跨頁”而是把整張表格的選中結(jié)果從“臨時(shí)狀態(tài)”提升為“業(yè)務(wù)數(shù)據(jù)”永遠(yuǎn)掛在業(yè)務(wù)層。這也是整篇的核心思路后面所有實(shí)現(xiàn)都是圍繞這一句話展開的。2. 兩條技術(shù)路線reserve-selection和手動Map管理怎么選講完原理肯定有人會問Element官方不是給了reserve-selection屬性嗎為什么還要自己存Map這個問題很自然因?yàn)楣俜椒桨复_實(shí)是很多人第一眼看到的解。但我必須說清楚reserve-selection能用但它在生產(chǎn)環(huán)境有一堆隱藏前提很多團(tuán)隊(duì)是踩完坑才回頭換手動管理的。我下面把兩條路線都擺出來你們自己權(quán)衡。2.1 reserve-selection官方保留選中的快速方案但有幾個隱藏前提先給快速方案的正解代碼。用reserve-selection實(shí)現(xiàn)跨頁保留選中代碼量非常少template el-table reftableRef :datapageData row-keyid selection-changehandleSelectionChange el-table-column typeselection reserve-selection width55 / el-table-column propname label姓名 min-width120 / el-table-column propdept label部門 min-width120 / /el-table /templateexport default { data() { return { pageData: [], selectedRows: [], }; }, methods: { handleSelectionChange(selection) { // reserve-selection 生效時(shí)selection 會包含其他頁已選中的行 // 但這里有一個關(guān)鍵點(diǎn)它保存的是行對象的引用不是快照 this.selectedRows selection; }, }, };用過的人都覺得爽翻頁切回來上一頁勾選的checkbox還在不需要寫一行恢復(fù)邏輯。但我后面在實(shí)際項(xiàng)目里逐步發(fā)現(xiàn)了它的坑而且每一個坑都挺隱蔽第一必須同時(shí)設(shè)置row-key且row-key對應(yīng)的字段必須在數(shù)據(jù)刷新后保持不變。如果你的列表id是后端生成的篩選和排序后返回的新數(shù)據(jù)行id不變那沒問題但如果你用遍歷索引當(dāng)row-key或者數(shù)據(jù)經(jīng)過前端處理后id變了reserve-selection會把舊key對應(yīng)的選中殘留到一個根本不存在的行上表現(xiàn)就是“數(shù)據(jù)刷新后之前勾選的行沒在列表里但提交時(shí)還在selectedRows里”。這種鬼問題極難排查因?yàn)榻缑婵雌饋硎钦５?。第二異步?shù)據(jù)初始化的時(shí)序會坑人。表格先渲染空data再請求接口返回pageData這個過程中reserve-selection的regist邏輯有時(shí)會滯后。我遇到過一種場景搜索條件變更后重新查數(shù)據(jù)第一幀pageData是空數(shù)組選中狀態(tài)被清空一次等新數(shù)據(jù)回來時(shí)reserve-selection沒有恢復(fù)之前的key跨頁選中全丟了。這個bug不是必現(xiàn)但一旦出現(xiàn)在線上用戶罵的就是你。第三v-if重建表格、動態(tài)渲染el-table-column比如根據(jù)權(quán)限控制某些列顯隱、或者多次clearSelection()調(diào)用都會讓reserve-selection直接失效或誤清全量。很多后臺系統(tǒng)喜歡用v-if控制表格在“數(shù)據(jù)模式”和“空狀態(tài)模式”之間切換結(jié)果切換回來選中全沒了。你要是用reserve-selection就必須保證表格組件從創(chuàng)建到銷毀的生命周期內(nèi)data和列配置都不能有大的結(jié)構(gòu)變化。第四也是我最不推薦的一點(diǎn)selectedRows里存的是行對象引用不是快照。如果后續(xù)你對行數(shù)據(jù)做了修改比如編輯了某個字段或者接口返回時(shí)某些字段沒帶全提交時(shí)從selectedRows里取到的可能是舊引用或殘缺字段。如果你需要“勾選后立刻把這一行某字段鎖定允許后續(xù)修改但提交用鎖定值”這種需求reserve-selection就滿足不了。所以我的結(jié)論是reserve-selection適合“列表數(shù)據(jù)穩(wěn)定、不動態(tài)改列、不重建表格、只做勾選提交”的輕量場景。它寫起來快但你也必須承擔(dān)它的隱性約束。一旦你的系統(tǒng)里存在上面任何一條建議直接跳到手動管理方案。2.2 為什么生產(chǎn)環(huán)境我最終選擇了手動Map管理我在實(shí)際負(fù)責(zé)的中后臺項(xiàng)目里表格往往同時(shí)具備這些特征分頁 搜索篩選 后端排序 權(quán)限控制列顯隱 數(shù)據(jù)半路修改字段 切換賬號后重新加載數(shù)據(jù)。把這些特征疊在一起reserve-selection那套“組件替我記數(shù)據(jù)跟著行引用走”的機(jī)制就變得不可靠。這就是我后來放棄它改成手動維護(hù)一個selectedMap的根本原因。手動管理方案的核心就一句話選中狀態(tài)從“表格內(nèi)部狀態(tài)”變成“業(yè)務(wù)組件的響應(yīng)式數(shù)據(jù)”表格只負(fù)責(zé)展示當(dāng)前頁哪些行被勾選真正的選中集合由你全權(quán)掌控。這樣做有幾個實(shí)實(shí)在在的好處數(shù)據(jù)和UI解耦selectedMap存的是行數(shù)據(jù)快照哪怕后續(xù)列表重新查詢、排序、甚至當(dāng)前頁不存在這條數(shù)據(jù)只要key還在Map里提交時(shí)就能取到完整的行信息。各種邊界情況可編程切換篩選條件、清空選中、批量操作、限制最大選擇數(shù)全部可以在業(yè)務(wù)層寫邏輯不用猜組件內(nèi)部行為。性能可預(yù)估選中集合的操作都是Map的set/delete/has時(shí)間復(fù)雜度O(1)幾千上萬條選中數(shù)據(jù)也不慌。當(dāng)然代價(jià)也明顯代碼量變多了翻頁后要自己調(diào)toggleRowSelection回顯還要加標(biāo)志位防止死循環(huán)。但對比線上數(shù)據(jù)錯亂的投訴我寧愿多寫這幾十行代碼。2.3 核心思路把選中狀態(tài)提升到業(yè)務(wù)層在寫代碼之前我要先把數(shù)據(jù)流畫出來這能幫你理解整個方案為什么設(shè)計(jì)成這樣正常勾選鏈路用戶點(diǎn)復(fù)選框 -select或select-all事件觸發(fā) - 根據(jù)勾選或取消向selectedMap寫入或刪除key - 表格繼續(xù)走它的正常渲染。翻頁恢復(fù)鏈路頁碼變化 - 請求新一頁數(shù)據(jù) -pageData更新 -watch或方法調(diào)用進(jìn)入restoreSelection- 遍歷當(dāng)前頁每行判斷key在不在selectedMap- 在則toggleRowSelection(row, true)回顯勾選。提交鏈路業(yè)務(wù)按鈕 - 遍歷selectedMap- 得到所有選中行做批量操作。三條鏈路彼此獨(dú)立selectedMap是唯一的數(shù)據(jù)源。這樣排序、篩選、分頁、跨頁全選都只是圍繞selectedMap做讀寫。還有一個小設(shè)計(jì)值得注意selectedMap的value我會存{...row}快照而不是直接存原行引用。原因有兩個一是防止后面對原行數(shù)據(jù)做修改時(shí)污染已選數(shù)據(jù)二是提交時(shí)拿到的字段齊整不會出現(xiàn)“勾選時(shí)明明有手機(jī)號提交時(shí)對象里沒有”的靈異事件。3. 手動管理跨頁選中的完整實(shí)現(xiàn)下面這套實(shí)現(xiàn)是我們在一個用戶量萬級的中后臺項(xiàng)目里跑過一年的方案按步驟復(fù)制就能用。我分三塊講模板和數(shù)據(jù)結(jié)構(gòu)怎么搭、勾選和取消怎么處理、翻頁恢復(fù)有哪些細(xì)節(jié)必須注意。3.1 模板與數(shù)據(jù)結(jié)構(gòu)搭建先看模板。注意我這里特意沒用reserve-selectionselection列的代碼和普通表格沒有任何區(qū)別template div classuser-table-wrapper el-table reftableRef v-loadingloading :datapageData row-keyid :row-class-namerowClassName selecthandleSelect select-allhandleSelectAll el-table-column typeselection width55 / el-table-column propname label姓名 min-width120 / el-table-column propphone label手機(jī)號 min-width140 / el-table-column propdept label部門 min-width120 / el-table-column propcreateTime label創(chuàng)建時(shí)間 min-width170 / /el-table el-pagination classtable-pagination background layouttotal, prev, pager, next, sizes :current-pagepage :page-sizepageSize :totaltotal current-changehandlePageChange size-changehandleSizeChange / /div /template再定義數(shù)據(jù)結(jié)構(gòu)。這里我推薦用Map而不是普通對象因?yàn)镸ap對key的類型沒有限制插入順序也好控制遍歷性能也比對象好export default { data() { return { page: 1, pageSize: 50, total: 0, loading: false, pageData: [], // 跨頁選中的核心數(shù)據(jù)結(jié)構(gòu) // key: row-key 對應(yīng)的字段值例如 id // value: 行數(shù)據(jù)快照 { ...row } selectedMap: new Map(), // 防止恢復(fù)勾選時(shí)觸發(fā) select/select-all 事件導(dǎo)致死循環(huán) isRestoring: false, }; }, };這里有兩個容易忽略的設(shè)計(jì)。一個是isRestoring標(biāo)志位。沒有它restoreSelection里調(diào)toggleRowSelection會觸發(fā)select事件handleSelect又把數(shù)據(jù)寫進(jìn)selectedMap而selectedMap變動如果又引起別的地方重新渲染就會出現(xiàn)事件風(fēng)暴輕則選中狀態(tài)錯亂重則直接棧溢出。我在剛實(shí)現(xiàn)這套邏輯時(shí)就沒有標(biāo)志位頁面一翻頁就卡死后來排查半天才找到是這里互相觸發(fā)。另一個是Map的value為什么要用{ ...row }而不是直接存row。前面提過這是為了防污染。舉個例子用戶在第1頁勾選了一行然后表格發(fā)請求刷新了列表第1頁的這行數(shù)據(jù)可能被新對象替代。如果你存的是舊引用提交時(shí)拿到的內(nèi)容還是舊的反而沒問題但如果你在勾選后某個彈窗里修改了原行數(shù)據(jù)比如改狀態(tài)字段舊引用對應(yīng)的對象會和列表里顯示的不一致。存快照就能保證selectedMap里永遠(yuǎn)是你勾選那一刻的狀態(tài)可控性最強(qiáng)。3.2 勾選、取消勾選、全選的處理邏輯勾選和取消走的是select事件。這個事件回調(diào)里有兩個參數(shù)selection變化后所有選中行的數(shù)組和row當(dāng)前操作的那一行。要判斷是勾選還是取消最簡單的方法就是看row還在不在selection里handleSelect(selection, row) { // 恢復(fù)勾選期間觸發(fā)的事件直接忽略 if (this.isRestoring) return; const key row[this.rowKey]; const isSelected selection.includes(row); if (isSelected) { // 勾選寫入快照 this.selectedMap.set(key, { ...row }); } else { // 取消刪除key this.selectedMap.delete(key); } }這里有個細(xì)節(jié)值得說明selection.includes(row)依賴的是“操作的行對象引用”。Element UI在渲染時(shí)用的是pageData里的行對象你操作時(shí)傳入的row也是同一個對象引用所以includes能正確判斷。如果因?yàn)槟承┰蚰惆l(fā)現(xiàn)includes不準(zhǔn)比如對行對象做過淺拷貝可以改成用key判斷const isSelected selection.some(item item[this.rowKey] key);兩條路都對選一個順手的即可。全選和取消全選走的是select-all事件。它只有一個參數(shù)selection也就是操作后當(dāng)前頁選中行的集合。全選時(shí)selection包含當(dāng)前頁所有行取消全選時(shí)selection為空數(shù)組。但這里有個大坑我必須單獨(dú)強(qiáng)調(diào)一下Element UI的表頭全選checkbox點(diǎn)擊一次在部分選中狀態(tài)下會執(zhí)行“先清空再全選”兩個動作也就是說selection參數(shù)會經(jīng)歷“空數(shù)組 - 全部行”的過程。你在二次點(diǎn)擊時(shí)如果拿selection直接覆蓋selectedMap會把之前所有頁的選中都清掉。所以處理select-all一定要用“增量合并”而不是“整體覆蓋”handleSelectAll(selection) { if (this.isRestoring) return; // 判斷當(dāng)前是“全選”還是“取消全選” // 全選時(shí)當(dāng)前頁的每一行都應(yīng)該在 selection 里 const isAllSelected this.pageData.every(row selection.includes(row)); this.pageData.forEach((row) { const key row[this.rowKey]; if (isAllSelected) { // 全選把當(dāng)前頁所有行寫入Map this.selectedMap.set(key, { ...row }); } else { // 取消全選把當(dāng)前頁所有行從Map中刪除 this.selectedMap.delete(key); } }); }這段代碼的關(guān)鍵在于isAllSelected的判斷。它不關(guān)心selection經(jīng)歷過幾次變化只看當(dāng)前這一幀的selection是否覆蓋了pageData全部行。這樣寫無論用戶在什么選中狀態(tài)下點(diǎn)全選結(jié)果都是穩(wěn)定的要么把這頁所有行合并進(jìn)全局要么把這頁所有行從全局移除其他頁的選中不受影響。3.3 翻頁后恢復(fù)勾選的細(xì)節(jié)不能用舊引用翻頁或改變每頁條數(shù)后pageData會被新的數(shù)據(jù)覆蓋。此時(shí)表格本身是不帶任何選中狀態(tài)的需要我們在數(shù)據(jù)到位后手動恢復(fù)?；謴?fù)邏輯放在loadPage的末尾async loadPage() { this.loading true; const { list, total } await fetchUserList({ page: this.page, pageSize: this.pageSize, }); this.loading false; this.pageData list; this.total total; // 數(shù)據(jù)到位后恢復(fù)勾選 this.restoreSelection(); }, restoreSelection() { if (!this.$refs.tableRef) return; this.isRestoring true; this.$nextTick(() { this.pageData.forEach((row) { const key row[this.rowKey]; if (this.selectedMap.has(key)) { this.$refs.tableRef.toggleRowSelection(row, true); } }); this.isRestoring false; }); }這個restoreSelection是整個方案里最容易寫錯的地方我?guī)缀趺看卧u審都能看到同事在這里踩坑。最常見的一個錯誤是把selectedMap里存的舊行對象直接傳給toggleRowSelection而不是用當(dāng)前pageData里的行對象。比如// 錯誤示例 this.selectedMap.forEach((row) { this.$refs.tableRef.toggleRowSelection(row, true); });這樣寫翻頁后表格根本不會有任何勾選。原因在于toggleRowSelection內(nèi)部會拿傳入的行和當(dāng)前data中的行做匹配由于你傳的是舊頁面的行對象引用新pageData里每一行都是新創(chuàng)建的對象引用對不上組件認(rèn)為“這一行不在表格里”自然不會勾選。正確做法永遠(yuǎn)是遍歷當(dāng)前pageData從selectedMap里查key然后再回設(shè)。另外restoreSelection里this.$nextTick也是必須的。因?yàn)閠his.pageData list之后Vue需要等到DOM更新完表格內(nèi)部的data屬性才會同步成新數(shù)據(jù)。如果不等nextTick直接遍歷pageData調(diào)toggleRowSelection此時(shí)表格內(nèi)部可能還在處理舊數(shù)據(jù)會出現(xiàn)恢復(fù)失敗或狀態(tài)殘留。還有一個性能問題容易被人忽略當(dāng)一頁有50條數(shù)據(jù)循環(huán)調(diào)toggleRowSelection50次每次都會觸發(fā)一次表格內(nèi)部的選中狀態(tài)更新。如果回顯邏輯還觸發(fā)了select事件即使有isRestoring攔截也會白白多走一輪方法調(diào)用。所以建議在restoreSelection開頭就置isRestoring truenextTick的回調(diào)里循環(huán)完再置回false把整個恢復(fù)過程隔離成一次“靜默操作”。3.4 清空全部與提交數(shù)據(jù)跨頁全選的方案里這兩個方法可以說是“配套服務(wù)”缺一個都難受。清空全部指的是把selectedMap清空的同時(shí)把當(dāng)前頁表格上可見的勾選也全部取消clearSelection() { // 清空業(yè)務(wù)層的選中集合 this.selectedMap.clear(); // 清空當(dāng)前頁表格可見的勾選 this.$nextTick(() { this.$refs.tableRef.clearSelection(); }); }這里要注意順序先清selectedMap再調(diào)clearSelection()。因?yàn)閏learSelection()會觸發(fā)select/select-all事件如果此時(shí)selectedMap還沒清空事件回調(diào)里會往Map里寫入當(dāng)前頁所有行的key導(dǎo)致“清空失敗”。反過來先清Map再清表格事件觸發(fā)了也無所謂handleSelect和handleSelectAll判斷到selectedMap已經(jīng)沒有對應(yīng)key自然不會寫入。提交數(shù)據(jù)時(shí)把selectedMap的values取出來就行function handleSubmit() { if (this.selectedMap.size 0) { // 給個提示別讓用戶直接提交空數(shù)據(jù) this.$message.warning(請先勾選要處理的用戶); return; } const selectedRows Array.from(this.selectedMap.values()); // 調(diào)用批量接口 await batchOperation(selectedRows); }如果你要按勾選順序提交Map本身會維護(hù)插入順序Array.from(this.selectedMap.values())拿到的數(shù)組基本就是用戶勾選的先后順序。但如果你中途刪掉某個key再重新添加Map會把它放到最后這一點(diǎn)如果業(yè)務(wù)要求嚴(yán)格按操作順序需要額外維護(hù)一個orderList數(shù)組來記錄這里就不展開寫了。4. 一不留神就翻車的邊界情況跨頁全選實(shí)現(xiàn)出來只是第一步。真正決定方案好不好用的是它在各種異常場景下能不能穩(wěn)住。下面這幾個邊界情況都是我在真實(shí)項(xiàng)目里被問過、被投訴過、現(xiàn)場排查過的每個都值得拿出來單獨(dú)說。4.1 排序篩選后的選中語義問題先給結(jié)論跨頁全選和排序、篩選不是天然兼容的你必須先和產(chǎn)品經(jīng)理確認(rèn)“已選”到底代表什么語義。我遇到的真實(shí)需求是這樣的用戶在第1頁勾了3個人然后在搜索框里輸入“離職”點(diǎn)擊查詢列表變成了離職員工之前勾選的3個人不在結(jié)果里。此時(shí)界面上“已選3人”是否還應(yīng)該顯示如果顯示用戶可能看不到自己選了誰很容易誤解成“這3人是當(dāng)前條件篩選出來的結(jié)果”如果不顯示但提交時(shí)又把3個人帶上用戶會在最后一步覺得莫名其妙。后來我們定的方案是所有篩選、排序操作都不會自動清空selectedMap但會在表格上方浮動一條提示已選 N 人當(dāng)前查詢條件下顯示 M 人操作將作用于全部已選。同時(shí)提供“清除已選”按鈕。這條提示的M怎么算就是當(dāng)前pageData里有多少行的key命中selectedMapconst currentPageSelectedCount computed(() this.pageData.filter(row this.selectedMap.has(row[this.rowKey])).length );這樣用戶對“哪些選中可見、哪些不可見”一目了然投訴率直線下降。另外如果你的業(yè)務(wù)在篩選后確實(shí)希望“只作用于當(dāng)前條件下的選中”那就改成篩選時(shí)自動調(diào)用clearSelection()并在篩選組件上給一個明顯的“已有選中數(shù)據(jù)切換篩選將清除”的提示。4.2 排序重排與數(shù)據(jù)刷新的競態(tài)問題中后臺列表幾乎都有排序。點(diǎn)表頭排序后后端重新返回列表此時(shí)pageData的數(shù)組順序變了但行的id沒變。只要我們的回顯邏輯基于key而不是基于順序排序后選中狀態(tài)就能正確恢復(fù)。這里有個問題反而比排序本身更隱蔽連續(xù)操作導(dǎo)致的接口競態(tài)。舉個具體場景用戶在第1頁卡頓的情況下連續(xù)點(diǎn)了第2頁、第3頁前端會發(fā)出兩次分頁請求后一次響應(yīng)覆蓋前一次。如果兩次請求之間網(wǎng)絡(luò)速度差異大可能出現(xiàn)第2頁的響應(yīng)比第3頁晚到最后表格停在“page3”的翻頁指示器上但展示的卻是第2頁的數(shù)據(jù)。這時(shí)候restoreSelection恢復(fù)的是第2頁的選中頁面狀態(tài)混亂。解決競態(tài)的標(biāo)準(zhǔn)做法是給請求編號只有最新編號的響應(yīng)允許覆蓋數(shù)據(jù)data() { return { querySeq: 0, }; }, async loadPage() { const currentSeq this.querySeq; this.loading true; const { list, total } await fetchUserList({ page: this.page, pageSize: this.pageSize, }); this.loading false; // 過期響應(yīng)直接丟棄 if (currentSeq ! this.querySeq) return; this.pageData list; this.total total; this.restoreSelection(); }這個querySeq字段我在所有分頁接口里都會加成本幾乎為零但能防住絕大部分連續(xù)翻頁、連續(xù)篩選造成的狀態(tài)錯亂。有時(shí)候用戶反饋“表格偶爾顯示和翻頁按鈕對不上”十有八九就是缺這個。4.3 表格銷毀與賬號切換時(shí)殘留臟數(shù)據(jù)后臺系統(tǒng)經(jīng)常有切換部門、退出登錄、彈窗關(guān)閉等場景表格組件被銷毀或v-if置為false。如果selectedMap是頁面級data組件銷毀時(shí)Vue會一起回收問題不大。但如果表格在彈窗里彈窗關(guān)閉后selectedMap還在父組件內(nèi)存里重新打開彈窗時(shí)上一次的選中數(shù)據(jù)會殘留在Map里。表現(xiàn)就是用戶這次打開彈窗什么都沒勾提交的時(shí)候卻提示“已選50人”。這個問題我建議在進(jìn)入表格頁面前統(tǒng)一初始化selectedMap并在關(guān)閉時(shí)清理openDialog() { this.selectedMap.clear(); this.dialogVisible true; }, closeDialog() { this.dialogVisible false; this.selectedMap.clear(); if (this.$refs.tableRef) { this.$refs.tableRef.clearSelection(); } }這里的核心原則是selectedMap的生命周期必須和業(yè)務(wù)會話一致不能比表格組件更長。如果你把Map定義在全局store里記得在退出相關(guān)業(yè)務(wù)模塊時(shí)手動清空不然這次選中的數(shù)據(jù)會跟著用戶跑到下一個業(yè)務(wù)里去。4.4 alert、messagebox、批量操作之后的選中保持問題還有一種情況用戶勾選了幾十行執(zhí)行批量操作后接口報(bào)錯了。此時(shí)要不要清除選中不同業(yè)務(wù)的答案完全不同。我的經(jīng)驗(yàn)是操作失敗時(shí)必須保留選中操作成功時(shí)可以保留也可以清除但必須給用戶明確的反饋。很多系統(tǒng)采用“執(zhí)行后自動清空”結(jié)果接口超時(shí)用戶還得重新一頁一頁翻回去再勾選體驗(yàn)極差。我會把“提交”和“清空”拆成兩個動作只在批量操作成功且用戶確認(rèn)不再處理其余數(shù)據(jù)時(shí)才清空。另外像MessageBox.confirm這類全局彈窗如果用戶點(diǎn)擊“確定”后我們把selectedMap清空了后續(xù)彈出的成功提示就別再依賴這個Map顯示數(shù)量否則會出現(xiàn)“已選0人但提示成功操作3人”的笑話。5. 跨頁全選配套的體驗(yàn)優(yōu)化與性能保障模塊跑通之后就要考慮把它做得更好用、扛得住數(shù)據(jù)量了。這一部分我會結(jié)合表格滾動條、滾動條寬度、4000條假數(shù)據(jù)、組合篩選、獲取列寬這幾個中后臺里經(jīng)常連在一起出現(xiàn)的問題逐個講我在項(xiàng)目里的處理方案。5.1 已選N條提示條與表格的聯(lián)動布局跨頁全選之后產(chǎn)品大概率會要求“在表格上方顯示已選N條”。這個提示條最怕兩件事一是翻頁后數(shù)字不更新二是和表格列對不齊。數(shù)字更新好辦用Map的size或者一個響應(yīng)式的selectedCount就能實(shí)時(shí)顯示。關(guān)鍵是布局對齊。有些設(shè)計(jì)會把提示條放在表格上方里面還有“清除”按鈕。如果表格開啟了固定列提示條的左邊緣會和表格左邊緣對齊看起來是整齊的。但如果提示條里還有“查看已選”之類的下拉面板它的寬度又不能超過表格本身。我的做法是給表格外層套一個.table-container提示條放在容器內(nèi)、表格之上寬度設(shè)成100%再配合box-sizing: border-box和表格本身的border設(shè)置基本能保證視覺對齊。如果提示條需要對齊到某個具體列比如對齊操作列就得獲取列寬了這個我會在第5.4節(jié)專門講做法。5.2 大數(shù)據(jù)量下表格滾動條和固定列的性能細(xì)節(jié)再來說熱詞里那個“el-table顯示4千條假數(shù)據(jù)”。我先給一個個人建議不要真的在一個頁面上讓el-table渲染4000行。很多人做原型時(shí)喜歡Array.from({ length: 4000 }, ...)生成假數(shù)據(jù)鋪滿表格看著很震撼但el-table并不是虛擬滾動表4000行全部渲染會導(dǎo)致DOM節(jié)點(diǎn)爆炸滾動條拖起來掉幀勾選checkbox更是卡到?jīng)]法用。如果只是做演示想要“一屏滾到底”的效果比較簡單的方法是給表格設(shè)置固定的height或max-height讓el-table自己產(chǎn)生內(nèi)部滾動條el-table :datapageData height600 row-keyid !-- columns -- /el-table這樣做表格內(nèi)部滾動DOM渲染仍然只處理可見區(qū)域之外的滾動容器結(jié)構(gòu)雖然4000行全量渲染依舊存在但至少不會撐滿整頁。屏幕高度有限用戶滾動的體驗(yàn)會好不少。但如果你要的是真正的4000行流暢滾動我只能說el-table做不到得換支持虛擬滾動的方案比如第三方table組件?？珥撊x這套手動Map管理的邏輯和那些表格組件同樣適用你只需要把“表格組件的事件回調(diào)”替換成對應(yīng)組件提供的select/select-all事件即可selectedMap的核心設(shè)計(jì)不用變。滾動條寬度的問題也要留個心。el-table開啟固定列后右側(cè)會出現(xiàn)一個滾動條當(dāng)滾動條和固定列重疊時(shí)表頭和表體的列寬容易對不上尤其是在窗口尺寸變化、表格寬度被百分比控制時(shí)。我在項(xiàng)目里遇到過一次表格右側(cè)固定了“操作”列但橫向滾動條被操作列遮住了一半用戶很難拖動。除了調(diào)整固定列寬度、給滾動條留位置之外還可以在表格數(shù)據(jù)變化后主動調(diào)用一次this.$nextTick(() { this.$refs.tableRef.doLayout(); });doLayout()是el-table的實(shí)例方法會重新計(jì)算列寬和布局。列寬對不齊、滾動條錯位、固定列錯位這些問題在數(shù)據(jù)異步加載后經(jīng)常出現(xiàn)調(diào)一下基本都能解決。注意一定要放在nextTick里否則DOM還沒更新完重新計(jì)算的是舊布局。5.3 組合篩選組件和跨頁全選的聯(lián)動策略大多數(shù)中后臺表格上方都掛著組合篩選組件關(guān)鍵字輸入框、部門下拉、狀態(tài)多選、日期范圍。篩選一多跨頁全選的交互就復(fù)雜了。我踩過的坑是這樣的用戶在“全部狀態(tài)”下勾了100人然后選擇“在職”狀態(tài)篩選此時(shí)列表只顯示在職用戶之前的100人里有80人還在Map里但列表里看不全。用戶并不知道這100人里有20人是離職的于是點(diǎn)擊“全選”想繼續(xù)把在職的都選上結(jié)果100 全部在職數(shù)量遠(yuǎn)大于預(yù)期。處理這種聯(lián)動我總結(jié)出一個比較穩(wěn)的交互模型篩選條件變化時(shí)不自動清空selectedMap但提示條上明確展示“已選N人含當(dāng)前篩選條件之外的M人”。如果用戶希望只選當(dāng)前結(jié)果集可以先點(diǎn)“清除已選”再重新勾選。如果點(diǎn)擊表頭全選只把當(dāng)前結(jié)果集合并進(jìn)selectedMap不影響其他條件里的已選數(shù)據(jù)。提交時(shí)提示“將處理全部已選N人”并列出前幾條和后綴“等N人”。這個方案雖然不能讓所有產(chǎn)品經(jīng)理滿意但它在“數(shù)據(jù)安全”和“操作效率”之間做到了均衡至少不會出現(xiàn)用戶不知道自己在操作什么的情況。組合篩選組件還會帶來一個技術(shù)點(diǎn)篩選條件在組件內(nèi)部但表格數(shù)據(jù)請求需要一個統(tǒng)一的參數(shù)對象。建議把篩選表單的model放在一個獨(dú)立的computed或ref里在loadPage里把它展開到請求參數(shù)中避免每個篩選控件單獨(dú)修改請求參數(shù)保證跨頁全選時(shí)重新請求的數(shù)據(jù)和篩選條件總是對應(yīng)的。5.4 獲取列寬做自定義表頭的對齊計(jì)算最后說一個相對進(jìn)階但很實(shí)用的點(diǎn)獲取el-table的列寬。為什么要獲取列寬因?yàn)楫?dāng)你想在表頭上方加自定義內(nèi)容比如“批量操作欄”的下拉、篩選面板的位置定位、表頭某個checkbox的樣式定制時(shí)只能用絕對定位或?qū)R計(jì)算這時(shí)候列寬就是唯一的坐標(biāo)系依據(jù)。官方并沒有直接暴露一個“獲取某一列寬度”的實(shí)例方法但我們可以從兩條路拿到。第一條是通過組件的storeconst columns this.$refs.tableRef.store.states.columns; columns.forEach((col) { console.log(col.label, col.width, col.realWidth); });col.width是用戶顯式設(shè)置的寬度col.realWidth是經(jīng)過計(jì)算后的真實(shí)寬度。固定列和自適應(yīng)列在realWidth上更可靠。第二條是直接從DOM里量const ths this.$refs.tableRef.$el.querySelectorAll(.el-table__header thead th); ths.forEach((th) { console.log(th.getBoundingClientRect().width); });DOM測量方式最直觀但依賴樣式渲染完成通常也要包在nextTick里用。我一般優(yōu)先用store.states.columns拿邏輯寬度用getBoundingClientRect做最終校正。拿到的列寬可以用來給“表頭全選”替代方案做精確的checkbox定位或者做一個跟隨表頭橫向滾動的“已選N人”操作條。順帶說一個列寬相關(guān)的高頻bug動態(tài)切換列的顯示隱藏時(shí)表格列寬會錯亂。這是因?yàn)関-if變更后表格內(nèi)部的列緩存沒有自動清理。解決方式是給表格加key讓列配置大幅變化時(shí)重建組件或者手動doLayout()重新排布。如果列切換頻繁、性能要求高優(yōu)先doLayout如果列配置切換不頻繁直接重建組件最穩(wěn)反正有selectedMap兜底組件重建了選中數(shù)據(jù)也不會丟。結(jié)尾跨頁全選這個功能代碼量不大但牽扯到的邊界場景一點(diǎn)也不少。我做下來最大的體會是不要和表格組件較勁要讓組件只負(fù)責(zé)它擅長的事——展示和交互真正需要長期保存的數(shù)據(jù)一定要握在自己手里。這也是為什么整篇文章花了大力氣講selectedMap的設(shè)計(jì)而不是教你怎么改Element源碼或者鉆reserve-selection的空子。最后再分享一個我在實(shí)際項(xiàng)目中驗(yàn)證過的小技巧如果你是用Vue3 Element Plus這套方案的代碼風(fēng)格基本不用變唯一要注意的是toggleRowSelection的第三個參數(shù)在不同版本里有差異恢復(fù)勾選時(shí)記得nextTick和isRestoring這兩個保險(xiǎn)一起上能幫你省掉大半查bug的時(shí)間。還有一個很容易被忽略的點(diǎn)就是測試?？珥撊x涉及分頁、篩選、排序、批量操作、失敗重試等場景手工點(diǎn)幾遍很難覆蓋全。我建議用無頭瀏覽器或者自動化測試把“跨頁勾選 - 翻頁 - 回顯 - 提交”這樣一條主鏈路固定下來每次發(fā)版前跑一遍。別問我為什么這么建議我吃過一次線上漏測的虧那次就是篩選后全選計(jì)數(shù)不對用戶反饋刷了一屏。