构建属于你自己的基于react的前端UI组件库

1. 为什么需要组件库

1.1 提高开发效率，便于维护自己的代码，保证规范性和唯一性

这是组件库最基础的功能。

举个例子，在我们的B端数据接口服务平台中，查询接口列表，接口基础信息，接口复制这几块功能本质上都是采集用户提交的信息，不同的只是item布局，输入框类型等地方，如果你不做组件，那代码可能需要写三遍（影响开发效率，难以维护UI交互的统一性），所以我们需要设计通用组件



那么这个组件放在哪里呢？如果放在单独的项目中，别的项目如果需要同样的功能只能拷贝，同样，这也会存在影响开发效率，难以维护UI交互的统一性的问题，这个时候就需要统一的UI组件库去解决这个问题

1.2 突出自己的产品特色

如果你一直用开源的组件库，你会发现你开发的所有产品跟市面上已有的产品总有种相似感，独一无二的特性不明显，很难引起他人的兴趣。

1.3 了解规范，提高技术能力

真正要维护一个组件库，你需要参考开源社区组件库的规范和标准，需要对组件库进行设计，需要你有一定的技术功底，在开发过程中团队的技术能力也会得到提升。

2. 如何搭建组件库

2.1 组件开发调试

storybook是一个辅助UI控件开发的工具。通过story创建独立的控件，让每个控件开发都有一个独立的开发调试环境。 Storybook的运行不依赖于项目，开发人员不用担心由于开发环境、依赖问题导致不能开发控件。
由于它支持多种主流框架，可以非常方便的用来进行react组件库的开发。

storybook

2.1.1 功能开发测试

在源代码进行组件编写和设计，在stories编写测试文件，利用storybook实现热更新进行实时调试。

2.1.2 接入项目调试

在组件库内部对组件开发完成之后，需要在业务项目中接入UI组件库，在项目接入过程中可能会出现安装，依赖不支持，和业务组件库存在冲突等各种问题，所以我们面对不成熟的组件库在初始接入存在各种问题的时候，不可能采用常规的发布到node官网，然后在安装使用的方式，我们需要本地的接入调试。

这个时候可以采用npm link
原理就是采用软链接，把项目的引用放到全局上，

// 组件库采用
npm link
npm unlink
// 业务项目(h5-koala ui组件库的名称)
npm uninstall h5-koala
npm link h5-koala
npm unlink h5-koala

npm link原理

2.2 打包(对外开放)

对于打包后的文件，统一放在 lib 目录下，同时记得要在 .gitignore 中加上 lib 目录，

2.2.1 提供 es6规范的包

采用tsc，对外提供编译之后的js文件，我们采用了es6标准

2.2.2 按需加载

在 UI 组件库的使用场景中，往往有时候只需引入个别组件而非全量组件，那么就要求组件库需要有能够按需加载的能力。

采用单独编译组件即可，或者使用treeShark也可以

2.3 版本管理及发布

组件库的某个版本完成开发测试工作后，需要将包发布到 npm 上。同时在后期迭代维护过程中我们需要了解版本管理以及发布。
此时，对于配置package.json需要知道下面一些字段：

2.3.1 版本管理

version

node中的版本号，符合语义化版本规则，即 major.minor.patch

• major：主版本号，不兼容的修改
• minor：次版本号，向下兼容的新功能
• patch：修订号，向下兼容的问题修复

main

main 是包的入口文件，可以是 commonJS 格式或者 umd 格式

module

定义用 ES6 模块打包的入口

unpkg

定义浏览器环境使用的入口，配合umd包使用

2.3.2 自动化发布流程

如果每次发布都需要运行测试、打包构建、更新版本号、npm 包发布等流程，未免有些繁琐，需要借助一些自动化的手段将上述流程串连起来，实现自动化发布。
只需要执行两条命令即可完成发布

// 本地编译，版本管理，提交，编写变更记录，
npm run tag 
// 发布
npm publish

 "build": "npm run tsb && gulp",
 "tsb": "rm -rf lib/ && tsc",
 "changelog": "conventional-changelog -p angular -i CHANGELOG.md -s",
 // commit message 自动集成到CHANGELOG.md中
 "version": "npm run changelog && git add CHANGELOG.md",
 "pretag": "npm run build && git add . && git commit -m 'build(src): publish' || true",
 // 修改版本号，并提交（%s 表示版本号）
"tag": "npm version ${1:-patch} -m 'Publish %s'",
 "posttag": "git push && git push --tags"

2.3 文档管理

2.3.1 gitbook

GitBook 是一个现代的文档平台，团队或个人可以在其上编写产品、API接口文档以及团队内部知识库. 作为一个组件库的文档平台，搭配github-pages,非常简单好用。
只需要开一个gh-pages分支，把gitbook build之后的文件发布到gh-pages分支上就能通过github-page访问了。
gitbook使用demo

2.3.2 vuepress

vue 驱动的静态网站生成器,
vuepress 使用demo

2.3.3 vuepress or gitbook?

• 性能 vuepress > gitbook, 单页预编译明显效率最高
• UI，感觉vuepress>gitbook
• 阅读体验 gitbook > vuepress, gitbook可以调节背景字体大小等，阅读体验上更佳
• 导出功能，好像只有gitbook有。
• 搜索 gitbook > vuepress，gitbook插件最多最佳，vuepress默认只能搜索标题，全文搜索需要引用第三方的工具。

由于gitbook团队不再维护cli，所以不推荐使用gitbook？？？？

2.3.4 vuepress + gitlab

可以配合gitlab的 CI/CD 工具，例如在 CI/CD 脚本中监听 master 分支的 tags 推送，一旦有新 tag 推送至远程，就执行上述的发布流程，包括文档站点的部署也可以在这里实现。 CI/CD 工具，例如在 CI/CD 脚本中监听 master 分支的 tags 推送，一旦有新 tag 推送至远程，就执行上述的发布流程，包括文档站点的部署也可以在这里实现。

这个在使用的时候被坑了一下，共享的runner用不了，需要自己在电脑上配置runner
具体的配置参考：https://www.jianshu.com/p/c7995ad64f48
其中被坑的点：在配置的时候会让你设置tags，然后你的项目里面的.gitlab-ci.yml配置文件下的tags一定要和配置runner时候设置的tags保持一致，被坑了一个多小时。。。
公司gitlab不支持pages，无语中。。。

3 源码

h5组件库源码

4 参考文档

前端 UI 组件库搭建指南