前言
最近做的项目使用了微前端框架single-spa。
对于这类微前端框架而言,通常有个utility应用,也就是公共应用,里面是各个子应用之间可以共用的一些公共组件或者方法。
对于一个团队而言,项目中公共组件和方法的使用难点不在于封装不在于技术,很多时候在于团队内部成员是否都能了解这些组件,以避免重复开发,从而提升团队效率。
如果是团队比较小,人员比较稳定的项目组可能还好点,对于团队比较大,人员流动较快的团队,这些通用组件和方法往往就被人遗忘在角落,很难再得到有效利用。
因为我所在的项目还在开发初期,并且是新入职也想去熟悉一下当前项目中的一些通用组件和方法,所以我自己特意开发了一个文档应用去解决这个问题。
技术方案选型
对于一个面向Ant Design编程的咸鱼而言,这个文档应用肯定是往这个方向做。
目标是能做成Ant Design的组件文档那样好用,既能很快看清组件的使用效果,也能快速复制示例代码。
有了目标之后,很快选定了两个技术方案
- StoryBook方案
- 自己开发解析markdown文件的文档应用
StoryBook是市面上一款比较流行的构建UI组件和文档的库,功能很强大。
但是这个库如果要应用到我们项目的团队存在以下问题:
- 英文文档,有学习成本
- 引入single-spa的utility应用很麻烦
- 对于构建在utility应用中的组件,需要在StoryBook中再写一遍,容易不同步
- 对于通用方法可能不支持
尤其是第三点特别存在问题,团队成员大都是业务开发,有交付压力,不是在github上为爱发电的开源贡献者。
他们是否有意愿在utility应用中写了一遍组件代码后,又专门跑到这个StoryBook中再写一道?
如果组件代码修改后,StoryBook这边没修改,这种不同步很容易导致开发人员明明按照文档使用组件,但是组件就是报错,挫败感很强。
联系到现实,我已经预想到如果走这个方案,一个月内这个玩意就会名存实亡,成为形式主义的存在,在三个月后成为大家都不愿提起的垃圾了。
所以有了第二个方案的诞生:自己开发解析markdown文件的文档应用。
这个方案并不是我凭空想象出来的,而是在前公司中就有这么一个内部应用,组件开发人员自己编写markdown文件,最终生成组件文档,并且应用本身可以