組件開發方案

npm組件化開發的背景

1. 隨着技術的發展，開發的複雜度也愈來愈高，傳統開發模式老是存在着==開發效率低，維護成本高==等的弊端。（界面開發太多，風格樣式隨時均可能調整，若是要調整，可能全部的項目都須要調整，牽一髮而動全身）
2. 項目愈來愈多,針對項目進度以及時間要求==每一個人對項目樣式的支持度==不是很高，須要一個統一的模式進行管理，提高開發人員的工做效率以及減小bug的產生，讓開發人員可以更好地投入到業務開發中,發現組件化開發很是必要

組件化開發的優勢、缺點

1. 前端的組件化開發，能夠很大程度上==下降系統各個功能的耦合性==，數據相互獨立，而且提升了功能內部的聚合性。這對前端工程化及下降代碼的維護來講，是有很大的好處的，內部結構密封，不與全局或其餘組件產生影響，特別是針對邏輯複雜的功能可以進行拆分，更好排查問題。（就像電腦零件同樣，針對各個零件的問題進行調整）
2. 耦合性的下降，提升了系統的伸展性，下降了開發的複雜度，提高開發效率，下降開發成本。
3. 由於功能已經完善，項目中使用的組件可以讓人員更少的接觸組件內部通用的邏輯，更加投入到業務的開發，提高你們的開發效率，減小bug的生成，還能讓新人員更好、更快的接入公司的開發任務。
4. 目前不少公共組件和項目依賴不少相同的node_modules，若是對組件開發經驗不足，中間配合起來，版本不一致可能會致使node_modules出現未知的問題，各個版本針對不一樣環境也要作區分。

組件化開發遵循的特性

1.標準性

• 任何一個組件都應該遵照一套標準，可使得不一樣區域的開發人員據此標準開發出一套標準統一的組件。

2.專注性

• 設計組件要遵循一個原則：一個組件只專一作一件事，且把這件事作好。

3.拆分性（須要開發人員來把控）

• 一個功能若是能夠拆分紅多個功能點，那就能夠將每一個功能點封裝成一個組件，固然也不是組件的顆粒度越小越好，只要將一個組件內的功能和邏輯控制在一個可控的範圍內便可，大組件也就是頁面又叫作視圖，用起來更加方便（沒必要通訊），小組件更加靈活（小組件是塊磚哪裏須要往哪搬）。
• 頁面上有一個 Table 列表和一個分頁控件，就能夠將 Table 封裝爲一個組件，分頁控件 封裝成一個組件，最後再把 Table組件 和 分頁組件 封裝成一個組件。Table 組件還能夠再拆分紅多個 table-column 組件，及展現邏輯等。

4.可維護性

• 針對之後可能出現的功能要有預見，儘可能作到向下兼容以及新功能的添加可以很好的進行完成開發，儘可能使用一個組件完成功能，實在不行只能分一個新功能組件進行開發完成，若是有不可逆的問題須要調整，還須要嚴格按照npm版本號標準管理添加版本。

5.可配置性

• 一個組件，要明確它的輸入和輸出分別是什麼。
• 組件除了要展現默認的內容，還須要作一些動態的適配，好比：一個組件內有一段文本，一個圖片和一個按鈕。那麼字體的顏色、圖片的規則、按鈕的位置、按鈕點擊事件的處理邏輯等，都是能夠作成可配置的。
• 要作可配置性，最基本的方式是經過屬性向組件傳遞配置的值，而在組件初始化的聲明週期內，經過讀取屬性的值作出對應的顯示修改。還有一些方法，經過調用組件暴露出來的函數，向函數傳遞有效的值；修改全局 CSS樣式；向組件傳遞特定事件，並在組件內監聽該事件來執行函數等。
• 在作可配置性時，爲了讓組件更加健壯，保證組件接收到的是有效的屬性、函數接收到的是有效的參數，須要作一些校驗。

組件拆解

• 組件是相對獨立的可複用邏輯單元，多個組件相互做用造成了完整豐富的頁面，組件化的思想將前端工程提升到了一個新的高度，其內在表現是將頁面進行分割與抽象，達到高複用，易維護的目的，同時，對組件的可靠性，可預測性也提出了要求。總體而言，組件是提升開發效率的利器，下面將探討一下組件的構成；
  

• 組件能夠看作一個簡單的I/O模型，組件處於面對用戶第一線，具備交互特性，所以能接收與展現相關的數據；組件與組件相互協做，數據流通以對外接口爲通道。組件內部主要包含視圖、邏輯、樣式與狀態四個部分，功能的差別也致使不一樣組件的具體構成不盡相同，例如純展現組件只要視圖層與屬性，容器組件有邏輯、狀態、屬性，可是沒有視圖層，這裏不區分具體組件的職能，統一討論全部構成部分；

  1.接口

• 接口對外提供具體功能與擴展，對內傳遞外部屬性，對用戶不可見，但承擔着橋樑的做用，是各組件組合的粘合劑，所以接口的設計十分重要，可靠的輸入輸出是組件穩定的基石，功能豐富的接口也將提升組件的使用體驗；

  2.交互

• 組件負責與用戶的交互工做，提供可操做的功能，同時收集用戶輸入，而後對數據進行加工，從新給用戶呈現新的數據，所以對用戶體驗提出了高要求，快速響應，界面友好，操做便捷，是優秀組件須要包含的特性，這次組件的開發也將對以上幾點作針對性的設計，爲了知足快速響應，將組件的執行任務進行優先級的分解，保證組件響應的快速，同時總體對組件進行從新設計，全新的視覺元素與交互規範，勢必會提升用戶體驗與開發效率；

  3.視圖

• 視圖是用戶可視化的界面圖形，良好和統一的外觀能提升用戶的使用體驗，經過公司組件化視覺規範來提升組件的視圖層表現；

  4.邏輯

• 邏輯是組件功能與外觀的基礎，對數據狀態進行處理，呈現出組件的不一樣表現形式，可複用的邏輯將簡化組件的結構，同時更加利於維護，這次將公司內部系統常見邏輯進行封裝與抽取，實現邏輯層的獨立；

  5.樣式

• 樣式是屬於視圖層的範疇，單獨將樣式提取出來，是爲了更好的維護，對目前樣式進行系統化的整改，將減小平常開發對樣式的依賴；

  6.狀態/屬性

• 狀態/屬性是一系列I/O和邏輯處理的內在體現，狀態/屬性的結構設計也決定了組件功能與實現的難易程度，在後續組件設計過程也將具象化狀態與屬性值；

組件體系

• 根據組件層級與功能劃分，造成以下的組件體系：
  
• 底層支撐上層的組件，底層組件提供基本功能，上層組件在此基礎上擴展與組合，造成知足特定場景的高聚合組件，組件庫的使用人員主要集中在頁面和容器級別的組件層級上，從而減小對底層基礎組件的依賴；

版本管理

分爲三個版本

• 主版本號（A）：當你作了不兼容的 API 修改，0表示處於開發階段；
• 次版本號（B）：當你作了向下兼容的功能性新增;
• 修訂號（C）：當你作了向下兼容的問題修正。

~容許小版本迭代

• 若是有缺省值，缺省部分任意迭代；
• 若是沒有缺省值，只容許補丁即修訂號（Patch）的迭代

eg.:

• ~1.2.3：>=1.2.3 <1.3.0
• ~1.2：>=1.2.0 < 1.3.0（至關於1.2.x）
• ~1：>=1.0.0 <2.0.0（至關於1.x）
• ~0.2.3：>=0.2.3 <0.3.0
• ~0.2：>=0.2.0 <0.3.0（至關於0.2.x）
• ~0：>=0.0.0 <1.0.0（至關於0.x）

^容許大版本迭代

• 容許從左到右的第一段不爲0那一版本位+1迭代（左閉右開）；
  若是有缺省值，且缺省值以前沒有不爲0的版本位，則容許缺省值的前一位版本+1迭代
  eg.:
• ^1.2.3：>=1.2.3 <2.0.0
• ^0.2.3：>=0.2.3 <0.3.0
• ^0.0.3：>=0.0.3 <0.0.4
• ^1.2.x：>=1.2.0 <2.0.0
• ^0.0.x：>=0.0.0 <0.1.0
• ^0.0：>=0.0.0 <0.1.0
• ^1.x：>=1.0.0 <2.0.0
• ^0.x：>=0.0.0 <1.0.0

鎖定（控制）版本

package-lock.json或是yarn.lock。

在npm的版本>=5.1的時候，package-lock.json文件是自動打開的，意味着會自動生成，
package-lock.json（官方文檔）能夠理解爲/node_modules文件夾內容的json映射，並可以感知npm的安裝/升級/卸載的操做。能夠保證在不一樣的環境下安裝的包版本保持一致。聽上去很不錯哈，實際使用中，大部分它的表現確實不錯，但是如上述問題：我手動修改了package.json文件內依賴的版本，package-lock.json就沒那麼聰明（至少目前是，將來會不會變聰明就不可知了），且不會變化。
若是你真的想保證你的包版本在各個環境都是同樣的話，請修改下package.json中的依賴，去掉默認前面的^，固然這樣的話，你就無法自動享受依賴包小版本的修復了，問題來了，在什麼狀況下選擇哪種呢？

在依賴包嚴格按照版本規範來開發的，你可使用^來享受包的最新功能和修復。這也是推薦的。
在你不可知或已知依賴包不是那麼規範的狀況下，或許它在一個小版本（patch）作出不兼容更改（不兼容更改在beta等先行版本中必定[墨菲定律]會發生），那麼這個時候，你應該把這個依賴包的版本在package.json上鎖住版本，而不該該把它交給package-lock.json來處理
記住一點，絕對不要在生成環境下使用beta等先行版本依賴包，由於若是那是你的私有項目，它會在將來的某一刻坑害了你，若是這是你的共有項目，那麼，它必定會在將來的某一刻對你的全部用戶作出致命的坑害行爲
---

初期開發

實現如圖：

1.劃分組件

根據組件具體職能不一樣，能夠劃分爲以下結構：

• 框架型組件：針對公司項目中組件特定的邏輯功能須要公用的組件能夠提取爲業務組件，只保證目前各項目框架的公共業務，不摻雜其餘的項目的邏輯（fulu商戶側，fl-pro運營側）
• 功能型組件（Table、Form，目前頁面最能體現的組件）：都是提供1個基類，其他進行派生擴展的機制針對實際場景進行開發
• 常規組件（Checkbox、Input、Radio等）：根據定製化樣式進行開發

2.提取項目公共頁模版

由公共函數類、公共模塊類、當前頁面組成，全部頁面引用公共組件，公共組件繼承公共類，開發者不須要寫過多公用的代碼，開發類由被基類、繼承類的公共組件，使用公共組件的的頁面三塊組成。

• 1.CommonPage：基類，將公共函數（初始化加載、顯示隱藏彈框、查詢等）與state（頁面須要使用的變量）提取公用。
• 2.CommonPageDom：公共組件，繼承公共類，能夠創建多種組件，自適應各類頁面。

• 3.TestPage:引用公共組件，能夠經過傳入配置文件進行動態加載

  頁面劃分

• 1.普通頁面不帶增、刪、改
• 2.普通頁面帶增、刪、改、查、彈框
• 3.帶tab切換的頁面

• 4.其他待擴展的頁面
  

3.提取公共函數

不少函數在咱們項目中都會頻繁使用，因此須要提取公共出來，方便使用

• 1.驗證函數
• 2.數字文字的處理，數組的合併，類型的檢驗等
• 3.其他可提取的公共函數

4.初期能達到的狀況

• 1.UI方面：公共組件樣式、交互徹底和公司須要的風格一致
• 2.功能開發：開發者只須要在當前引用組件，傳遞相應參數就能生成想要的頁面

中期開發

一鍵配置開發

• 1.建立頁面1鍵生成對應頁面的組織結構，包括頁面文件夾還有models，services，routers等
• 2.經過傳遞的配置參數給組件，直接生成頁面

後期開發

經過拖拉拽直接進行開發

• 1.經過開發的工具直接托拉拽進行生成頁面

持續優化

腳手架持續優化

• 1.依賴包的更新，打包的持續優化
• 2.項目使用技術的持續更新

各個流程的優化

• 1.單元測試，自動化測試
• 2.前端自動化部署，動態修改線上代碼
• 3.項目性能優化（jsperf、yslow、pagespeed）
• 4.組件功能優化
• 5.公共函數庫持續迭代