目前前端三大框架（vue.js, Angular.js, react.js）都在引領着前端的組件化開發方向，組件化的前端開發方式的確為業務實現帶來了前所未有的方便，其實組件化開發早已經具有（YUI），但如何封裝一個優秀的組件，可能並不是每位前端開發者都能夠做好的。
組件封裝有一定的不確定性，更多時候是在做幾個方面的權衡，並且在業務不斷變化中，可能還會面臨一些調整和重構。
組件化開發的意義有很多，一些新手會狹隘地認為只是為了復用（包括對於模塊化的理解），認為只有一個地方用就沒必要抽取封裝為組件，但實則不盡然：
- 組件化是對實現的分層，是更有效地代碼組合方式
- 組件化是對資源的重組和優化，從而使項目資源管理更合理
- 組件化有利於單元測試
- 組件化對重構較友好
組件與模塊
模塊(Module)通常強調的是職責（分離、內聚），組件是可復用模塊和相關依賴的封裝。
組件可以如下定義：
- 可復用的模塊，完成既定功能
- 有明確的接口規定
- 有上下文依賴、外部依賴資源的定義
- 可以獨立發布
組件設計的原則
新手常常會更多地從實現（如所用的框架vue的組件實現方式）直覺角度定義組件，並且隘於視角較局限，經驗較欠缺，對於職責划分不合理。
以下原則盡可能使用，用得越多就組件的復用性就越好。
- 適用單一職責原則
- 適用開放封閉原則
- 追求短小精悍
- 避免太多參數
- 縮小信賴范圍和向穩定方向信賴
- 適用SPOT法則 (Single Point Of Truth，就是盡量不要重復代碼，出自《The Art of Unix Programming》)
- 追求無副作用
- 追求引用透明
- 避免暴露組件內部實現
- 避免直接操作DOM
- 適用好萊塢法則 (好萊塢法則： Don’t call us, we’ll call you, 又稱IoC, Inversion of control, 控制反轉)
- 入口處檢查參數的有效性，出口處檢查返回的正確性
- 充分隔離變化的部分
- 組件和數據分享，信賴一致性的數據結構
自省的幾個問題
以上原則有點太教科書，不結合長期的實踐深刻理解，很難靈活運用，所以我設計了以下幾個自省問題，在思考一個組件時候，從這幾個問題入手，引導完善組件的設計。
這個組件可否（有必要）再分？
組件划分的依據通常是 業務邏輯、功能，要考慮各組件之間的關系是否明確（如組件樹方式管理組件間依賴關系，兄弟組件不可見），以及組件的可復用度。
虎課網https://www.wode007.com/sites/73267.html 設計塢https://www.wode007.com/sites/73738.html
划分粒度的大小需要根據實際情況權衡，太小會提升維護成本，太大又不夠靈活和高復用性。
每一個組件都應該有其獨特的划分目的的，有的是為了復用實現，有的是為了封裝復雜度清晰業務實現。
這個組件的依賴是否可再縮減？
縮減組件依賴可以提高組件的可復用度，常用的方法是IoC（依賴注入），對外弱類型依賴。
這個組件是否對其它組件造成侵入？
一個組件的封裝性不夠，或者自身越界操作，就可能對自身之外造成了侵入，這種情況應該盡量避免，確保組件的生命周期能夠對其影響進行有效的管理（如destroy后不留痕跡）。
較常見的一種情況是：組件運行時對window對象添加resize監聽事件以實現組件響應視窗尺寸變化事件，這種需求的更好替代方案是：組件提供刷新方法，由父組件實現調用（最終由根組件統一處理）。
次優的方案是，當組件destroy前清理恢復。
一個組件不應對其它兄弟組件造成直接影響。
這個組件可否復用於其它類似場景中？
需要考慮需要適用的不同場景，在組件接口設計時進行必要的兼容。
這個組件當別人用時，會怎么想？
接口設計符合規范和大眾習慣，盡量讓別人用起來簡單易上手，易上手是指更符合直覺。
假如業務需要不需要這個功能，是否方便清除？
各組件之前以組合的關系互相配合，也是對功能需求的模塊化抽象，當需求變化時可以將實現以模塊粒度進行調整。