切換語言為:簡體

前段進階必須掌握的模組化與元件化

  • 爱糖宝
  • 2024-07-30
  • 2076
  • 0
  • 0

如果把程式設計比作一門武學,除了掌握紮實的基本功外。想要進階為大宗師,我們還得內外兼修,掌握像vue,react等高階招式。更重要的是需要精進物件導向的高階內功心法。

什麼是模組化

在前端發展歷程中,起初並沒有模組化的概念,從原生js開發到jQuery一把梭,一個html中穿插著各式各樣的js檔案,相互之前不好隔離,變數與方法都是提升到全域性。隨著專案複雜度的提升,變得不利於維護管理。並且沒辦法很好的滿足“高內聚,低耦合” 的思想。逐漸的,模組化開發在社羣裡面流行了起來。

前端模組化可以將一個大型的前端專案拆分成多個小模組,方便管理和維護。常見的前端模組化規範有 CommonJS、AMD、CMD 和 ES6 Module。

這些模組化方案都各具特色,這裏優先建議使用ES6 Module

什麼是元件化

其實web從一開始變有了元件化的思想,只是直到react,vue等流行起來之後,元件化的思想纔開始深入人心,伴隨著我們的日常開發。

在元件化的思想裡面,我們認為一個網頁的呈現可以由若干個UI元件組成,一個元件只是網頁組成部分的一個單位而已。而元件化又十分靈活,我們可以元件巢狀,組合,打散等等,將各類複雜應用合理的拆分成一個個便於維護的元件單位。然後形成一棵枝繁葉茂的元件樹

原生元件化(Shadow DOM)

html中有各式各樣的標籤,這些標籤就是一個個的元件。例如:video,input,button...等等,都html內建好的web component。

除此之外,我們也可以透過 shadow DOM 的方式去自定義實現一個原生的web元件。

框架元件化(react,vue,angular,svelte...)

這些主流的前端框架更加豐富了元件的定義,生命週期,元件通訊,資訊隔離等等功能,利用現在主流的前端框架,我們可以輕鬆的實現元件化開發,極大提高了開發效率與質量。

元件化開發的設計思路

當我們對一個專案或者網頁進行元件化設計的時候,應該權衡利弊,找到一個合理的平衡點。因為過渡的拆分元件會使得程式碼過於分散,複雜度高。如果元件抽象程度不夠,程式碼又過於冗餘,複用性不高。如何透過合理的設計元件,來對程式碼進行解耦與分類,是一個值得思考的問題。

在各類場景下應該如何封裝元件?

對於何時應該封裝一個元件,每個人的見解都不一樣。有人認為多處地方使用了相同的邏輯,就應該抽離一個元件,有人認為元件拆分之後程式碼變多了,元件之前通訊變複雜了,還不如不封裝元件。那麼在面對複雜多變的需求業務場景下,我們應該如何去合理拆分元件呢?

一、  分析網頁的UI組成

當我們在UI設計師哪裏拿到一張精美的設計稿的時候,我們首先是需要看著設計稿開始分析網頁的組成部分是什麼?例如一個後臺管理系統,最經典的就是聖盃佈局,整個網頁可以分為“頭部導航欄”,“左側選單”,“右側內容”,“底部描述”。基於基本佈局,我們至少便需要封裝四個基本元件,再根據元件複雜度進一步拆分

二、  元件顆粒度定義

● 原子級元件:最小單位的元件,這類元件通常只包含一個單一功能,不參雜多餘的業務程式碼。例如網頁中的按鈕,圖示,輸入框,下拉框等。原子級的元件應該具備最大通用性與複用性。市面上大多數UI元件庫提供了許多原子級元件,極大提高了開發效率。

● 分子級元件:由多個不同的原子級元件組成,通常實現了一些基礎常見的功能模組。例如:級聯選擇器,穿梭框,標籤頁等。

● 複合型元件:由多個不同的原子級和分子級元件組成,通常實現了一些較為複雜的業務功能。例如:表格,表單,日曆,tree樹等。

● 頁面級元件:集大成者,由多個不同的原子,分子,複合元件組成,通常實現了一些具有獨立業務需求的功能模組。例如:購物車列表,收貨地址設定,導航選單等。

三、  什麼情況下應該抽離元件?

講了這麼多,那麼在面對日益複雜的業務需求時。怎樣合理的抽象元件,達到一個合理的平衡點呢?在什麼情況下,我們需要抽離元件出來呢?

● 頁面UI層次分明,複雜度高

○ 當頁面UI層次分明且複雜度高的時候,我們第一時間應該是考慮“拆”,根據頁面特性,ui展示,業務需求不同維度去拆成一個個元件

● 多出地方使用,出場率高

○ 當一個ui元件會以相同的形式出現在不同地方,只需要透過引數控制即可滿足不同場景時。便可以考慮將這些邏輯封裝成一個元件多處使用了

● 具備完整的功能閉環

○ 某些業務場景功能比較純粹,功能單一且能完整閉環,例如某個純展示的卡片資訊面板,步驟條顯示,一些特定業務邏輯處理的包裝元件等。這個時候變可以考慮將其封裝成一個元件。

● 業務極其複雜且耦合度高

○ 在面對業務複雜且耦合度高的需求開發時,就可以利用元件拆分來對程式碼進行解耦以達到邏輯分解,關注點分離,提高程式碼質量的目的

● 無需關注內部實現,只關心結果呈現

○ 日常開發中經常會遇到一些“黑匣子”開發,在此類場景上我們往往不需要關注元件內部實現,只需要該元件能在網頁上正常執行預期結果即可。例如:一個圓形的餅狀統計圖,一個播放器的二次包裝,一個canvas畫板容器等

如何設計一個優秀的元件

說一千道一萬,我們應該如何才能設計好一個優秀的元件,一個優秀的元件應該具備什麼品質呢?

● 從需求角度出發

○ 當接到一個需求之後,應該第一時間去理解需求。考慮需求的本質與後續迭代可能會產生的變化。從而再去設計元件,以便應對需求的持續更新

● 從UI設計稿角度出發

○ 在透過程式碼還原設計稿之外,還需要考慮好元件樣式的相容性,不同螢幕尺寸的適配性,文案長短,異常資料顯示,預設頁展示等等

● 從使用者角度出發

○ 開發完一個元件,往往是需要提供給團隊的其它成員或者是自己使用的。這裏用上很喜歡的一句話「程式碼只是能友好的執行在機器上,但最終是寫給人看的」

○ 要以人為本,多為元件的使用者著想。想想別人在使用該元件的時候,心裏會不會罵娘,一段時間後自己在回過頭來看這個元件的程式碼,是否能看得懂

● 從元件自身角度出發

○ 元件本身要經過足夠多的測試,以確保元件能夠在不同場景下穩定執行

○ 對外暴露的api配置要儘量精煉且滿足功能

○ 對外暴露的api以及元件關鍵程式碼處需留下注釋或者api文件

○ 具備一定的拓展性和維護性,以確保使用者能在不修改原始碼的情況下實現一些定製化需求

○ 具備極強的易用性,簡單性。別讓元件的使用成本過高心智負擔過重

○ 對入參有一定的包容性,對出參有一定的健壯性。對一些引數型別,引數值做兜底與相容處理,對出參同樣要保持穩定,必要時給出相應的異常描述以便排查問題

○ 元件需要具備一定的靈活性,做到像介面一樣即插即用

○ 無副作用,無不良依賴。儘量避免與其他業務耦合,職責單一

○ 具備極強「普適性」要能最大程度的與其他元件組合使用,且不造成汙染

結束語

不難看出,不論是模組化還是元件化,其本質都是基於物件導向思想開發。在程式碼中多使用物件導向的思想,能使得我們的程式碼結構,組織邏輯,優雅程度更上一層樓。許多的設計模式看似高深,在理解了物件導向之後,再看這些設計模式就會有一種原來如此,恍然大悟的感覺。行走於江湖,修得此心法,必將突破天元境!

0則評論

您的電子郵件等資訊不會被公開,以下所有項目均必填

OK! You can skip this field.