我對組件化的一點細瑣的想法

 

　　組件化是如今提的頻率很是高的一個詞。我以爲組件化就是從全部頁面的內容去提取最大公約數，例如後臺管控類項目頁面基本均可以提取爲header，sidebar，container，footer4大塊，而後在每一塊裏再提取最大公約數，例如container頁面裏的表格控件，表單控件等。毫無疑問，組件化是爲了一次實現，永久複用的效果，這樣不只是方便了本身開發，也讓項目其餘的和將來的小夥伴更快的上手。提到更快上手，那麼什麼樣的組件才能更快的上手，一是組件內簡單的註釋或者文檔，如今的編輯器基本均可以裝doc-api的插件，二是組件的入參的限制，入參越少，參數限制越多，上手越簡單。好比某個組件僅僅實現了tab頁籤的功能，那麼只容許傳一個表明要顯示文案的label的數組就能夠了。某個需求產品要多顯示一些內容，好比不知足於只顯示一個label，可能要再多顯示一個title或者其它什麼內容，那麼可能也僅僅須要加幾個入參，並不須要對組件大變更。可是某天產品又一個需求，例如會員，他要展現會員收入，新增會員，人均，新增訂單，支付訂單的信息，而且每一個要展現的內容都不太同樣，換句話說每一個tab的樣式都不同。那麼你僅僅一個tab組件來實現的話確定很繁瑣。那麼在作以前有沒有考慮到組件的可擴展性，有沒有去思考產品哪天又會拍腦殼提出某些大致一致，細節有變化的要求。那麼這個組件換成2部分，一個父組件表明tab的容器，另外一個子組件表明一個tab，大體結構就是<tab-container><tab>a</tab><tab>b</tab></tab-container>，這樣就能夠對每一個tab能夠單獨實現本身的內容。可是這樣一來，組件的入參勢必會變多，可能每一個參數的限制也會變少，瞭解什麼場景上傳什麼參數就會提升組件的上手成本，這多是一個關於組件可擴展性的博弈，到底在寫這個組件前要不要考慮或者預留這個功能的擴展。又好比某個tab要禁用，是僅僅組件加載時禁用一次，仍是動態去計算或者監聽這個屬性，只要入參改變就會改變禁用的tab。出現動態改變禁用tab的需求可能性大不大，若是很小，那麼就不必去預先實現。一個組件有能夠擴展不完的功能，若是永遠在這個組件中實現，那麼最終組件必然會變得臃腫不堪維護。好比某個需求產品要求tab加入滑動的功能，這樣就能夠經過滑動顯示更多的tab。能夠經過加一個type入參，而後賦予一個default表明老的tab，而後另一個值是scroll來實現這個需求，可是之後可能的其餘type勢必讓這個組件難以維護，因此提早適當的分類，好比這個滑動的tab組件大體結構爲<tab-slider-container><tab-slider></tab-slider></tab-slider-contaner>這樣按照使用的場景提取出不一樣組件，那麼就有了<tab>和<tab-slider>2個適用於不一樣場景的頁籤組件。

　　總結一下組件化要考慮的問題：一、組件的結構（同一個功能要不要根據場景拆分新的組件，拆分的最小粒度多少合適），二、組件的擴展性（要不要考慮某個功能的擴展，擴展到什麼程度爲。