Vue組件化思考

項目結束一段時間，寫個文章總結下。初入項目組，看到了3000行的vue文件，一口血差點捧出，無奈上一個程序員已經離職，留下的坑，只能本身填上了。在重構項目的過程當中，也發現了一些別的問題，組內分享會作了總結分享，此次總結成文章特此記錄。

用搭積木的方式構建vue組件，就如同搭積木同樣，構建咱們的項目

在項目中，對於組件的劃分，咱們通常會劃分爲業務組件和功能組件，也能夠稱爲視圖組件和容器組件。在react中也被稱爲無狀態組件和UI組件。組件劃分明確，對於代碼的可維護性和閱讀性有必定的便利性。劃分方式以下圖所示：

組件設計考量，分而治之

天下大事，分久必合，合久必分。組件亦然，由之前的寫在一塊兒，到現在的明確劃分。分而治之的思想，也可讓咱們更加專一於主要的功能實現，便於擴展和複用。
在組件的設計中，須要考慮如下幾點：

可擴展性強

擴展性首先是咱們要考慮的點，若是不能擴展，就表明着代碼寫死，失去了代碼的靈活性

組件中方法函數的抽離，便於複用，適用程度高。

儘量使用方法定義，避免使用template表達式，不便於複用

文檔清楚詳細

畢竟寫的組件是給人用的，不完善的文檔讓別人如何使用，確定不能手把手教別人怎麼使用吧，因此一個組件詳細的使用說明是必須的。

顆粒度合適，適度抽象

這個是一個經驗的問題，如何衡量顆粒度是否合適，實際上是一個度的問題，每一個人有每一個人的見解，可是儘可能保證一個組件完成的功能是單一的，而不是多個功能的結合體。

功能儘量單一，代碼行數適中

這一點和上面顆粒度相似，以代碼行數衡量也能夠，通常的組件若是抽離合適的話，絕對不會超過1000行，若是代碼太多，就說明組件劃分不合理，抽離不完善，須要從新設計。

必要的時候須要ui的配合（設計不止於好看，更關乎好用。—喬布斯）

有的組件設計出來太醜，程序員的眼光和一個專業的設計師的眼光仍是有必定差距的，因此若是能夠的話能夠請專業的設計師設計如下ui界面，在必定程度上能夠吸引到別人。

組件設計參考點

組件間props原子化

父子組件經過 props 屬性傳值時，儘量的規定數據類型而且使用原始類型的數據。儘可能只使用 JavaScript 原始類型（字符串、數字、布爾值）和函數。儘可能避免複雜的對象。

有如下幾點注意：

• 保證組件API清晰直觀
• 更好的理解每個prop的含義和做用
• 傳遞過於複雜的對象使得咱們不可以清楚的知道哪些屬性或方法被自定義組件使用，這使得代碼難以重構和維護。
• 保證組件可用（防護性編程）

示例：

巧妙利用slot擴展組件

用好slot能夠設計出不少優秀的組件。

合理使用mixin實現複用

Mixins封裝可重用的代碼，避免重複。若是多個組件共享相同功能，則可使用mixin。經過mixin，能夠專一於單個組件的任務和抽象的通用代碼。這有助於更好地維護應用程序。

及時模塊化

在決定抽離成組件以前，先問一下本身下面幾個問題：

• 是否有足夠的頁面結構/邏輯來保證它？
• 代碼重複（或可能重複）？
• 它會減小須要書寫的模板嗎？
• 性能會收到影響嗎？
• 你是否會在測試代碼的全部部分時遇到問題？
• 你是否有一個明確的理由？
• 這些好處是否超過了成本？

當你明確了上面幾個問題後，是否抽離組件相信你已經有了明確的答案。

如何設計組件？什麼時候抽離組件？如何抽離一個合適的組件？都是一些設計原則加上實際經驗相互做用下做出的判斷，理論指導，實踐判斷。

最後用一段雞湯文結尾：

在一天結束時，雖然你的直接責任多是「編寫代碼」，但你不該忽視你的最終目標，即創建一些東西。建立產品。爲了產生一些你能夠引覺得豪的東西並幫助別人，即便它在技術上並不完美，永遠記得找到一個平衡點。不幸的是，在一週內天天 8 小時盯着眼前的代碼會使得眼界和角度變得更爲「狹窄」，這個時候你須要的你是退後一步，確保你不要爲了一顆樹而失去整個森林。

感謝各位大佬的閱讀，讀完但願給點個贊再走哦，謝謝！🙏🙏🙏