前端mv架構下（目前寫的是vue），對元件抽象的思考

前沿：

　　抽象是門大學問。前端mv架構中，以元件化的概念為主。經常會考慮抽象到元件級别，進行複用。合理的抽象，能提高效率，減少業務邏輯視圖的耦合程度。不合理的抽象，則會增加代碼的複雜程度。

遇到的問題

　合理的抽象是很難的，需要不斷的思考，才能做到最合适的抽象。在b+項目中，遇到了一些問題。

　　1、有些元件，ui和邏輯都可複用。ui抽象了，對應邏輯沒抽。這樣在複用這個元件的時候，邏輯部分的代碼沒有複用到，得另外複制粘貼一份。　　　

　　2、有些元件，ui可複用，邏輯不可複用。抽象成一個元件，ui是實作了複用，但是業務邏輯得配置參數使用，導緻switch case 無限增多。

我所了解的抽象思維：

　　1、基礎抽象，适用于所有的項目。

　　　　首先，從功能的緯度去抽象。抽象一些具有某一特定功能的ui元件。比如說，button，日期選擇器，清單等，這些都是具有特定功能的子產品，單獨可抽象為一個元件子產品。功能型抽象的理念是，不關心具體項目的業務邏輯，隻關心具體功能的邏輯。這種抽象的最終結果就是抽象出一整套具備各種功能子產品的ui庫。例如elemntui，antd，vant等。

　　2、業務子產品的抽象，根據業務邏輯判斷。

　　　　在具體項目中，除了從功能子產品先抽象最基本的一層。還可以根據業務的實際需求，基于基礎抽象的元件庫，進行二次封裝，以達到此項目中具有通用性的抽象子產品。判斷可抽象的依據是，ui具有一緻性且業務邏輯也一緻性（主要判斷條件）。一個的反面例子，假如有三個子產品，每個子產品的清單都是長得差不多，但是三個子產品的業務邏輯是不一緻的，比如說接口調的不一樣。這種情況下，雖然ui很像，但是邏輯不一樣，就不合适抽象元件進行複用。一個正面例子，假如有一個多個下注按鈕，ui稍有不同，但是實作的邏輯都是下注。那麼就适合做抽象複用。

總結：

　　通用的功能性子產品有限，是以是可配置并可抽象的。業務型邏輯的情況可能無限，不合适去做配置實作抽象。是以，在業務中能抽象的必要條件是，業務邏輯必須具有一緻性。如果ui也一緻，則可抽象成元件。如果ui不一緻，則單獨抽象邏輯部分（這vue中可用minxins引入公共邏輯）。