- 蘇格團隊
- 作者：Tomey
一、開篇
說起前端元件化是這幾年老生常談的話題，筆者就不在這裡對前端元件化思想的發展史、優劣做詳細的介紹。今天主要與大家分享一下，筆者在開發中從初期的小專案，到後期的專案功能迭代，功能模組越來越多，專案越來越大，元件化規範制定不夠完善，多人團隊協作開發導致的一些問題，與筆主自己處理的方案的思考。
二、發現、提出問題
1、三張圖說明一個業務模組功能迭代圖。
第1版
元件單向資料流，父元件狀態單向傳輸子元件
第2版
隨著功能迭代，非父子元件會共享一些狀態。 此處由於非父子元件間狀態共享不復雜，優先使用狀態提升（狀態提升，我們需要把子元件間共享的狀態，提升到容器元件進行管理，並有容器元件下發到子元件）解決此類問題。
第3版
隨著更多的功能迭代，模組分層越來越多，跨多層元件狀態共享越來越複雜
狀態管理redux、vuex就是為了解決此類問題而出現。
通過以上的專案模組迭代週期的發現，不可避免的出現多元件狀態共享。 通常處理共享狀態有三種方式：
- 狀態提升，我們需要把子元件間共享的狀態，提升到容器元件進行管理，並有容器元件下發到子元件。
- 狀態管理redux、vuex。
- 事件機制，子元件改變共享的狀態，通過事件管理模組emit分發出去，需要同步更改狀態的子元件通過on接收更改事件。
引入狀態管理就真的能解決所有的問題嗎？
- 元件哪些狀態需要提取到狀態管理？
- 如何避免濫用全域性狀態導致專案混亂？
- 容器元件、展示元件如何劃分？
- 多人協作開發元件規範、風格不統一，元件間共享狀態雙向修改規則不統一，新人加入學習成本高。
三、解決問題
筆者認為解決問題的方法，就是制定相應規範，保證團隊程式碼風格統一。
- 容器元件與展示元件開發規範。
- 哪些元件狀態應該提取到狀態管理，狀態管理開發規範。
請看下圖：
容器型元件：主要是獲取、更新、提交、刪除內含展示元件狀態資料，不包含任何Virtual DOM 的修改或組合，也不會包含元件的樣式。
展示型元件：展示型元件主要表現為元件是怎樣渲染的，包含了Virtual DOM的修改或組合，也包含元件的樣式，同進不依賴任何形式的store。一般可以寫成無狀態函式，但實際上由於很多展示型元件裡依然存在生命週期方法，所以不一定都是無狀態的元件。
說明：
- 專案初期版本，只有一個容器元件A，容器A包含三個展示元件A1、A2、A3，所有共享狀態都有容器A管理。
- 隨著專案迭代，容器元件A會分裂出兩個新模組容器元件B、C。
- 容器元件B、C分別包含展示元件B1、B2，C1、C2，且B、C之間存在共享狀態。
- 容器元件間共享狀態資料，統一由狀態管理store管理。
規範：
- 展示元件必須在容器元件中使用，除了獨有的狀態，其他共享狀態統一由容器元件管理。
- 展示元件涉及修改共享狀態的操作，例如點選事件，需要把點選事件通過無狀態回撥函式拋到容器元件，由容器元件統一做狀態獲取、更新、提交、刪除等等操作。
- 父子容器元件共享狀態，子容器只能讀取父容器元件共享狀態，不能進行修改（例如子容器只能通過無狀態回撥函式拋到父容器），保證單向資料流。
- 子容器修改父容器或者修改非父子容器共享狀態唯一途徑，通過狀態管理store統一修改。
- 由於容器間共享狀態不能雙向修改，所以狀態管理store會儲存大量的共享狀態資料，需要通過系統模組、容器元件名分層註冊需要狀態共享的容器元件state。
例項
寫了一個vue+vuex的基礎例項，可供參考。下載 github
四、結束
文章到此結束，寫這篇文章目標主要是記錄自己對於元件規範的思考,歡迎各位大佬提出自己的見解，文章有誤的地方請大家及時指正~