如何開發公司組件庫（上）

前端業務是依託於組件實現的，隨着公司業務不斷增多，從那些功能類似的業務中能夠抽離出一些公共組件，造成公司的組件庫。組件庫的開發是一項複雜的工做，除需實現功能以外還要考慮構建、發佈、測試等一系列因素。但一個通過良好設計的成熟組件庫每每會在以後節省咱們大量的時間，讓咱們能更快速高效的實現業務需求。這篇文章是我在開發公司組件庫時的一些實踐分享，但願能對你們有所幫助。本文基於 Angular 框架，React 和 VUE 基本思路大同小異。

在開發組件以前，咱們須要作一些準備工做以確保所開發的組件能產生價值，包括：需求評審、調研同類型組件和發出組件issue。

需求評審

這部分的內容須要由提出組件抽離需求的成員來完成。

需求評審的意義在於肯定組件開發的目的，沒有通過需求評審就盲目開發的結果只能是浪費時間。需求評審須要肯定如下幾點內容：

1. 哪些項目在使用以及組件須要具有的功能 這是組件開發的意義所在，也是組件設計的依據，必需要給出具體的項目與功能描述。
2. 是否有必要抽離組件 組件開發通常耗時較長，要衡量利弊。通常優先抽取業務相關性較強的組件，好比標註器、關係圖譜等或者很是通用能迅速節省開發時間的組件，好比權限模塊、表格組件等等。
3. 由誰負責組件開發和 Code Review 組件的開發工做必須經過代碼審查，以保證組件庫的質量。所以在肯定組件開發人員的時候須要指定人員負責 Code Review, 建議組件庫有固定的成員負責 Code Review。

充分調研同類型組件

日光之下無新事，所需開發的組件每每並不新鮮早已被人實現，咱們只須要在此基礎上作一些調整便可。對已有的成熟組件的調研是十分必要的，它能夠幫助咱們避免由於自負犯下的錯誤。調研主要包括：

1. 組件的使用方式 對於 Angular 項目來說，組件有多種表現形式能夠提供功能。以ng-zorro-antd中的組件爲例，nz-button經過指令(DIRECTIVE)的形式實現按鈕相關功能，nz-message經過服務(SERVICE)來實現全局提示功能，nz-table以組件(COMPONENT)的形式實現功能，其內部又經過更細粒度的th和td組件與指令實現。可見不一樣用途的組件，其須要的使用方式也會有差別。調研的時候首先須要瞭解同類型的組件的使用方式。
2. 組件的功能與對應 API 設計 這裏須要注意的是 API 的命名，一般來說某些功能的命名是約定俗成的，好比數據類 API 通常爲*Data。參考規範的 API 命名，儘可能減小標新立異，使 API 易於理解。
3. 組件及功能實現方式 除了組件設計，還須要注意組件具體的實現方式。好比：組件類如何抽離依賴，組件的關鍵功能是如何實現的等等。

進行組件設計

組件的設計主要包含組件的使用方式和 API。在這一步須要輸出一份組件的使用範例以及根據功能設計的組件 API 列表。在進行組件設計的時候，可能會遇到如下的問題，這是個人一些見解。

公共組件裏要不要出現業務邏輯

組件是爲了提供 UI 視圖渲染。可是針對一樣的 UI 視圖渲染，不一樣的業務會引入不一樣的業務邏輯。好比用戶列表組件與文章列表組件的 UI 視圖渲染相同，但有着不一樣的業務邏輯（依賴的服務不一樣）。一般組件庫不包含具體的業務邏輯，只封裝組件自身 UI 邏輯與樣式邏輯。那若是是公司的業務組件庫，業務模式單一固定，爲了方便快捷，是否應該將業務與組件 UI 邏輯耦合在組件內部呢？個人見解是，組件自己只應該承擔視圖渲染的做用，即使業務固定，也應該剝離業務邏輯去設計組件。固定的業務邏輯能夠單獨封裝，沒有必要與組件邏輯耦合。組件應該保持純淨。好比須要根據用戶是否登陸的狀態下顯示相應文字，咱們應該提供一個能夠只包含 UI 渲染（自定義顯示文字）的組件而非一個包含業務邏輯（依賴於用戶登陸信息）的組件。以下所示：

// 同時包含業務邏輯（用戶信息服務）與 UI 渲染的組件
@Component({
  selector: 'download-span',
  template: ` <button [disabled]="disabled">{{disabled?'沒法下載':'下載'}}</button> `
})
class  DownloadSpanComponent {
  constructor(private userService: UserService) {}
  get disabled(): boolean {
    return !userService.hasLogin()
  }
}
複製代碼

// 不包含業務邏輯只包含 UI 渲染的組件
@Component({
  selector: 'download-span'
  template: ` <button [disabled]="disabled">{{disabled?'沒法下載':'下載'}}</button> `
})
class DownloadSpanComponent {
  @Input()
  disabled: boolean;
}
複製代碼

如何去判斷組件須要什麼樣的 API

創建在第一個問題的結論上，咱們才能判斷組件到底須要什麼樣的 API。首先組件的 API 必然是與組件的視圖渲染相關的，好比 [loading]指定表格是否顯示加載中視圖，[data]指定表格中的每個單元格中的具體內容。所以，API 的設計須要體現它所直接映射的功能。並且最好每個 API 映射的功能是彼此獨立的。其次，因爲組件不包含業務邏輯，所以組件的 API 也應與業務無關。因此 API 不能帶有具體的業務特徵，好比不能添加一個[showUserId]用來表示用作用戶列表時是否顯示用戶 ID列。最後，組件的設計毫不是爲了符合全部的業務需求，也沒有這個必要。所以，在設計 API 的時候應該考慮是否大多數場景都會須要用到這個 API。若是隻是爲了知足極少數的場景需求，那麼就沒有必要提供這個 API。由於很顯然組件的功能越簡單，組件的穩定性就會越好，拓展起來也越方便。特殊功能應該在具體的項目中進一步定製組件實現。

如何更新組件

組件的設計不是一勞永逸，須要不斷添加新的功能或更改已有的功能。在更新組件的時候，除了須要遵循以上兩點討論的結果外，還有一些須要考慮。首先保證新功能不會對已有的功能產生破壞，這是顯而易見的。其次，更新的功能不能夠由已有的功能單獨或組合實現。好比添加新功能[pagination]表示表格的分頁情況，這個功能能夠用[pageIndex]與[pageSize]組合表示。

根據組件設計提出 issue

組件的 issue 必需要包含如下內容：簡介、使用示例、功能列表和 API。除此之外，能夠針對性的添加一些其餘信息，好比動機、開發背景、遷移策略等等。在提出 issue 以後須要和同事積極討論，至少須要肯定功能列表和 API 知足你們的使用需求。issue 內容大體肯定以後，能夠點擊 gitlab 提供的 Create merge request 按鈕，提出一個 WIP 狀態的MR。而後在默認提供的分支上開發組件。由於組件開發每每包含的代碼量不少，若是開發結束以後再提出 MR，會致使負責 Code Review 很是困難。因此提早發起 MR，讓開發的過程始終可見，也方便你們在 MR 下隨時討論。

至此，組件開發的前期準備工做就完成了，接下來進入具體的組件開發環節。

相關連接： 如何開發公司組件庫(下)