我們團(tuán)隊(duì)半年前接手了一個(gè)中后臺項(xiàng)目第一版急著上線組件基本是頁面拆分法——一個(gè)路由對應(yīng)一個(gè).vue文件公共部分全靠復(fù)制粘貼。結(jié)果二期需求一來改動(dòng)點(diǎn)散落在十幾個(gè)文件里一個(gè)按鈕的交互調(diào)整要翻三個(gè)組件改完A處炸了B處。痛定思痛之后我把整個(gè)項(xiàng)目的組件梳理重構(gòu)了一遍這中間踩了不少坑也想明白了很多事。這篇文章不打算講Vue的基礎(chǔ)語法而是聚焦組件化開發(fā)這件事本身邊界怎么劃、數(shù)據(jù)怎么傳、復(fù)用怎么做、性能怎么顧以及我實(shí)際項(xiàng)目里遇到的一些典型問題的完整排查過程。1. 組件粒度的劃分邏輯別把拆文件當(dāng)成組件化很多初學(xué)者理解的組件化就是把一個(gè)頁面拆成好幾個(gè).vue文件這個(gè)理解不算錯(cuò)但遠(yuǎn)遠(yuǎn)不夠。我在代碼評審里見過一個(gè)非常典型的問題有人把一個(gè)表單頁拆成了FormHeader.vue、FormBody.vue、FormFooter.vue看起來結(jié)構(gòu)清晰但實(shí)際上三個(gè)組件之間用$emit和props傳了幾十個(gè)字段父組件里塞滿了各種回調(diào)函數(shù)改一個(gè)字段校驗(yàn)規(guī)則要在三個(gè)文件里來回跳。這不是組件化這是把一個(gè)大文件拆成了三個(gè)互相依賴的小文件復(fù)雜度一點(diǎn)沒降反而因?yàn)橥ㄐ懦杀旧吡恕?.1 拆分的本質(zhì)是封裝變化不是切分頁面組件拆分的真正目的是把會(huì)一起變化的邏輯和視圖收攏在一起把不會(huì)一起變化的邏輯隔離開來。我傾向于用三個(gè)問題來判斷一個(gè)組件是否需要拆分這段代碼是否會(huì)在多個(gè)地方復(fù)用這段代碼是否只跟某一塊獨(dú)立的業(yè)務(wù)強(qiáng)相關(guān)跟外層頁面其他部分沒有直接耦合這段代碼是否有獨(dú)立的狀態(tài)管理需求如果三個(gè)問題的答案都是否那它就只是一段普通的模板片段強(qiáng)行拆成組件反而增加通信成本。比如頁面頂部的標(biāo)題欄如果整站只有一個(gè)頁面用到而且只是展示文字那就沒必要抽組件。反之如果項(xiàng)目里有十個(gè)頁面都要用同一個(gè)用戶選擇器要處理遠(yuǎn)程搜索、多選、回顯、禁用狀態(tài)這種就必須拆——因?yàn)樗型暾?dú)立的交互邏輯和內(nèi)部狀態(tài)。1.2 我目前比較穩(wěn)定的拆分習(xí)慣實(shí)際項(xiàng)目中我總結(jié)了一套自己的拆分節(jié)奏按照業(yè)務(wù)組件 通用組件 基礎(chǔ)組件三層來做層級例子特點(diǎn)基礎(chǔ)組件UI組件按鈕、輸入框、彈窗、日期選擇器不感知業(yè)務(wù)純展示基礎(chǔ)交互通常用第三方庫如Ant Design Vue通用業(yè)務(wù)組件用戶選擇器、部門樹、文件上傳、商品選擇彈窗綁定特定業(yè)務(wù)實(shí)體內(nèi)部有數(shù)據(jù)請求邏輯但跟具體頁面無關(guān)頁面級業(yè)務(wù)組件訂單表單、商品詳情卡片、審批列表跟頁面強(qiáng)相關(guān)可以獨(dú)立維護(hù)其他頁面基本不會(huì)用這個(gè)分層的核心意義在于依賴方向基礎(chǔ)組件不依賴業(yè)務(wù)組件通用業(yè)務(wù)組件不依賴頁面級組件。一旦出現(xiàn)反向依賴比如通用組件里引了某個(gè)頁面的接口復(fù)用性就廢掉了。經(jīng)驗(yàn)心得組件拆分的粒度沒有絕對標(biāo)準(zhǔn)但有一個(gè)可以落地的檢驗(yàn)方法——如果一個(gè)組件里同時(shí)存在v-for、v-if、多個(gè)props分支判斷、超過三個(gè)$emit事件基本就可以考慮繼續(xù)拆了。反之如果一個(gè)組件只有props展示沒有內(nèi)部狀態(tài)也沒必要為了看起來組件化而硬拆。2. 組件通信方式的選擇不同場景要用的正確姿勢Vue組件通信的方式非常多props、$emit、v-model、$refs、provide/inject、事件總線、Pinia、Vuex。很多人能背出API但到了真正的項(xiàng)目里不知道選哪個(gè)。我的經(jīng)驗(yàn)是通信方式的選擇本質(zhì)上是在問一個(gè)問題數(shù)據(jù)之間的依賴關(guān)系是單向的還是雙向的是父子的還是跨層級的2.1 props/$emit是默認(rèn)選擇但要注意數(shù)據(jù)流向父子通信最普通但也不是隨便用的。我見過有人在props里傳對象子組件里直接this.propsObj.xxx newVal改屬性這在Vue 2里是能運(yùn)行的但會(huì)破壞單向數(shù)據(jù)流。后續(xù)排查問題的時(shí)候你根本不知道這個(gè)對象的某個(gè)屬性是被哪個(gè)組件改掉的。正確做法是子組件把修改意圖$emit上去由父組件來改數(shù)據(jù)!-- 子組件 -- template el-input :model-valuemodelValue update:model-valueval $emit(update:modelValue, val) / /template script setup defineProps([modelValue]) defineEmits([update:modelValue]) /script用v-model語法糖來簡化這種受控組件的寫法模板看起來簡潔很多而且父組件和子組件的數(shù)據(jù)流仍然保持?jǐn)?shù)據(jù)在父、行為在子的單向邏輯。2.2 provide/inject跨層級傳遞的邊界provide配inject解決的是跨層級透傳問題。比如一個(gè)復(fù)雜頁面里的根組件向下傳項(xiàng)目上下文信息中間隔了三層組件每層都用props中轉(zhuǎn)太痛苦provide/inject就非常合適。但這里有個(gè)非常常見的坑provide里的數(shù)據(jù)如果不是響應(yīng)式的子組件接收后不會(huì)自動(dòng)更新。我踩過一次在父組件里provide了一個(gè)普通對象接口返回后改了對象里的某個(gè)數(shù)組子組件里的inject拿到的還是舊值。排查了半天才發(fā)現(xiàn)問題出在響應(yīng)性上。所以使用provide時(shí)要注意要么直接provide一個(gè)ref、reactive對象要么用computed包裝一層。// 父組件 const projectInfo ref({ name: , owner: }) provide(projectInfo, projectInfo) // 子組件 const projectInfo inject(projectInfo)這么處理之后接口數(shù)據(jù)更新時(shí)子組件里用到的projectInfo也能自動(dòng)刷新。我一般用provide/inject來傳遞上下文狀態(tài)——比如當(dāng)前登錄用戶、當(dāng)前項(xiàng)目ID、權(quán)限配置這類全局性的、讀取頻率高且基本不怎么變的數(shù)據(jù)。2.3 事件總線為什么不推薦以及什么時(shí)候真的該用事件總線new Vue()或mitt在Vue 2時(shí)代很流行到了Vue 3雖然也可以實(shí)現(xiàn)但官方已經(jīng)不太推薦了。原因很簡單全局事件不好追蹤。出問題的時(shí)候你不知道事件是誰發(fā)的也不知道誰在監(jiān)聽代碼量一大就變成事件滿天飛。而且組件銷毀時(shí)如果忘記off解除監(jiān)聽還會(huì)造成內(nèi)存泄漏。我之前在一個(gè)老項(xiàng)目里查過一個(gè)詭異的bugA頁面提交表單成功觸發(fā)了B頁面的數(shù)據(jù)刷新當(dāng)時(shí)就是靠一個(gè)全局事件總線跨頁面通信最后發(fā)現(xiàn)B頁面已經(jīng)銷毀了但監(jiān)聽還在反復(fù)提交后頁面越來越卡。定位到原因后我把這個(gè)全局事件改成了Pinia里的狀態(tài)管理。但這不代表事件總線完全不能碰。在極少數(shù)場景下比如多個(gè)組件需要共同響應(yīng)一個(gè)外部系統(tǒng)事件比如WebSocket推送消息、全局快捷鍵用一個(gè)統(tǒng)一的mitt實(shí)例還是比在每個(gè)組件里各自管理生命周期要省事。這種情況下把事件名定義成常量集中管理并且組件卸載時(shí)記得off問題也不大。2.4 Pinia是跨組件共享數(shù)據(jù)的最終歸屬當(dāng)數(shù)據(jù)需要在多個(gè)非父子組件之間共享或者多個(gè)組件要修改同一個(gè)數(shù)據(jù)源時(shí)我強(qiáng)烈建議直接上Pinia。相比VuexPinia的API更簡潔去掉了mutations那一層直接在store里寫函數(shù)改state配合setup風(fēng)格的store寫法心智負(fù)擔(dān)低很多。在實(shí)際組件化項(xiàng)目里Pinia通常用來承載真正的全局狀態(tài)用戶信息、權(quán)限點(diǎn)、購物車、或者某個(gè)跨頁面需要保持一致的數(shù)據(jù)。需要注意的是盡量不要把所有的數(shù)據(jù)都塞進(jìn)store。有時(shí)候父子組件之間傳遞最簡單的開關(guān)狀態(tài)也用store反而會(huì)讓組件失去獨(dú)立性。我推薦的判斷標(biāo)準(zhǔn)是如果這個(gè)組件的復(fù)用性要求很高它的內(nèi)部數(shù)據(jù)就不要依賴store而應(yīng)該通過props傳入。這樣以后放到任何頁面都能直接用不用先建一堆store才能跑。3. 插槽設(shè)計(jì)讓組件真正具備擴(kuò)展能力如果你只把組件做成封裝起來的一整塊頁面那它注定很難復(fù)用因?yàn)楝F(xiàn)實(shí)中的業(yè)務(wù)總有那么一點(diǎn)點(diǎn)不同同樣的彈窗組件A頁面要加一個(gè)輸入框B頁面要加一個(gè)表格C頁面要改按鈕文案。這時(shí)候如果每個(gè)差異都用props去控制組件會(huì)膨脹成一個(gè)巨大的if/else怪物。Vue里更好的解法是插槽slot。3.1 作用域插槽的正確用法插槽不只是往組件里塞一段模板這么簡單作用域插槽允許子組件向插槽內(nèi)容傳遞數(shù)據(jù)這樣父組件就能在插槽里拿到子組件的狀態(tài)來定制展示。舉個(gè)例子我封裝過一個(gè)通用的AsyncSelect組件它負(fù)責(zé)遠(yuǎn)程搜索、防抖、loading狀態(tài)、下拉選項(xiàng)數(shù)據(jù)管理。但不同頁面對選項(xiàng)渲染的需求不同有的地方要顯示頭像昵稱有的地方只要顯示部門名。如果我把選項(xiàng)渲染寫死在組件里就沒法復(fù)用了。于是我用作用域插槽把選項(xiàng)數(shù)據(jù)暴露出去AsyncSelect :fetch-apifetchUsers template #option{ item } div classuser-option el-avatar :srcitem.avatar sizesmall / span{{ item.name }}{{ item.dept }}/span /div /template /AsyncSelect這樣AsyncSelect只負(fù)責(zé)數(shù)據(jù)獲取和交互邏輯具體的展示樣式由使用方?jīng)Q定。組件本身不關(guān)心你在選項(xiàng)里顯示什么。3.2 具名插槽與預(yù)留擴(kuò)展位的思路組件封裝的另一個(gè)經(jīng)驗(yàn)是從一開始就預(yù)留擴(kuò)展位。哪怕當(dāng)前只有一個(gè)插槽需求也建議把組件內(nèi)部的關(guān)鍵位置用具名插槽暴露出來。比如一個(gè)Card組件默認(rèn)有header和footer但內(nèi)容區(qū)域到底放什么完全由外部決定。這樣后續(xù)出現(xiàn)新的業(yè)務(wù)需求時(shí)你不需要去改被復(fù)用的老組件而是通過插槽內(nèi)容做擴(kuò)展安全得多。我在重構(gòu)項(xiàng)目時(shí)把原來一個(gè)寫死的OrderDetail組件改成了多個(gè)區(qū)域插槽頂部信息、商品明細(xì)、操作按鈕、擴(kuò)展信息區(qū)。結(jié)果后來新增了一個(gè)物流跟蹤需求完全不需要?jiǎng)雍诵慕M件只在外部調(diào)用時(shí)往擴(kuò)展信息區(qū)塞了一個(gè)LogisticsTimeline組件就搞定了。這就是插槽帶來的解耦能力。4. 組件狀態(tài)管理與生命周期最容易踩坑的地方很多人對組件化開發(fā)的理解停留在模板怎么寫、組件怎么拆但真正到項(xiàng)目中跑起來生命周期和狀態(tài)同步才是最容易出問題的環(huán)節(jié)。我整理了幾個(gè)實(shí)戰(zhàn)中反復(fù)遇到的坑以及最終的排查方案。4.1 組件復(fù)用導(dǎo)致的數(shù)據(jù)殘留有一段場景一個(gè)列表頁點(diǎn)擊編輯按鈕打開一個(gè)彈窗組件彈窗里是一個(gè)表單。第一版代碼彈窗是用v-if控制的打開時(shí)創(chuàng)建組件關(guān)閉時(shí)銷毀組件。后來為了優(yōu)化體驗(yàn)改成用v-show控制顯隱結(jié)果出現(xiàn)了一個(gè)很隱蔽的bugA記錄編輯到一半關(guān)閉彈窗再打開編輯B記錄表單里還是A記錄的數(shù)據(jù)。排查過程先懷疑是表單初始化邏輯沒觸發(fā)檢查created和mounted——發(fā)現(xiàn)組件在v-show下根本不會(huì)重新走生命周期鉤子只有v-if才會(huì)重新創(chuàng)建組件。解決方案有三種方案一保留v-if但增加一個(gè)key來強(qiáng)制組件重建比如:keycurrentRecord.id。這樣每次打開不同記錄時(shí)Vue會(huì)認(rèn)為這是一個(gè)新組件走完整的初始化流程。方案二用watch監(jiān)聽外部傳入的visible或currentRecord在彈窗打開時(shí)手動(dòng)重置表單數(shù)據(jù)。方案三通過$refs調(diào)用子組件暴露的resetForm方法。我落地時(shí)選擇了方案一因?yàn)樗那秩胱钚《襨ey變化后組件內(nèi)部所有狀態(tài)都是全新的不會(huì)殘留。4.2 為什么明明數(shù)據(jù)變了界面不更新另一類高頻問題是修改了數(shù)據(jù)但視圖不動(dòng)。在Vue 3的reactive和ref設(shè)計(jì)中一般不會(huì)出現(xiàn)屬性新增不響應(yīng)這類Vue 2時(shí)代的坑但有一種情況很容易被忽略在computed里直接修改state。比如有人寫了這樣的代碼const count computed({ get() { return store.count }, set(val) { store.count val // 直接改store } })這本身問題不大但如果count被多個(gè)組件引用而且set邏輯里還帶副作用就會(huì)造成一個(gè)組件改了值其他組件也間接受影響但依賴鏈復(fù)雜到根本看不出是誰改的。排查這一類問題我建議用Vue Devtools的組件樹和Pinia面板直接看當(dāng)前組件的computed依賴關(guān)系能比較快地定位到被修改的數(shù)據(jù)源。4.3 組件銷毀時(shí)的清理工作組件化開發(fā)中onUnmountedVue 3階段是很多人會(huì)忽略的。如果組件里創(chuàng)建了setInterval、addEventListener、WebSocket連接或者訂閱了mitt事件必須在銷毀時(shí)清理否則頁面切換多了就會(huì)卡頓甚至報(bào)錯(cuò)。我寫過這樣一個(gè)組件它內(nèi)部用一個(gè)輪詢?nèi)ニ⑿聰?shù)據(jù)當(dāng)時(shí)的代碼如下onMounted(() { this.timer setInterval(fetchData, 3000) })后來我在路由里反復(fù)進(jìn)入退出這個(gè)頁面發(fā)現(xiàn)接口請求次數(shù)越來越多頁面也越來越卡。用DevTools的Performance面板一查發(fā)現(xiàn)每進(jìn)入一次都多了一個(gè)setInterval因?yàn)榕f組件的定時(shí)器沒有清掉。加上onUnmounted里clearInterval之后就正常了。寫組件時(shí)我現(xiàn)在的習(xí)慣是所有在onMounted里打開的資源都必須在onUnmounted里關(guān)閉。這個(gè)習(xí)慣比等出問題再去查高效得多。5. 組件的復(fù)用與擴(kuò)展把單一職責(zé)貫徹到業(yè)務(wù)組件業(yè)務(wù)組件的復(fù)用比基礎(chǔ)組件要難得多。因?yàn)榛A(chǔ)組件通常只是展示交互業(yè)務(wù)組件卻包含了數(shù)據(jù)請求、權(quán)限判斷、業(yè)務(wù)狀態(tài)等復(fù)雜邏輯。如果邊界沒劃好很容易變成看起來復(fù)用實(shí)際上改都改不動(dòng)。5.1 通用業(yè)務(wù)組件的封裝要點(diǎn)以前面說的AsyncSelect為例一個(gè)可復(fù)用的業(yè)務(wù)組件應(yīng)該具備這幾個(gè)特征數(shù)據(jù)獲取能力由外部傳入通過props傳fetchApi組件內(nèi)部不寫死任何接口內(nèi)部狀態(tài)完整搜索詞、loading、選項(xiàng)列表、選中值、下拉開關(guān)全部由組件自己管理對外暴露最小必要接口modelValue雙向綁定、placeholder、disabled等常規(guī)屬性關(guān)鍵展示位用插槽暴露方便外部定制如果業(yè)務(wù)組件里寫死了某個(gè)后端的請求地址或者內(nèi)部調(diào)用了其他業(yè)務(wù)模塊的狀態(tài)那這個(gè)組件的復(fù)用面就非常窄了。封裝時(shí)的核心思想是把變的部分留給使用者把不變的部分沉淀在組件內(nèi)部。5.2 組合式函數(shù)Composables復(fù)用的是邏輯不是組件還有一些場景組件本身不適合復(fù)用但邏輯值得復(fù)用。比如列表頁的搜索、分頁、重置這套流程在很多頁面里都一樣但頁面的模板結(jié)構(gòu)完全不同。這時(shí)候硬抽公共組件反而不靈活更好的做法是用組合式函數(shù)useSearchList把邏輯抽出來。export function useSearchList(fetchApi, { defaultParams {} } {}) { const loading ref(false) const list ref([]) const total ref(0) const params reactive({ ...defaultParams }) async function getList() { loading.value true try { const res await fetchApi(params) list.value res.list total.value res.total } finally { loading.value false } } function reset() { Object.keys(params).forEach(k delete params[k]) Object.assign(params, defaultParams) getList() } return { loading, list, total, params, getList, reset } }這樣每個(gè)頁面只需要少量模板代碼就能復(fù)用整套搜索列表邏輯。相比組件復(fù)用這種方式更輕量也更靈活。組件負(fù)責(zé)復(fù)用視覺交互Composable負(fù)責(zé)復(fù)用純邏輯兩種手段配合使用覆蓋的場景才完整。5.3 先寫代碼再抽象不要過度設(shè)計(jì)我自己之前犯過一個(gè)錯(cuò)誤就是做組件的時(shí)候想著以后可能會(huì)擴(kuò)展加入了很多當(dāng)時(shí)根本用不到的配置項(xiàng)和邏輯分支。結(jié)果代碼復(fù)雜了測試覆蓋也沒跟上后來真正有擴(kuò)展需求的時(shí)候才發(fā)現(xiàn)當(dāng)初預(yù)設(shè)的分支跟實(shí)際需求完全對不上改動(dòng)反而更大。現(xiàn)在我的做法是先讓組件在至少兩個(gè)真實(shí)業(yè)務(wù)場景里跑通然后再根據(jù)這兩個(gè)場景的共性和差異做抽象。如果只有一個(gè)場景在用抽出來的通用性很可能是假的。真正可復(fù)用的組件是在反復(fù)迭代中沉淀出來的而不是靠一次性設(shè)計(jì)出來的。6. 組件渲染性能優(yōu)化從能用到流暢組件化開發(fā)做到后期性能是一個(gè)繞不開的話題。尤其當(dāng)頁面里有很多嵌套組件、長列表、復(fù)雜表格的時(shí)候渲染性能直接決定了體驗(yàn)。6.1 用computed緩存派生狀態(tài)避免重復(fù)計(jì)算很多人寫模板里的過濾和計(jì)算時(shí)習(xí)慣直接在模板里寫方法template div{{ formatTime(item.createTime) }}/div /template script setup function formatTime(time) { /* ... */ } /script這個(gè)寫法的問題是只要組件重新渲染formatTime就會(huì)被重新執(zhí)行。如果列表有幾百條每條都調(diào)用一次性能就是幾百次函數(shù)調(diào)用。更合理的做法是把計(jì)算結(jié)果變成computed或者直接在數(shù)據(jù)層面格式化好。尤其當(dāng)計(jì)算邏輯依賴多個(gè)響應(yīng)式屬性時(shí)computed是有緩存機(jī)制的只有依賴變化時(shí)才重新計(jì)算性能提升非常明顯。6.2 v-if與v-show的選擇還有一個(gè)老生常談但經(jīng)常被用錯(cuò)的問題v-if和v-show。我見過有人把一個(gè)大段組件用v-show控制導(dǎo)致初始化時(shí)就渲染了所有子組件即使它根本不可見也有人把切換頻繁的按鈕用v-if導(dǎo)致每次點(diǎn)擊都要重新創(chuàng)建銷毀組件。我的選擇標(biāo)準(zhǔn)很簡單如果元素只在初始時(shí)渲染一次后續(xù)基本不變用v-if如果元素切換頻繁且內(nèi)部邏輯不復(fù)雜用v-show如果元素內(nèi)部包含大量子組件和復(fù)雜狀態(tài)盡量避免v-show因?yàn)樗m然隱藏了元素但并沒有銷毀組件組件內(nèi)部的onMounted、定時(shí)器、數(shù)據(jù)請求都還在跑6.3 長列表的性能優(yōu)化中后臺項(xiàng)目里長表格、長列表非常常見。幾千條數(shù)據(jù)一次性渲染頁面會(huì)明顯卡頓。我的優(yōu)化思路分幾步讓后端做分頁前端只展示當(dāng)前頁數(shù)據(jù)這是最簡單有效的方式。如果必須一次性加載大量數(shù)據(jù)考慮用虛擬滾動(dòng)——只渲染可視區(qū)域內(nèi)的DOM滾動(dòng)時(shí)動(dòng)態(tài)替換。盡量避免在列表項(xiàng)組件里放太復(fù)雜的子組件列表項(xiàng)越輕滾動(dòng)越流暢。虛擬滾動(dòng)實(shí)現(xiàn)起來有一定成本但網(wǎng)上有不少成熟的方案如vue-virtual-scroller,如果項(xiàng)目確實(shí)需要可以直接引庫。不過拿這個(gè)庫之前一定要自己拉一下demo試一下因?yàn)橛行┨摂M滾動(dòng)方案跟表格的固定列、多級表頭組合時(shí)會(huì)有兼容問題。6.4 借助Vue Devtools定位性能瓶頸排查組件性能問題時(shí)我一般會(huì)打開Vue Devtools的性能標(biāo)簽頁錄制一段交互操作然后看每個(gè)組件的渲染耗時(shí)、依賴追蹤情況。排查的優(yōu)先級是先看是否有組件在數(shù)據(jù)不變時(shí)仍然頻繁重渲染如果有檢查它的props和computed是否穩(wěn)定再看是否有大組件內(nèi)部存在嵌套過深的子組件樹考慮用v-memo、shallowRef或拆分異步組件最后看網(wǎng)絡(luò)請求是否有組件mounted時(shí)同時(shí)發(fā)起了多個(gè)重復(fù)請求Vue 3.2提供的v-memo指令在某些場景下非常有用。比如一個(gè)列表里每一項(xiàng)組件都依賴一個(gè)選中狀態(tài)而選中狀態(tài)只在一個(gè)時(shí)刻改變一個(gè)值但模板里其他內(nèi)容沒有變化時(shí)用v-memo可以直接跳過不必要的diff。不過v-memo要求你非常清楚依賴是什么用錯(cuò)了反而會(huì)導(dǎo)致界面不更新所以我建議項(xiàng)目中有限度使用。7. 幾個(gè)真實(shí)業(yè)務(wù)場景的完整復(fù)盤光講理論容易飄。這里挑三個(gè)我在真實(shí)項(xiàng)目里對接過的組件化難點(diǎn)完整走一遍從問題出現(xiàn)到最終落地的過程。7.1 百度地圖組件第一次打開正常第二次一片空白這是熱搜詞里出現(xiàn)的一個(gè)典型問題。我在一個(gè)項(xiàng)目中封裝了地圖選擇器組件第一次進(jìn)入頁面地圖正常顯示切換路由再回來地圖區(qū)域變成空白。排查過程中我先確認(rèn)了組件確實(shí)走過了onMounted地圖實(shí)例也創(chuàng)建了但容器DOM的寬高在初始化時(shí)是0。這個(gè)問題的根因是百度地圖初始化的時(shí)機(jī)和DOM的渲染時(shí)機(jī)不同步。當(dāng)組件被路由切換重建時(shí)地圖容器雖然掛載了但布局尚未穩(wěn)定寬高還沒被計(jì)算出來地圖初始化就會(huì)失敗。我在排查時(shí)先驗(yàn)證了延遲初始化的思路在nextTick后再setTimeout(0)初始化地圖但這個(gè)方案并不穩(wěn)定。最終我采用了兩個(gè)保險(xiǎn)在onMounted里用nextTick確保DOM布局完成后再初始化地圖。給地圖容器設(shè)置一個(gè)固定的min-height避免寬高為0。同時(shí)用一個(gè)key綁定到組件上當(dāng)?shù)貓D容器重新創(chuàng)建時(shí)強(qiáng)制地圖實(shí)例重新初始化。這個(gè)案例給我的經(jīng)驗(yàn)是組件在二次打開時(shí)產(chǎn)生問題多半是生命周期和外部依賴如地圖、富文本編輯器、圖表的初始化時(shí)序沒有對齊而且排查時(shí)不要一股腦去懷疑框架先確認(rèn)DOM狀態(tài)和外部庫需要的條件是否滿足。7.2 el-select遠(yuǎn)程搜索下拉滾動(dòng)加載更多另一個(gè)熱搜詞是el-select可以遠(yuǎn)程搜索下拉框可以滾動(dòng)請求更多數(shù)據(jù)。中后臺里這是非常常見的需求。難點(diǎn)在于遠(yuǎn)程搜索需要防抖避免每輸入一個(gè)字符就請求一次下拉滾動(dòng)到底部時(shí)需要加載下一頁數(shù)據(jù)并且去重已選中的選項(xiàng)即使不在當(dāng)前搜索結(jié)果里也要回顯我封裝的方案是組件內(nèi)部維護(hù)options數(shù)組、page和keyword狀態(tài)搜索時(shí)重置page1并請求第一頁數(shù)據(jù)滾動(dòng)到底時(shí)page繼續(xù)請求用Map去重選中后把選中的對象單獨(dú)存放在一個(gè)selectedOption里讓顯示值可以正?；仫@。代碼結(jié)構(gòu)大概是el-select v-modelselectedValue filterable remote :remote-methoddebouncedSearch visible-changehandleVisibleChange el-option v-foropt in options :keyopt.id :labelopt.name :valueopt.id / /el-select這里有個(gè)容易踩的坑remote-method觸發(fā)的時(shí)機(jī)比你想象中頻繁如果沒做防抖接口會(huì)被打爆。我習(xí)慣用lodash.debounce包一層或者自己寫個(gè)簡單的定時(shí)器版本。另一個(gè)坑是滾動(dòng)加載的容器不是頁面而是el-select的下拉彈層要監(jiān)聽的是那個(gè)彈層容器的scroll事件而不是頁面的scroll。這個(gè)彈層在DOM里可能不在組件內(nèi)部所以不能用scroll直接綁定需要在onMounted后拿到彈層的DOM元素添加監(jiān)聽并在onUnmounted時(shí)移除。7.3 飛書免登錄跳轉(zhuǎn)Vue項(xiàng)目時(shí)的登錄態(tài)不同步這個(gè)場景更偏向于多系統(tǒng)集成中的組件邊界設(shè)計(jì)。實(shí)際項(xiàng)目中遇到的需求大致是從飛書的工作臺點(diǎn)擊應(yīng)用圖標(biāo)跳轉(zhuǎn)到我們的Vue項(xiàng)目需要自動(dòng)完成登錄而不是讓用戶再輸一次賬號密碼。這里的關(guān)鍵不是組件本身而是應(yīng)用啟動(dòng)時(shí)的會(huì)話打通。我們的做法是在路由前置守衛(wèi)里放一個(gè)全局的登錄攔截如果本地沒有token就嘗試用飛書跳轉(zhuǎn)參數(shù)里的臨時(shí)憑證去換取服務(wù)端的登錄態(tài)。換取成功后再繼續(xù)路由跳轉(zhuǎn)失敗則跳轉(zhuǎn)到登錄頁。從組件化的角度看這個(gè)登錄攔截本質(zhì)上是**整個(gè)應(yīng)用的最高層組件或路由守衛(wèi)**在統(tǒng)一處理而不是每個(gè)頁面組件各自判斷。如果每個(gè)頁面都去處理是否已登錄的邏輯代碼會(huì)非常分散也很難維護(hù)。正確的做法是把這類與應(yīng)用生命周期強(qiáng)相關(guān)的邏輯收斂到全局而不是散落在各個(gè)業(yè)務(wù)組件里。8. 復(fù)盤哪些組件化最佳實(shí)踐其實(shí)是偽需求寫了這么多我想最后聊一個(gè)反直覺的話題。網(wǎng)上很多文章都在強(qiáng)調(diào)組件要足夠通用、足夠解耦、配置要靈活但我的實(shí)際體會(huì)是過度追求這些往往比不拆分更糟糕。我接手過一套組件庫里面每個(gè)組件都有十幾個(gè)props、四五個(gè)插槽、還有一堆computed動(dòng)態(tài)判斷?？雌饋矸浅?qiáng)大但真正用的時(shí)候大部分props從沒被傳入過大部分插槽也從沒被使用過。反而因?yàn)榇a分支太多任何一個(gè)小改動(dòng)都要回歸測試一大堆場景。一個(gè)組件真正被復(fù)用的前提是在真實(shí)場景中確實(shí)出現(xiàn)了復(fù)用的需求。與其在一開始就設(shè)計(jì)一個(gè)萬能組件不如在第一個(gè)使用場景里把組件做到剛好夠用在第二個(gè)使用場景出現(xiàn)時(shí)再根據(jù)差異抽象出擴(kuò)展點(diǎn)。我在重構(gòu)項(xiàng)目時(shí)發(fā)現(xiàn)一個(gè)很有意思的現(xiàn)象真正被復(fù)用的組件往往是在三個(gè)以上的頁面中都長得很像的那部分而那些當(dāng)初精心設(shè)計(jì)的萬能組件反而因?yàn)闆]人敢用最終成了死代碼。組件化的價(jià)值是讓系統(tǒng)的復(fù)雜度可控不是讓組件數(shù)量變多。每抽出一個(gè)組件都應(yīng)該讓代碼邏輯更清晰、改動(dòng)面更小、可讀性更高。如果拆完之后發(fā)現(xiàn)改動(dòng)一個(gè)功能要同時(shí)改三個(gè)組件那大概率是拆分方向出了問題而不是組件化本身沒用。另一個(gè)體會(huì)跟組件命名有關(guān)。好的組件名應(yīng)該讓人一看就知道它是干嘛的而且要能看明白它的層級。項(xiàng)目里我見過大量index.vue文件點(diǎn)進(jìn)去才知道是什么組件。雖然這是很多腳手架默認(rèn)生成的命名但長期維護(hù)下來這種命名方式真的會(huì)增加定位成本。我現(xiàn)在的做法是通用組件名用名詞名詞如UserSelect、DeptTree頁面組件名用頁面名業(yè)務(wù)名如OrderDetailPanel盡量不用index.vue作為唯一命名。組件化開發(fā)這條路沒有標(biāo)準(zhǔn)答案但有一些共性的原則邊界要清晰、數(shù)據(jù)流要可追蹤、復(fù)用要基于真實(shí)需求、性能要有意識地去關(guān)注。每次你拿到一個(gè)需求先不要急著寫模板花幾分鐘想想這個(gè)功能跟其他頁面的現(xiàn)有能力是什么關(guān)系哪些東西應(yīng)該收斂到組件內(nèi)部哪些能力應(yīng)該以插槽或props的形式對外暴露想清楚了再動(dòng)手后面的維護(hù)成本會(huì)低很多。