關於前端組件化、狀態管理規範化的思考

• 蘇格團隊
• 做者：Tomey

1、開篇

提及前端組件化是這幾年老生常談的話題，筆者就不在這裏對前端組件化思想的發展史、優劣作詳細的介紹。今天主要與你們分享一下，筆者在開發中從初期的小項目，到後期的項目功能迭代，功能模塊愈來愈多，項目愈來愈大，組件化規範制定不夠完善，多人團隊協做開發致使的一些問題，與筆主本身處理的方案的思考。

2、發現、提出問題

一、三張圖說明一個業務模塊功能迭代圖。

第1版

組件單向數據流，父組件狀態單向傳輸子組件

第2版

隨着功能迭代，非父子組件會共享一些狀態。 此處因爲非父子組件間狀態共享不復雜，優先使用狀態提高（狀態提高，咱們須要把子組件間共享的狀態，提高到容器組件進行管理，並有容器組件下發到子組件）解決此類問題。

第3版

隨着更多的功能迭代，模塊分層愈來愈多，跨多層組件狀態共享愈來愈複雜

狀態管理redux、vuex就是爲了解決此類問題而出現。

經過以上的項目模塊迭代週期的發現，不可避免的出現多組件狀態共享。 一般處理共享狀態有三種方式：

1. 狀態提高，咱們須要把子組件間共享的狀態，提高到容器組件進行管理，並有容器組件下發到子組件。
2. 狀態管理redux、vuex。
3. 事件機制，子組件改變共享的狀態，經過事件管理模塊emit分發出去，須要同步更改狀態的子組件經過on接收更改事件。

引入狀態管理就真的能解決全部的問題嗎？

1. 組件哪些狀態須要提取到狀態管理？
2. 如何避免濫用全局狀態致使項目混亂？
3. 容器組件、展現組件如何劃分？
4. 多人協做開發組件規範、風格不統一，組件間共享狀態雙向修改規則不統一，新人加入學習成本高。

3、解決問題

筆者認爲解決問題的方法，就是制定相應規範，保證團隊代碼風格統一。

1. 容器組件與展現組件開發規範。
2. 哪些組件狀態應該提取到狀態管理，狀態管理開發規範。

請看下圖：

容器型組件：主要是獲取、更新、提交、刪除內含展現組件狀態數據，不包含任何Virtual DOM 的修改或組合，也不會包含組件的樣式。

展現型組件：展現型組件主要表現爲組件是怎樣渲染的，包含了Virtual DOM的修改或組合，也包含組件的樣式，同進不依賴任何形式的store。通常能夠寫成無狀態函數，但實際上因爲不少展現型組件裏依然存在生命週期方法，因此不必定都是無狀態的組件。

說明：

1. 項目初期版本，只有一個容器組件A，容器A包含三個展現組件A一、A二、A3，全部共享狀態都有容器A管理。
2. 隨着項目迭代，容器組件A會分裂出兩個新模塊容器組件B、C。
3. 容器組件B、C分別包含展現組件B一、B2，C一、C2，且B、C之間存在共享狀態。
4. 容器組件間共享狀態數據，統一由狀態管理store管理。

規範：

1. 展現組件必須在容器組件中使用，除了獨有的狀態，其餘共享狀態統一由容器組件管理。
2. 展現組件涉及修改共享狀態的操做，例如點擊事件，須要把點擊事件經過無狀態回調函數拋到容器組件，由容器組件統一作狀態獲取、更新、提交、刪除等等操做。
3. 父子容器組件共享狀態，子容器只能讀取父容器組件共享狀態，不能進行修改（例如子容器只能經過無狀態回調函數拋到父容器），保證單向數據流。
4. 子容器修改父容器或者修改非父子容器共享狀態惟一途徑，經過狀態管理store統一修改。
5. 因爲容器間共享狀態不能雙向修改，因此狀態管理store會保存大量的共享狀態數據，須要經過系統模塊、容器組件名分層註冊須要狀態共享的容器組件state。

實例

寫了一個vue+vuex的基礎實例，可供參考。下載 github

4、結束

文章到此結束，寫這篇文章目標主要是記錄本身對於組件規範的思考,歡迎各位大佬提出本身的看法，文章有誤的地方請你們及時指正~