如何开发公司组件库（上）

前端业务是依托于组件实现的，随着公司业务不断增多，从那些功能类似的业务中能够抽离出一些公共组件，造成公司的组件库。组件库的开发是一项复杂的工做，除需实现功能以外还要考虑构建、发布、测试等一系列因素。但一个通过良好设计的成熟组件库每每会在以后节省咱们大量的时间，让咱们能更快速高效的实现业务需求。这篇文章是我在开发公司组件库时的一些实践分享，但愿能对你们有所帮助。本文基于 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 下随时讨论。

至此，组件开发的前期准备工做就完成了，接下来进入具体的组件开发环节。

相关连接： 如何开发公司组件库(下)