Taro组件库｜从0到1搭建

本片主要介绍了如何搭建一个Taro的组件库，该组件是基于 Taro 框架开发的多端 React UI 组件库、目前支持 H5 和小程序。

背景

现状

随着我们当前业务的扩展和丰富，移动端的项目比较侧重业务开发，因此项目人员规模的扩大与迭代时长的增加，项目复杂度持续增长。而为了满足业务的快速上线，很难去落实统一的设计规范，在开发过程中由于UI缺乏标准导致的问题不断凸显，具体体现在以下4个层面：产品层面、设计层面、开发层面和测试层面。

对于我们开发来说组件代码实现碎片化，存在多次开发的情况，导致维护拓展成本较高，变更主题，国际化等需求难以实现。组件缺乏统一管理手段，缺乏与UI之间的桥梁，无法实现积累沉淀，无法适应新业务的快速开发。所以去创建组件库是我们比不可少的项目之一

由于我们移动端开发目前支持小程序和H5，所以我们选用了Taro做为我们的框架。组件库的建设也是根据基于Taro建设的。

目标

基于上述开发工作中的切实痛点，以及未来可预见的移动端能力需求，因此建立统一的多端UI组件库是我们必须要沉淀的。目前是以实现各个项目的基本组件和部分业务组件为目标而开发的，支持各个项目中主题修改、部分样式修改、动态主题修改和部分组件自定义流程。

因此我们为了改善用户端体验一致性，提升多技术方案间组件的通用性和复用率，降低整体视觉改版的研发成本。通过抽离成熟的业务场景，建立可提供高质量、可扩展、可统一配置的基于Taro的组件代码库。使之具备支持多业务高层次的代码复用能力，进而提高UI业务中台能力，使项目保持高度一致性

竞品

目前Taro样式库业内也有不少团队在做，我们也是分析了多个组件库内容，分析了它们组件库的思想和架构。下面对他们进行分析：

组件库	github	特点
NutUi	Star: 4k; User: 400+	一款具有京东风格的组件库；目前支持react和vue开发；50+ 组件
taro-ui	Star: 3.8k; User: 3.6k	由京东·凹凸实验室倾力打造的多端开发解决方案；多端（微信小程序、H5、RN等）
taroify	Star: 239	基于Vant的Taro React版本，与Vant相同的视觉规范，一致的API；60+ 组件；
AntmJS/vantui	Star: 100+	基于有赞VantWeapp开发的同时支持 Taro 和 React 的 UI 库；
taro-color-ui	Star: 30+	基于 ColorUI 封装的 TaroUI 组件库

实现

铺路

在做组件库前，需要对建设组件库的内容做一些前提工作，我就简单的总结了一下：

做组件库前我们还是要设计来支援我们，我们自己想的东西并没有那么合理，通过ui帮助我们有自己的设计风格或是设计系统才是最好的选择，UI通过自己的设计规范、设计语言、设计原则生成自己的设计资源以此帮助我们去实现我们的组件。
成立组件库小组，邀请了同步门做业务的人员一块进行开发。一块去学习主流框架的各种配置，如Vant、Antd Mobile、NutUi和taro-ui等框架，学习了它们的架构设计，组件的属性和样式的规范性。打包和发布方式。

介绍

目前我们的组件也是处于开发阶段，但是已经可以在项目中使用了。该组件是一套基于 Taro 框架开发的多端 React UI 组件库，京东商羚团队出品，开发和服务于移动Web界面的企业级产品。我们给它起了个名字——Tard(Taro React Design)。详情可以查看我们的文档地址

整体思路

该组件库是底层也是用react、taro、less、typescript等技术进行打造开发了，taro就不用多说了，react和less是部门选择使用的。

组件库的发布则是通过lerna进行发布，目前现在只有组件库一个包进行发布，后期将组件库进行拆分。

该组件目前分为3个部分，组件库本身、文档项目、demo项目。

组件库打包是用了rollup框架，因为Taro编译小程序的时候都是用esmodule模式进行处理的，而webpack目前打包不了这种模式，因此我们选用rollup。
文档则是用umi，之所以用它，是因为它有约定式路由，我们可以利用组件库rollup写个插件（组件库中md文件修改，文档项目就可以直接监听进行修改，免除路由配置）。
demo项目则是用的taro脚手架安装的，demo和文档之间的交互本来想用微前端进行处理，但是taro目前不支持。所以就选用了iframe进行处理。使用组件内容则是用yarn link来动态实现的。

组件系统设计思路

对于多个同一部门的系统来说，我们最终的目的就是实现错综复杂的业务功能，但是不同模块或者子系统之间很多业务往往是相通的或者相似的，所以基于这种场景我们的业务组件就很有必要出场了。我们可以把功能或者需求类似的有机体封装成一个业务组件，并对外暴露接口来实现灵活的可定制性，这样的话我们就可以再不同页面不同子系统中复用同样的逻辑和功能了。

对于上面同理，在不同页面中通常有可能出现视觉或者交互完全相同或者类似的区块，为了提高可复用性和提高开发效率，我们通常会基于基础组件和业务组件再进行一次封装，让其成为一个独立的区块以便开发者直接复用。减少代码量。

通过上面的一层层封装，我们就逐渐搭建了一套完整的组件化系统，基于这种模式的开发往往也是一个好的前端架构的开始。但要注意一点就是高层次的组件一定会依赖低层次的组件。

组件库的划分

组件库的划分我们也是参照了业内比较成熟的组件，但是也是要根据自己部门的业务实际情况来再次区分。我们现在讲30多个组件分了6类：基础组件、表单组件、反馈组件、展示组件、导航组件和特色组件。基本上都是业内普遍用的，在这说一下特色组件，其实就是在基础组件之上拓展的业务组件，目前将2个组件抽离开源出来，剩下的还待开发和测试。

主题定制

目前我们组件提供了一套默认主题，CSS 命名采用 BEM 的风格，方便使用者覆盖样式。如果你想完全替换主题色或者其他样式，可以根据我们提供的配置文件进行修改。我们提供两套方案供选择，分别是样式变量和主题动态更改。可参考文档。

样式变量目前分为3类：基本变量、公共变量和组件变量。基本变量我们将一些定义和基本单位等属性提出来以便公共变量和组件变量去使用。公共变量则是将组件中常用的一些字体、间距、大小等属性抽成公共属性去使用。组件变量则是将每个组件的特殊属性进行抽离成变量的形式方便开发者去修改

组件库编译

上面说了组件库打包是用了rollup框架，但是也提供了ts打包规则，方便其它模块直接使用。rollup框架支持EsModule和commonJs，大家感兴趣的可以看下Taro源码，commonJs是H5使用规则、EsModule则是提供给小程序编译。打包文件体积也会更小。

在这简单的说一下，EsModule模式不太兼容React Hooks的写法，因为React Hooks并没有按照EsModule方式输出，所以我们output中做了一下配置，将react和react dom进行输出。

{
  file: resolveFile(Package.module),
  format: 'es',
  sourcemap: true,
  globals: {
    react: 'React',
    'react-dom': 'ReactDOM',
  }
}

文档

文档的内容也是组件库的关键，开发人员如果看不懂文档说明组件库的内容没有做好。文档我在两个方面给大家介绍一下：实现和规范。

1. 实现

文档的开发其实分为三个部分：框架主体、文档处理和自动编译

框架主体用Umi进行开发的，用它方便、快捷、可配置
文档处理则是用react-markdown，支持语法高亮、样式自定义、丰富的插件支持。本来想写一个loader，但是Umi的解析代码的规则还没有整理清楚。所以用了上面方法更加快捷高效。
自动编译则是写了webpack通过编写插件实现md文件监听。

2. 规范

排版规范：页面排版分为组件介绍、代码演示、API介绍三大部分。组件名：（大写驼峰）需使用一级标题书写；代码演示、API: 采用二级标题；其他：均采用三级标题书写。
API规范：API的编写需要区分组件的属性与事件部分，属性部分需要书写属性名、描述信息、属性类型、以及默认值；事件部分需要指定事件名、事件描述以及事件参数，如事件参数为复杂数据类型，需要在下方说明具体数据结构。
示例规范：组件示例部分需要按照组件具体功能顺序书写，每个实例需要按照功能、描述、代码示例的顺序进行编写，编写顺序需要与右侧演示部分对应编写。
样式变量：样式变量部分需要将编写当前组件中使用到的组件自定义变量在文档中列出，方便使用者在使用当前组件时进行样式覆写。

写在最后

该组件库前前后后花费了4个月的时间，之所以用了这么长时间，主要是我们是业务部门，平常还需要日常维护和开发系统，组件库的开发只能在开发该页面时封装成组件，要不就用业余时间去开发。目前发布了alpha-3.0版本，正式版本待我们将特单元测试和组件更加完善。

虽然它不是绩效，也不是任务。但它是一个提高自身实力的平台。不负每一份热爱、不负每一天拼搏。也感谢各位开发人员对该组件库的贡献。@jjjona0215、@蝼蚁11再此感谢两位的鼎力支持，也感谢其他人对该组件库的支持。

链接：github地址、文档地址