前言
本篇主要來聊一聊元件的劃分的那些事。現在的前端開發，都是圍繞著元件展開的。我們逐漸意識到，理解元件化的含義，清楚元件劃分的規則至關重要。如何做到元件與元件之間的耦合度儘量的小，如何完成子元件和父元件的劃分，或許，是我們開發一個優秀的系統前，需要去認真思考的問題。如果你喜歡我的文章，歡迎評論，歡迎Star~github部落格
正文
本篇文章主要使用的資料驅動框架是vue，所以後續的元件劃分中，也主要是圍繞著vue元件展開的。或許，你會有疑問，React和Vue的元件性質不應該是一樣的嗎？是的，可以說兩者開發出來的元件都非常的相似，但是，還是有些細微的差別。
比方說，無狀態元件，大家都知道React中的無狀態元件，只有props這個外部給予的屬性。但是，在Vue中，你會發現似乎也有類似的元件，只提供props不就可以了麼。但是，它仍然是具備data的。所以，歸根結底，它只是不去使用狀態，而不是沒有狀態。
扯了這些東西，我們回到正題——元件的劃分。
這裡需要我們去思考一個問題——元件以何為分？
首先，我們以寫程式碼這件事來舉個例子。我們說好的程式碼裡面，函式必須只滿足一個功能。一旦，你的函式實現的效果太過於繁雜，那麼，這就意味著其他地方需要修改這個函式的部分功能時，總會來這裡做修改。“牽一髮而動全身”，場景越來越複雜，總有改不動的一天。
通過上面的例子，我們回過頭來聊元件，劃分的原則：
一個元件只做一件事，基於功能做好職責劃分。
我們需要在專案開發過程中，始終履行這個原則。在專案的初期、中期還是後期，往往會出問題的是初期。為啥？
因為開發初期，往往整體的系統功能單一，展現形式單一，這也誤導我們做出錯誤的思考。
例如：開發一個資訊查詢系統，前期最多的就是輸入框。可能一開始的輸入框形式比較單一，校驗形式單一，所以我們會將它統一封裝成一個text-input元件。愚蠢的是，我們會將校驗的邏輯寫進元件裡面，因為一開始的表單只有一種校驗邏輯，寫進元件中可以省下很多程式碼。
後來，突然增加了，一個驗證碼輸入框，需要有部分內容去顯示驗證碼。這時，我們會思考需不需要將之前的text-input進行拆解。但是，僅僅增加了一個驗證碼而已，我們完全可以使用v-if指令來控制這種情況。於是，草草了事，又在text-input上添了一個props去確認是否使用驗證碼元件。堂而皇之，之後的簡訊輸入框來了，我們又可以在原先的驗證碼的基礎上，增加簡訊按鈕。而且由於整個資訊查詢系統，對於輸入框的使用量劇增，開始出現不同的輸入框校驗方式。我們又得去輸入框中，進行修改。總有我們不敢改的一天，因為不同業務線，使用的輸入框元件，大多都是這個，不可能每次測試都會來測一下每條業務線的邏輯。
基於上訴情況，我們回過頭來思考，我們為在前期做好一件事情——單一原則的劃分。
撇開上述案例不談，我們先來看看正常情況下，我們如何來劃分元件的，如圖：
這裡依然扯到了無狀態元件(在vue中，我們可以考慮只使用props的元件)。
理解一下UI元件：即UI單元，如輸入框、tab框、表格、下拉框。我們可以來看一下2017年vue的UI庫發展情況：
可從圖中看出，element這個vue的UI庫，增長的速度非常之快，或許是國內的教程大多數使用的UI庫都是element的緣故吧，iView同樣在快速增長著。
移動端的UI庫，同樣也有Mint UI和vux。
回到之前的話題，我們可以將元件分割成一個一個的業務元件，然後業務元件可以通過UI元件和無狀態元件組成。這裡的無狀態元件可以給個定義：只接受props，根據不同的props展現出不同的樣式，並且會丟擲事件來通知外部元件需要的更改。
回顧之前的案例，我們也可以進行如下的操作：
由於前期開發中對text-input這個元件塞入了太多不應該的東西。所以，我們需要一個將之前的簡訊、驗證碼、普通的輸入框分成三個不同的業務元件。然後，可以使用既定的UI元件庫來進行拼接。
還剩下一個容器元件：
它就相當於一個盒子，包含著各種業務元件，同時它也承接了各種資料，然後對這些資料進行分發。在元件的劃分中容器元件扮演著至關重要的角色。
總結
我們將元件劃分成三種元件：容器元件、無狀態元件和UI元件。這樣，我們就可以按照既定的原則去處理元件。同時，在拿到產品的原型稿時，我們也需要去認真地思考這個問題。我們可以將頁面分成幾個模組。
需要明白的是：
- 越小的單元，state就越需要單一
- 不要在UI元件和無狀態元件中進行資料的請求，應該將之放入容器元件中
- 單向原則，子元件不應該影響父元件
最後，希望你能夠在實踐中去進行運用。
如果你對我寫的有疑問，可以評論，如我寫的有錯誤，歡迎指正。你喜歡我的部落格，請給我關注Star~呦github部落格
歡迎訂閱微信公眾號
