一、为什么要做这个组件库
笔者所在团队是做多端的C端商城，主要是小程序+H5，我们的技术栈选的是Taro+React。商城，自然比较庞大，基本的组件都会用到。比如基础的按钮、价格、下拉筛选菜单... 熟悉这一块的朋友可能清楚，
Taro+React的组件库，Taro官方做了Taro UI，用过的朋友应该也知道，好用&能用的组件真的是很有限，业内也没有其他好用的组件库
于是我们在业务中，沉淀了一套基于Taro框架开发的多端React UI组件库，沉淀过程中其实我们也是从0-1实现一个组件库，从中也沉淀了不少经验
本篇文章主要讲组件库的诞生、如何落地到开源，重在分享经验，具体细节限于篇幅不展开
二、Tard的基本介绍
1、定义
一套基于 Taro 框架开发的多端 React UI 组件库
2、组件库相关链接
三、Tard是如何诞生及落地的
我们做第一个C端商城由于团队刚成立，且项目时间比较急，所以没来的急做组件库，就上线了
组件都写在了业务工程里面，因此也带来了如下问题：
- 组件中揉杂了很多业务代码，
维护性差 - 组件封装的质量不高、API定义随意，
可读性差 - 组件不能在多个业务工程中复用，效率低，
复用性差
于是我们一直想做一套组件库，做组件库的想法由此诞生，但真正落地还是来自业务驱动
当时产品团队规划了两条新的商城产品线，意味着还需要大量使用到组件，前车之鉴，我们在两个项目启动时，开始搭建了组件库，我们的做法：
- 研究业内开源组件库，基本开源的都研究过了，参考实现方案
- 开发前根据产品的PRD汇总需要封装的组件
- 开发过程中先把组件先抽到组件库，业务工程通过
npm link组件库使用 - 组件封装都按照统一的标准来做，分为三类，
组件本身，组件文档，组件demo - 设计稿出来后
组件的样式来自于业务设计稿
我们大概封装了30+组件，当然，这样做我们也遇到了一些问题
- 组件样式取自业务设计稿，
不太规范，要知道做组件的一大特性之一就是主题定制，而实现主题定制实现方式是css变量，变量的值需要设计来确定，但是我们没有这么多时间以及设计资源，于是变量取的是业务设计稿 - 组件的规范，
组件的命名、API参数名未统一（比如是否现实遮罩层有人用的isMask，有人用的overlay），好几个人并行开发，没有一套统一的标准，目标是先满足业务，也没来的及顾及更多 - 组件的
使用文档、demo不完善，还是没有一个统一的标准check - 组件需要适配小程序、H5，自测不够
四、Tard为什么想开源
来自两个契机：第一有一条产品线停止了，意味着我们有更多的时间可以做好组件库；第二在做组件库的过程中，调研到taro-react组件库这块的确是空白区，除了上面提到的Taro UI，在github上搜到两个star数100+的仓库外，没有其他解决方案
于是我们想，何不做好一点，甚至开源，补起这一空缺！！
说干就干，于是我们开始着手解决上面遇到的3个大问题
- 这块需要设计的支持，组内资源都忙于业务，所以在组件库上没有多余的资源投入，我们几个人也是兴趣驱动，幸运的是有一名设计主动联系我帮忙，大家看到的logo、官网都是经过设计的，但是组件库的整个样式变量还是很庞大的，我们目前基于业务设计稿，后续应该会来一轮优化，但不影响基本使用❌
- 组件命名格式用大驼峰，参看各开源组件库命名，API制定一个标准文档，根据标准文档来制定，之前写的不一致的调整过来，虽然业务已经用了，但还没上线，即时纠正过来的成本还是可控的✅
- 制定了使用文档以及demo的写法标准，以及需要覆盖的案例。制定好之后其实就是工作量的问题了，分工弄完后，依次check，针对有问题的再改✅
- 好在自己组内的业务用着组件库，业务由测试完整的测试，遇到的适配问题都及时发现解决了✅
完成以上任务后跟随业务上线，我们发布了[email protected]
五、加入我们
未来规划：
- 组件库样式打磨
- 提供多套主题样式
- 补充单元测试
- 持续丰富组件
- 组件库构建抽为cli
- vscode提示插件
- lint校验规范
- ...
路漫漫其修远兮，目前参与的3个人主要还是做业务，之前看到一句话，当你的业务从1-100扩张时，资源很难或者说不可能也扩张100倍，比如之前我们做一个商城可能需要150人日，基于组件库做一个可能可以降到100人日
对做技术最近的思考：做技术可能短期来看，收益不明显，但是走的越远，越能发现价值；要用长远的眼光来看，并且以最佳实践的方式实现
坚信组件库的必要性之后，我们后续计划持续升级tard，由于需要做的事情实在太多。欢迎大家共建，我们会有一些issue发布在github，可以通过提交pr加入我们