关于组件库，你需要知道的

[aoilti]

关于重构

组件库重构的想法，从我开发第一个组件时就已经萌生了，至于为什么有这样的想法？

1. 现有组件库开发组件时，我们的流程是这样的。首先你需要写出组件的代码。然后你需要在 /examples/demo 目录下，写出关于组件的demo。最后，在组件的目录下新建index.md文件，再把刚刚写好的demo复制出代码，放在index.md的代码块里。
   在这个过程中我们需要考虑组件demo如何书写，路由如何定义，如何保证demo和示例代码同步，如何保证API自动生成等问题。这样的步骤繁琐且容易出错，所以如果有一款开箱即用的文档生成工具，就能极大提高我们的开发效率。
2. 在组件库立项初期，因为人力资源问题，我们的组件库采用的策略是，先写RN组件，RN组件写好以后通过一段脚本，转译成H5组件。这样的思路看似不错，然而中间转译的工具是非常复杂的，而且这个工具是由我们自己写的，在维护这个工具的过程中势必会踩更多的坑，由一变二的过程本意是为了节省更多的时间，但是如此做法反倒增加了时间。
3. 组件库的不分包问题。目前我们组件库发包时，会把RN和H5发在同一个包里，这样的做法一方面增加了包体积，另外一方面也违背原子设计的规则。
4. 组件库的理解。如果把组件库比喻成一栋楼的话，那么这栋楼在初期我们就需要对楼每层的上下间距（size系统），楼面大白楼内大白刷什么（color系统），大楼避震如何（测试系统），售楼部样品展示（文档系统）等问题掌握清楚，哪怕开始没有这些，但是我们需要预留出合适的位置，等待后期成熟，轻松插拔。凑合主义对于建设大楼是要不得的。
5. 回到第一点的问题上来，在维护maimai_node的过程中，我发现在maimai_node里有很多优秀的组件，但是这些组件存在重复造轮子的问题，也就是说A团队本来写的有一个tips组件，但是B团队不知道，所以B团队一旦有需要，B团队在不知情的前提下，大概率会再去造一个。这样极大浪费了时间和效率。如果能把开箱即用的文档工具集成到maimai_node，那简直不要太爽。

TODO

我是一个极度懒惰又爱BB的人，关于上述问题，很早以前我就提出，但是苦于自己极大的惰性，迟迟不曾动手，在2021年S3，我终于开始着手开发。

1. 不得不说，React的生态在三大框架里做的还是不错的。文档生成工具我选择了阿里团队开源的Dumi，简单易上手。
2. 关于2、3、4的问题，这里先保留一下，后面讲。
3. 对于5的问题，1完成后，再做5，水到渠成。历史告诉我们，天下大势分久必合，春秋五霸，战国七雄都是昙花一现，大一统是主流，我们的目标是建立大一统的脉脉前端。

新的结构

在对组件库做新的重构时，我选择了mono repo来重新组织了我们组件库的结构，RN和H5我对他们进行了拆分，另外对于可复用的css变量部分以及未来可能会用到的ts方法类，我抽离出了utils包。最后，我还给组件库起了一个不知道好不好听的名字，schiff在德语里，它是船的意思，我希望我们的未来是星辰大海，因此拥有一艘船，是我们远征的基础。下面来看一下新的组织结构是什么样的吧。


重新组织了结构后，我对button组件进行了一次移植，如上图所示，可以看到目录清爽了很多。再来看一下引入方式。

目前我针对打包发布构建进行了全流程的跑通，但是苦于精力问题，@schiff/RN还没有做，另外组件移植我也只做了Button的（由于依赖Icon，这部分没移植）。还有就是关于css处理上，我替换了之前的less，与bootstrap看齐，采用了scss，关于scss和less的区别，见仁见智，我个人倾向跟着社区走，我更喜欢scss一些。

未来

现阶段，组件库还处于雏形阶段，如果想要打造出一款成熟的组件库，还需要更多的路要走，未来我认为还需要做的事情有以下方面。

1. 组件移植，更多的组件移植进来。可以先做H5的，RN的优先级暂时不高。
2. 组件库测试。现阶段我没有考虑测试如何接入，可以考虑一下。
3. RN组件移植，调研RN组件文档生成工具，具体可以看看业界是如何实现的。
4. 拆分Icon组件，把Icon资源部分从原来的在组件库中剥离，组件库中的Icon组件只是一个负责显示图标资源的壳子。
5. 规范组件库开发，提高组件库重要程度。这里包含组件库开发过程中的提交规范，建立组件库前端委员会对组件设计API评审，统一设计规范等。
6. 未来待补充...
   一直很喜欢一句话，叫路漫漫其修远兮，吾将上下而求索。希望后来者能够不要像我一样，做行动的矮子，大家加油。
   项目地址：aoilti/schiff
   参考文章：
   基于lerna和yarn workspace的monorepo工作流
   开源项目都在用 monorepo，但是你知道居然有那么多坑么？