做后臺(tái)管理系統(tǒng)的時(shí)候幾乎繞不開Vue和Element UI這對(duì)組合。而在各種業(yè)務(wù)頁面里多級(jí)下拉篩選框又是出場率最高的組件之一什么省市區(qū)聯(lián)動(dòng)了、部門層級(jí)篩選了、商品分類切換了說到底都是同一套邏輯在換皮。前陣子我在一個(gè)數(shù)據(jù)看板項(xiàng)目里做了一版“篩選條件區(qū)”包含四級(jí)聯(lián)動(dòng)的下拉篩選折騰完發(fā)現(xiàn)這里面的坑遠(yuǎn)不止“寫個(gè)組件就完事”那么簡單。今天把這套實(shí)現(xiàn)從選擇方案到落地細(xì)節(jié)再到踩過的坑完整梳理一遍給需要的朋友做個(gè)參考。這套方案適合誰如果你正在用Vue 2 Element UI做過或準(zhǔn)備做帶層級(jí)關(guān)系的篩選表單如果你不想只停留在“靜態(tài)下拉框復(fù)制粘貼”的階段想搞清楚聯(lián)動(dòng)篩選的內(nèi)存結(jié)構(gòu)怎么設(shè)計(jì)、遠(yuǎn)程數(shù)據(jù)怎么按需加載、表格篩選怎么共用一套條件狀態(tài)那這篇文章應(yīng)該能幫你省下不少查資料的力氣。1. 多級(jí)下拉篩選框的需求場景與方案選型1.1 多級(jí)篩選在真實(shí)業(yè)務(wù)里長什么樣先聊一下需求本身。所謂的多級(jí)下拉篩選框一般分兩種形態(tài)。第一種是“同層級(jí)多條件并列”比如篩選列表頁的數(shù)據(jù)有“時(shí)間范圍”“狀態(tài)”“來源渠道”三個(gè)下拉仨下拉之間互不依賴各篩各的。第二種是“父子層級(jí)聯(lián)動(dòng)”比如選了“省份”之后“城市”下拉的選項(xiàng)才會(huì)跟著變選了“城市”之后“區(qū)縣”才會(huì)刷新。標(biāo)題里說的“多級(jí)下拉菜單”絕大多數(shù)情況下指的是第二種也就是有依賴關(guān)系的聯(lián)動(dòng)下拉。我這次遇到的需求是在訂單列表頁做一個(gè)篩選區(qū)用來篩訂單。篩選維度有四層客戶分類、客戶名稱、訂單狀態(tài)、數(shù)據(jù)權(quán)限范圍。前三層是硬聯(lián)動(dòng)關(guān)系——選中客戶分類后客戶名稱的候選列表要變成該分類下的客戶訂單狀態(tài)則是獨(dú)立的。這個(gè)場景就是非常典型的“省市區(qū)聯(lián)動(dòng)”的變種只是把地理層級(jí)的對(duì)象換成了業(yè)務(wù)對(duì)象。在設(shè)計(jì)階段要搞清楚的第一件事是你的數(shù)據(jù)是靜態(tài)的還是動(dòng)態(tài)的。靜態(tài)就是前端一次性拿到所有層級(jí)的所有選項(xiàng)自己根據(jù)父級(jí)選中的值去過濾動(dòng)態(tài)則是每次切換父級(jí)選項(xiàng)時(shí)向后端發(fā)請求拉取子級(jí)列表。這個(gè)選擇直接決定了后面代碼怎么寫也決定了用戶體驗(yàn)的天花板。1.2 方案選型el-select聯(lián)動(dòng)還是el-cascader級(jí)聯(lián)選擇器這是很多新手上來就會(huì)卡住的問題。Element UI里其實(shí)自帶了一個(gè)el-cascader組件它就是專門為多級(jí)選擇設(shè)計(jì)的UI上表現(xiàn)為一個(gè)下拉框點(diǎn)開是一整棵級(jí)聯(lián)樹。那為什么還要費(fèi)勁去用多個(gè)el-select做聯(lián)動(dòng)呢說到底是交互語義和數(shù)據(jù)形態(tài)決定的。對(duì)比維度el-select聯(lián)動(dòng)方案el-cascader方案UI呈現(xiàn)多個(gè)獨(dú)立下拉框每個(gè)占一列單個(gè)下拉框內(nèi)部樹形展示交互習(xí)慣貼近原生表單用戶無學(xué)習(xí)成本適合省市區(qū)、分類樹等層級(jí)感知強(qiáng)的場景數(shù)據(jù)回顯每個(gè)字段獨(dú)立綁定回顯容易需要處理路徑數(shù)組如[廣東省,深圳市]末級(jí)語義每一級(jí)篩選項(xiàng)獨(dú)立參與篩選通常整體作為一個(gè)篩選項(xiàng)傳給后端右擊/懶加載聯(lián)動(dòng)數(shù)據(jù)需自行控制請求原生支持懶加載動(dòng)態(tài)顯示多級(jí)值更靈活受限我這次選擇el-select聯(lián)動(dòng)原因非常直接客戶名稱這一級(jí)需要支持遠(yuǎn)程搜索而且層級(jí)之間要根據(jù)權(quán)限動(dòng)態(tài)隱藏某一級(jí)cascader在這種場景下會(huì)顯得很笨重。所以我最后是“主聯(lián)動(dòng)用el-select純樹形的地方用cascader”各干各的。1.3 數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)決定后續(xù)所有邏輯不管選哪種方案數(shù)據(jù)結(jié)構(gòu)的規(guī)劃都特別重要。很多項(xiàng)目做到后期發(fā)現(xiàn)代碼亂得沒法維護(hù)根源在于當(dāng)初沒有把選項(xiàng)的數(shù)據(jù)結(jié)構(gòu)定清楚。聯(lián)動(dòng)場景下我建議父級(jí)選項(xiàng)這么設(shè)計(jì)// 客戶分類選項(xiàng) customerCategoryOptions: [ { id: 1, name: 企業(yè)客戶 }, { id: 2, name: 個(gè)人客戶 }, { id: 3, name: 渠道客戶 } ] // 客戶名稱選項(xiàng)每個(gè)都帶有categoryId歸屬標(biāo)記 customerOptions: [ { id: 101, name: 阿里巴巴, categoryId: 1 }, { id: 102, name: 騰訊, categoryId: 1 }, { id: 201, name: 張三, categoryId: 2 }, { id: 301, name: 某渠道商, categoryId: 3 } ]關(guān)鍵點(diǎn)在于子級(jí)選項(xiàng)里要給每一個(gè)選項(xiàng)掛上父級(jí)id的字段categoryId。這樣不管數(shù)據(jù)是接口返回的還是前端靜態(tài)的都可以通過一次filter快速得到“當(dāng)前父級(jí)下的合法子選項(xiàng)”而不需要為每一層單獨(dú)寫冗余的狀態(tài)。2. 基于el-select實(shí)現(xiàn)多級(jí)聯(lián)動(dòng)篩選框2.1 模板骨架篩選區(qū)的基本結(jié)構(gòu)先展示我最終版的模板結(jié)構(gòu)。這一段是整個(gè)篩選區(qū)的地基后續(xù)的所有邏輯都在這個(gè)骨架里生長。template el-form reffilterForm :modelfilterForm inline classfilter-bar el-form-item label客戶分類 propcategoryId el-select v-modelfilterForm.categoryId placeholder請選擇客戶分類 clearable filterable stylewidth: 180px changehandleCategoryChange el-option v-foritem in customerCategoryOptions :keyitem.id :labelitem.name :valueitem.id / /el-select /el-form-item el-form-item label客戶名稱 propcustomerId el-select v-modelfilterForm.customerId placeholder請選擇客戶名稱 clearable filterable :disabled!filterForm.categoryId :loadingcustomerLoading stylewidth: 220px changehandleCustomerChange el-option v-foritem in currentCustomerOptions :keyitem.id :labelitem.name :valueitem.id / /el-select /el-form-item el-form-item label訂單狀態(tài) proporderStatus el-select v-modelfilterForm.orderStatus placeholder請選擇訂單狀態(tài) clearable stylewidth: 160px el-option label待付款 valuePENDING / el-option label已付款 valuePAID / el-option label已發(fā)貨 valueSHIPPED / el-option label已完成 valueFINISHED / el-option label已取消 valueCANCELED / /el-select /el-form-item el-form-item el-button typeprimary clickhandleSearch查詢/el-button el-button clickhandleReset重置/el-button /el-form-item /el-form /template這里有幾個(gè)細(xì)節(jié)我特意加了你們在實(shí)際項(xiàng)目里照著抄就行。第一個(gè)是子級(jí)下拉的disabled綁定filterForm.categoryId沒有選中時(shí)客戶名稱下拉直接禁用。這個(gè)在交互上是很明確的引導(dǎo)用戶一看就知道“得先選分類”。第二個(gè)是filterable屬性。多級(jí)篩選框到了第二級(jí)以后選項(xiàng)數(shù)量往往會(huì)比較多比如客戶名稱可能有幾百上千條這時(shí)候必須加filterable讓用戶能輸入關(guān)鍵字過濾否則光靠滾動(dòng)找選項(xiàng)能把人逼瘋。第三個(gè)是每列寬度我都固定了。篩選區(qū)如果寬度不固定換行后就會(huì)變得很亂。用inline的el-form布局下顯式給每個(gè)el-select設(shè)置style寬度是我經(jīng)歷多次“對(duì)不齊”之后養(yǎng)成的習(xí)慣。2.2 聯(lián)動(dòng)邏輯選父級(jí)清空子級(jí)并更新候選列表聯(lián)動(dòng)篩選核心要處理的邏輯其實(shí)只有兩條父級(jí)變化時(shí)清空所有后代的值父級(jí)變化時(shí)刷新所有后代的候選數(shù)據(jù)。代碼寫多了你會(huì)發(fā)現(xiàn)所有層級(jí)之間的聯(lián)動(dòng)本質(zhì)上都是這兩條規(guī)則的循環(huán)嵌套。export default { data() { return { filterForm: { categoryId: null, customerId: null, orderStatus: null }, customerCategoryOptions: [], // 全量客戶列表 allCustomerOptions: [], customerLoading: false } }, computed: { // 根據(jù)選中的categoryId過濾出當(dāng)前可選的客戶列表 currentCustomerOptions() { if (!this.filterForm.categoryId) return [] return this.allCustomerOptions.filter( item item.categoryId this.filterForm.categoryId ) } }, methods: { async handleCategoryChange(value) { // 只要父級(jí)變化子級(jí)的值必須清空 this.filterForm.customerId null if (!value) return // 如果后端要求按分類動(dòng)態(tài)拉取客戶列表就在這里發(fā)請求 // this.customerLoading true // const res await getCustomerList({ categoryId: value }) // this.allCustomerOptions res.data // this.customerLoading false }, handleCustomerChange(value) { // 如果還有第三級(jí)這里繼續(xù)清空第三級(jí)的值 console.log(selected customer:, value) }, handleSearch() { this.$emit(search, { ...this.filterForm }) }, handleReset() { this.filterForm { categoryId: null, customerId: null, orderStatus: null } } } }這里最容易被忽略的地方是clearable清空按鈕的處理。用戶點(diǎn)父級(jí)下拉的小叉號(hào)也觸發(fā)了change此時(shí)value是null如果你不處理子級(jí)會(huì)把上一次選中的值“殘留”下來。所以我上面的代碼里clear分支同樣會(huì)把后代的customerId設(shè)置為null然后return掉后續(xù)操作。計(jì)算屬性的寫法是我個(gè)人很推崇的currentCustomerOptions不單獨(dú)存儲(chǔ)一份可變數(shù)組而是通過filter計(jì)算得出。這樣做的最大好處是——數(shù)據(jù)源始終是單向的、可追溯的無論父級(jí)選中什么算出來的永遠(yuǎn)是對(duì)的不會(huì)出現(xiàn)“狀態(tài)忘記同步”這種bug。只有在接口返回的候選列表需要緩存時(shí)才去維護(hù)一份categoryId - customers的映射。2.3 遠(yuǎn)程搜索客戶名稱的數(shù)據(jù)量大了怎么辦如果客戶名稱這個(gè)下拉框有上千條數(shù)據(jù)全部一次性放進(jìn)el-option里瀏覽器渲染會(huì)有明顯的卡頓感。Element UI的el-select原生支持遠(yuǎn)程搜索就是把filterable換成filterable remote再配一個(gè)remote-method方法。el-select v-modelfilterForm.customerId placeholder請輸入客戶名稱搜索 filterable remote :remote-methodremoteSearchCustomer :loadingcustomerLoading :disabled!filterForm.categoryId stylewidth: 220px el-option v-foritem in currentCustomerOptions :keyitem.id :labelitem.name :valueitem.id / /el-selectmethods: { async remoteSearchCustomer(query) { if (!this.filterForm.categoryId) return if (query ) { this.currentCustomerOptions [] return } this.customerLoading true try { const res await getCustomerList({ categoryId: this.filterForm.categoryId, keyword: query }) this.currentCustomerOptions res.data } finally { this.customerLoading false } } }注意這里就不能用計(jì)算屬性了因?yàn)檫h(yuǎn)程搜索的結(jié)果是服務(wù)端返回的臨時(shí)數(shù)據(jù)必須用一個(gè)mutation方法把它存起來。遠(yuǎn)程搜索有兩個(gè)容易踩的坑一個(gè)是“每次輸入都會(huì)發(fā)請求”要配合防抖另一個(gè)是“上次搜索結(jié)果還殘留”在query為空時(shí)要手動(dòng)清空列表。防抖我習(xí)慣直接寫一個(gè)工具函數(shù)不引額外的庫// utils/debounce.js export function debounce(fn, delay 300) { let timer null return function (...args) { if (timer) clearTimeout(timer) timer setTimeout(() { fn.apply(this, args) }, delay) } } // 組件中 created() { this.remoteSearchCustomer debounce(this.remoteSearchCustomer, 300) }2.4 三級(jí)及以上聯(lián)動(dòng)如何優(yōu)雅擴(kuò)展剛才是兩級(jí)聯(lián)動(dòng)可實(shí)際業(yè)務(wù)里經(jīng)常出現(xiàn)三級(jí)甚至四級(jí)聯(lián)動(dòng)。有的人會(huì)把上文的代碼復(fù)制一份然后改改結(jié)果同一個(gè)方法名出現(xiàn)在多個(gè)下拉里維護(hù)起來像噩夢。我把聯(lián)動(dòng)的核心邏輯封裝成了一個(gè)通用方法本質(zhì)是用一個(gè)“層級(jí)字段配置表”驅(qū)動(dòng)所有層級(jí)的清空和加載// 層級(jí)配置 levelConfig: [ { key: categoryId, childKey: customerId, fetchApi: getCustomerList }, { key: customerId, childKey: orderSourceId, fetchApi: getOrderSourceList } ] methods: { async handleLevelChange(levelKey, value) { const level this.levelConfig.find(config config.key levelKey) // 清空該層級(jí)下所有后代的值 if (level level.childKey) { this.filterForm[level.childKey] null } if (!value) return // 后續(xù)可根據(jù)配置繼續(xù)加載下一級(jí) } }這個(gè)方案看著簡單但是擴(kuò)展性是質(zhì)的提升。以后要加第五級(jí)、第六級(jí)只需要在配置表里加一行然后模板里加一個(gè)el-select邏輯層完全不用動(dòng)。如果你所在的項(xiàng)目篩選層級(jí)特別多建議一開始就按這個(gè)思路來做抽象別等到改到第三版再來重構(gòu)。3. 用el-cascader處理真正的樹形層級(jí)場景3.1 什么時(shí)候該用el-cascader在某些場景下多個(gè)el-select聯(lián)動(dòng)的形態(tài)反而不合適。比如做“渠道歸屬”篩選渠道的層級(jí)可能是不固定的——有的渠道下面有子渠道有的沒有用戶希望的是“選中最終子級(jí)查詢這個(gè)子級(jí)的所有單量”但又需要能看到完整的層級(jí)關(guān)系。這種時(shí)候你用三個(gè)el-select會(huì)發(fā)現(xiàn)第三級(jí)的選項(xiàng)經(jīng)常是空數(shù)組因?yàn)闆]那么多深度。遇到這種“層級(jí)深度不固定”“層級(jí)關(guān)系需要一眼看全”的場景直接用el-cascader就對(duì)了。它本身就是一個(gè)從省市區(qū)選擇器抽象出來的通用組件。對(duì)我這個(gè)項(xiàng)目里的“數(shù)據(jù)權(quán)限范圍”篩選我最終就是用了el-cascader。3.2 el-cascader基礎(chǔ)用法與動(dòng)態(tài)數(shù)據(jù)加載先用最省事的靜態(tài)數(shù)據(jù)方式看個(gè)例子。假設(shè)數(shù)據(jù)源是一棵樹cascaderOptions: [ { value: company, label: 全公司, children: [ { value: sales, label: 銷售部, children: [ { value: sales-1, label: 銷售一組 }, { value: sales-2, label: 銷售二組 } ] }, { value: operations, label: 運(yùn)營部, children: [ { value: operations-1, label: 運(yùn)營一組 } ] } ] } ]模板部分el-cascader v-modelfilterForm.dataScope :optionscascaderOptions :props{ checkStrictly: true, emitPath: false } placeholder請選擇數(shù)據(jù)權(quán)限范圍 clearable stylewidth: 220px changehandleDataScopeChange /這里有兩個(gè)屬性的作用必須講清楚不然會(huì)踩很大的坑checkStrictly: true表示可以選擇任意一級(jí)不強(qiáng)制要求選中葉子節(jié)點(diǎn)。這個(gè)在篩選場景里非常重要。你想想如果用戶想篩“銷售部”這個(gè)整層的數(shù)據(jù)但組件強(qiáng)制他選到“銷售一組”才能生效那這個(gè)篩選器就是個(gè)半殘品。emitPath: false表示v-model綁定的值只保留選中節(jié)點(diǎn)的value而不是一個(gè)自root開始的路徑數(shù)組。如果設(shè)置成默認(rèn)的emitPath為truev-model會(huì)變成類似[company, sales, sales-1]這樣的數(shù)組不僅數(shù)據(jù)形態(tài)怪傳給后端還要自己拼接非常麻煩。3.3 遠(yuǎn)程加載大樹懶加載才是正解如果是真正的組織架構(gòu)樹或者分類層級(jí)特別深一次性把所有節(jié)點(diǎn)返回給前端生成樹很容易把接口和瀏覽器都干垮。cascader原生支持懶加載通過props里的lazyLoad來實(shí)現(xiàn)。el-cascader v-modelfilterForm.dataScope :propscascaderProps clearable stylewidth: 220px / script export default { data() { return { cascaderProps: { checkStrictly: true, emitPath: false, lazy: true, lazyLoad: this.lazyLoadNode } } }, methods: { async lazyLoadNode(node, resolve) { // node.level從0開始0就是根節(jié)點(diǎn) const parentId node.level 0 ? null : node.value const res await fetchScopeTree({ parentId }) const nodes res.data.map(item ({ value: item.id, label: item.name, leaf: !item.hasChildren })) resolve(nodes) } } } /script懶加載有幾個(gè)點(diǎn)必須注意。第一leaf字段必須根據(jù)后端返回的hasChildren來正確設(shè)置否則葉子節(jié)點(diǎn)還會(huì)帶著展開箭頭點(diǎn)擊時(shí)又發(fā)一次請求白給接口增加壓力。第二lazyLoad是在props里定義的函數(shù)如果里面用到了this要確保此時(shí)的this指向組件實(shí)例如果不確定就改成箭頭函數(shù)。第三點(diǎn)是我實(shí)際踩過的坑切換篩選條件時(shí)cascader已展開的節(jié)點(diǎn)緩存不會(huì)自動(dòng)清空。比如你先選了“銷售部”再切到別的條件回來看會(huì)發(fā)現(xiàn)展開的還是之前的狀態(tài)。要給cascader加一個(gè)key來強(qiáng)制重建或者手動(dòng)調(diào)用它的clearCheckedNodes方法。4. 篩選框與表格/列表聯(lián)動(dòng)的工程實(shí)踐4.1 查詢參數(shù)的統(tǒng)一管理到了這一步你的篩選區(qū)長什么樣已經(jīng)基本定了但真正讓篩選“活起來”的是跟表格數(shù)據(jù)的聯(lián)動(dòng)。在實(shí)際項(xiàng)目里這個(gè)聯(lián)動(dòng)不是簡單地把filterForm對(duì)象丟給接口就完事而是要把“查詢參數(shù)”和“分頁參數(shù)”統(tǒng)一管理起來。我習(xí)慣的做法是在頁面組件中單獨(dú)維護(hù)一個(gè)queryParams對(duì)象用它來存儲(chǔ)真正會(huì)傳給后端的查詢參數(shù)。filterForm只負(fù)責(zé)界面上的值當(dāng)用戶點(diǎn)擊“查詢”按鈕時(shí)才把篩選區(qū)里的值同步過去。data() { return { queryParams: { categoryId: null, customerId: null, orderStatus: null, dataScope: null, pageNum: 1, pageSize: 10 }, tableData: [], total: 0 } }, methods: { async fetchTableData() { const res await getOrderList(this.queryParams) this.tableData res.data.records this.total res.data.total }, handleSearch() { // 查詢時(shí)重置頁碼到第一頁 this.queryParams { ...this.queryParams, ...this.filterForm, pageNum: 1 } this.fetchTableData() } }這里的核心原則是界面輸入狀態(tài)和真正的請求狀態(tài)分離。如果你把filterForm直接綁定到queryParams的引用上用戶在選下拉的過程中就可能觸發(fā)多次請求既浪費(fèi)帶寬又會(huì)讓頁面閃爍。篩選區(qū)“填寫”和“生效”這兩個(gè)動(dòng)作分開是工程化成熟度的分水嶺。4.2 值類型與傳參格式的坑多級(jí)篩選中值類型不一致是個(gè)高頻坑。el-select選中后v-model里的值它是option的value屬性對(duì)應(yīng)的值。如果value綁定的是數(shù)字id那filterForm里就是number類型但el-cascader如果設(shè)置了emitPath為false選中的值是葉子node的value這個(gè)value可能是number也可能是string取決于你的數(shù)據(jù)定義。后端的接口參數(shù)往往對(duì)類型要求嚴(yán)格。傳到后端之前我習(xí)慣做一次類型歸一化處理尤其是cascader的值handleSearch() { const params { ...this.filterForm, // 空字符串統(tǒng)一轉(zhuǎn)成null避免后端報(bào)參數(shù)格式錯(cuò)誤 categoryId: this.filterForm.categoryId || null, customerId: this.filterForm.customerId || null, // cascader的值可能是數(shù)字0要小心判斷 dataScope: this.filterForm.dataScope ?? null } this.queryParams { ...this.queryParams, ...params, pageNum: 1 } this.fetchTableData() }注意看dataScope這里我用了??空值合并運(yùn)算符不是||。因?yàn)閏ascader的value可能從0開始如果value是00 || null會(huì)得到null這就不對(duì)了。用??只有在null或undefined時(shí)才返回右邊的默認(rèn)值。這個(gè)細(xì)節(jié)坑過我好幾次排查了半小時(shí)才發(fā)現(xiàn)是值被||吞掉了。4.3 篩選條件的回顯處理URL帶參進(jìn)入頁面、從詳情頁返回列表頁時(shí)需要恢復(fù)篩選條件這種需求在管理后臺(tái)也經(jīng)常出現(xiàn)。如果篩選條件存到了瀏覽器的sessionStorage里回顯時(shí)就要把值重新賦值給filterForm。有一個(gè)特別隱蔽的問題在el-select上如果回顯的值在選項(xiàng)中不存在下拉框會(huì)顯示這個(gè)值而不是label。比如后端返回的categoryId是99但選項(xiàng)里根本沒有id為99的選項(xiàng)那下拉就會(huì)顯示一個(gè)“99”的數(shù)字很丑也很奇怪。這時(shí)候要做一次數(shù)據(jù)兜底把不在選項(xiàng)里的值清掉。mounted() { const cached sessionStorage.getItem(orderFilter) if (cached) { const parsed JSON.parse(cached) this.filterForm { categoryId: this.validateValue(parsed.categoryId, this.customerCategoryOptions), customerId: this.validateValue(parsed.customerId, this.currentCustomerOptions), orderStatus: parsed.orderStatus || null } } }, methods: { validateValue(value, options) { if (value null || value undefined || value ) return null return options.some(item item.id value) ? value : null } }注意回顯客戶名稱時(shí)有個(gè)先后順序問題必須先回顯categoryId等currentCustomerOptions計(jì)算出來之后再回顯customerId。否則customerId驗(yàn)證時(shí)currentCustomerOptions還是空數(shù)組就被錯(cuò)誤地清掉了。這也是聯(lián)動(dòng)篩選回顯的經(jīng)典順序難題。4.4 重置篩選條件的三種姿勢重置篩選看起來很簡單就是值清空但在實(shí)際項(xiàng)目里重置的觸發(fā)渠道有三種處理方式略有不同。第一種是“重置”按鈕點(diǎn)擊。這個(gè)邏輯最簡單把filterForm整體重置為空對(duì)象然后調(diào)用查詢。handleReset() { this.filterForm { categoryId: null, customerId: null, orderStatus: null, dataScope: null } // 有表單校驗(yàn)的話要清除校驗(yàn)狀態(tài) this.$refs.filterForm this.$refs.filterForm.clearValidate() this.handleSearch() }第二種是每個(gè)下拉框自帶的clearable清空。這種要記得在change回調(diào)里通知父組件。如果父組件里還有其他篩選邏輯聯(lián)動(dòng)必要時(shí)還要手動(dòng)觸發(fā)一次查詢。第三種是“重置所有默認(rèn)條件”一般出現(xiàn)在篩選條件特別多、還有默認(rèn)值的頁面。比如有個(gè)“只看有效數(shù)據(jù)”的開關(guān)重置時(shí)希望開關(guān)恢復(fù)到true而不是空。這種情況下我會(huì)先把默認(rèn)篩選條件定義為一個(gè)常量const DEFAULT_FILTER { categoryId: null, customerId: null, orderStatus: null, dataScope: null, onlyValid: true }然后重置的時(shí)候this.filterForm { ...DEFAULT_FILTER }。用展開運(yùn)算符復(fù)制一份而不是直接賦值同一個(gè)對(duì)象引用否則后續(xù)修改filterForm會(huì)改到DEFAULT_FILTER本身。5. 常見問題與排查技巧實(shí)錄寫到這里我把這段時(shí)間里碰到的典型問題和排查思路整理成一張速查表都是網(wǎng)上不一定能搜到的現(xiàn)場經(jīng)驗(yàn)。5.1 問題速查表下拉框的“靈異事件”問題現(xiàn)象可能原因處理方法切換父級(jí)后子級(jí)還殘留上一次的值沒在父級(jí)change里清空子級(jí)統(tǒng)一在change回調(diào)里清空所有后代字段下拉選項(xiàng)很多滾動(dòng)明顯卡頓一次性渲染大量el-option用遠(yuǎn)程搜索或改用el-select-virtual-select選中的值在頁面上顯示為數(shù)字而非文本選項(xiàng)數(shù)據(jù)還沒加載完就賦值了先加載選項(xiàng)數(shù)據(jù)再回顯或做validateValue兜底清除父級(jí)篩選時(shí)子級(jí)下拉自動(dòng)出現(xiàn)一段空白clearable觸發(fā)的change事件沒處理判斷value為空時(shí)同樣清空子級(jí)cascader選完整路徑后傳值給后端口徑不對(duì)默認(rèn)emitPath是truev-model為數(shù)組設(shè)置emitPath:false或自行加工路徑最后一個(gè)值表格刷新時(shí)篩選條件閃爍一下又變空queryParams和filterForm沒有分離讓filterForm只控制界面請求參數(shù)單獨(dú)維護(hù)5.2 下拉框高度與樣式的自定義問題熱詞里提到“element-ui select 選擇器 高度怎么設(shè)置”這也是很多人的痛點(diǎn)尤其在設(shè)計(jì)稿里把下拉框高度和樣式都定義好了拿到Element UI默認(rèn)樣式覺得差距很大。直接寫css覆蓋的話要小心scoped作用域。方法一在全局樣式文件中覆蓋/* 改變select選擇器的高度 */ .el-select__wrapper { min-height: 36px; }但這里要提醒一下Element UI不同版本的下拉框DOM結(jié)構(gòu)是有差異的Element UI 2.x當(dāng)中輸入框的高度樣式類名是.el-input__inner而新版組件庫已經(jīng)把el-select改成了el-select__wrapper結(jié)構(gòu)。如果你用的舊版本覆蓋.el-input__inner生效新版本則要調(diào)整.el-select__wrapper的min-height。方法二給el-select加自定義類名el-select classcustom-filter-select v-model....custom-filter-select .el-select__wrapper { min-height: 36px; }如果可以接受我更推薦直接給el-select設(shè)定style寬度高度跟隨布局自適應(yīng)這樣需要調(diào)整的樣式量最小。別為了好看硬把下拉框壓得很矮下拉框高度太矮會(huì)嚴(yán)重降低點(diǎn)擊命中率尤其在企業(yè)級(jí)后臺(tái)里目標(biāo)用戶都是每天頻繁操作表的人舒適度比顏值更重要。5.3 下拉選項(xiàng)的防閃處理與緩存優(yōu)化頁面初始化時(shí)如果選項(xiàng)數(shù)據(jù)是異步加載的用戶在快速操作時(shí)經(jīng)?？吹较吕颉翱找幌掠殖鰜磉x項(xiàng)”觀感很差。我習(xí)慣在數(shù)據(jù)還沒回來時(shí)用v-loading給篩選區(qū)加個(gè)loading態(tài)字段級(jí)loading可以綁定到el-select的:loading屬性。另一個(gè)比較有效的優(yōu)化是選項(xiàng)數(shù)據(jù)緩存。以客戶名稱為例如果當(dāng)前分類下有1000個(gè)客戶用戶每次重新進(jìn)入頁面都要重新拉一遍接口壓力很大?？梢栽趦?nèi)存里維護(hù)一個(gè)Map以categoryId為key緩存已拉取的數(shù)據(jù)customerCacheMap: new Map(), async fetchCustomersByCategory(categoryId) { if (this.customerCacheMap.has(categoryId)) { this.allCustomerOptions this.customerCacheMap.get(categoryId) return } this.customerLoading true try { const res await getCustomerList({ categoryId }) this.customerCacheMap.set(categoryId, res.data) this.allCustomerOptions res.data } finally { this.customerLoading false } }這種緩存的好處是用戶在多級(jí)下拉之間來回切換時(shí)已經(jīng)加載過的數(shù)據(jù)從第二次開始就走內(nèi)存不會(huì)重復(fù)發(fā)請求。缺點(diǎn)是內(nèi)存占用會(huì)上升所以只建議對(duì)“變動(dòng)頻率低、數(shù)據(jù)量適中”的選項(xiàng)做緩存。像訂單狀態(tài)這種本身就是常量枚舉的根本沒必要走接口。5.4 掛載時(shí)初始數(shù)據(jù)加載的順序篩選區(qū)如果有默認(rèn)值頁面的mounted里就要注意數(shù)據(jù)加載順序。比如默認(rèn)選中了“企業(yè)客戶”分類那么初始化流程應(yīng)該是先請求客戶分類列表分類列表返回后給filterForm.categoryId賦默認(rèn)值賦值觸發(fā)handleCategoryChange如果手動(dòng)賦值不觸發(fā)change則手動(dòng)調(diào)用再加載客戶名稱列表客戶名稱列表返回后給filterForm.customerId賦默認(rèn)值如果不按這個(gè)順序來一上來就給customerId賦值但客戶名稱選項(xiàng)還沒加載這個(gè)值就會(huì)成為上面的“幽靈值”——顯示成數(shù)字而不是名稱。這也是新手最容易踩的坑之一。我習(xí)慣用一個(gè)initFilter方法來統(tǒng)一控制加載順序用async/await保證步驟依次執(zhí)行async initFilter() { await this.fetchCategories() this.filterForm.categoryId 1 await this.fetchCustomersByCategory(1) this.filterForm.customerId 101 }5.5 vue-router參數(shù)聯(lián)動(dòng)刷新頁面后保留篩選條件還有一個(gè)小話題是熱詞里提到的“vue路由參數(shù)”。如果你的列表頁篩選條件需要跟URL同步比如希望用戶把篩選后的URL發(fā)給別人別人打開就能看到同樣的篩選結(jié)果那就要把篩選參數(shù)映射到路由的query上。做法不復(fù)雜handleSearch() { this.$router.replace({ query: { ...this.$route.query, categoryId: this.filterForm.categoryId || undefined, customerId: this.filterForm.customerId || undefined } }).catch(() {}) this.fetchTableData() }然后mounted時(shí)從this.$route.query中恢復(fù)篩選值再走一遍數(shù)據(jù)加載。這里有個(gè)小細(xì)節(jié)$router.replace返回的是一個(gè)Promise在路由跳轉(zhuǎn)重復(fù)或取消時(shí)可能拋出NavigationDuplicated錯(cuò)誤要用.catch(() {})吞掉不然控制臺(tái)會(huì)一直報(bào)紅排查時(shí)特別容易分心。寫在最后關(guān)于Vue和Element UI的多級(jí)下拉篩選框核心其實(shí)不在于你會(huì)不會(huì)用el-select或者el-cascader而在于你有沒有把“界面輸入狀態(tài)”“請求參數(shù)狀態(tài)”“數(shù)據(jù)來源狀態(tài)”這三者的關(guān)系理清楚。我這次做下來最大的體會(huì)是組件只是工具真正難的是數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)和聯(lián)動(dòng)邏輯的邊界控制。父級(jí)一變化哪些要清空、哪些要重新拉取、哪些要禁用這些規(guī)則在寫代碼之前就應(yīng)該在紙上畫明白否則后期每一級(jí)新增聯(lián)動(dòng)都會(huì)是一次傷筋動(dòng)骨的改動(dòng)。如果你也在做類似的后臺(tái)管理系統(tǒng)建議先不要急著抄組件代碼拿一張紙把你的篩選層級(jí)、依賴關(guān)系、數(shù)據(jù)來源列一遍再回來動(dòng)手。把基礎(chǔ)打牢后面不管換成el-cascader還是自己封裝樹形組件都能輕松接住。這套方案里的處理思路換成其他UI庫比如Ant Design Vue的Select或Cascader一樣適用變化的只是API的寫法不變的是那三條狀態(tài)管理的原則。