- A+
前言
最近做的项目使用了微前端框架single-spa。
对于这类微前端框架而言，通常有个utility应用，也就是公共应用，里面是各个子应用之间可以共用的一些公共组件或者方法。
对于一个团队而言，项目中公共组件和方法的使用难点不在于封装不在于技术，很多时候在于团队内部成员是否都能了解这些组件，以避免重复开发，从而提升团队效率。
如果是团队比较小，人员比较稳定的项目组可能还好点，对于团队比较大，人员流动较快的团队，这些通用组件和方法往往就被人遗忘在角落，很难再得到有效利用。
因为我所在的项目还在开发初期，并且是新入职也想去熟悉一下当前项目中的一些通用组件和方法，所以我自己特意开发了一个文档应用去解决这个问题。
技术方案选型
对于一个面向Ant Design编程的咸鱼而言，这个文档应用肯定是往这个方向做。
目标是能做成Ant Design的组件文档那样好用，既能很快看清组件的使用效果，也能快速复制示例代码。
有了目标之后，很快选定了两个技术方案
- StoryBook方案
- 自己开发解析markdown文件的文档应用
StoryBook是市面上一款比较流行的构建UI组件和文档的库，功能很强大。
但是这个库如果要应用到我们项目的团队存在以下问题：
- 英文文档，有学习成本
- 引入single-spa的utility应用很麻烦
- 对于构建在utility应用中的组件，需要在StoryBook中再写一遍，容易不同步
- 对于通用方法可能不支持
尤其是第三点特别存在问题，团队成员大都是业务开发，有交付压力，不是在github上为爱发电的开源贡献者。
他们是否有意愿在utility应用中写了一遍组件代码后，又专门跑到这个StoryBook中再写一道？
如果组件代码修改后，StoryBook这边没修改，这种不同步很容易导致开发人员明明按照文档使用组件，但是组件就是报错，挫败感很强。
联系到现实，我已经预想到如果走这个方案，一个月内这个玩意就会名存实亡，成为形式主义的存在，在三个月后成为大家都不愿提起的垃圾了。
所以有了第二个方案的诞生：自己开发解析markdown文件的文档应用。
这个方案并不是我凭空想象出来的，而是在前公司中就有这么一个内部应用，组件开发人员自己编写markdown文件，最终生成组件文档，并且应用本身可以解析markdown文件中的代码部分，从而在组件文档中生成对应的组件示例。
彼时我只是一个组件开发人员，并不是这个文档应用的实现人员，所以也不知道其技术原理。
但是前公司这个应用让我知道了这么玩行得通，当时作为组件开发人员，接受和使用这个应用异常轻松，只要会写markdown就行了，没有学习成本。而且使用这种方式，控制权掌握在自己手中，更容易和自己的团队项目有效结合起来。
基本原理
虽然这个文档应用是我一个人花了两天的时间独立完成，但是花的是工作时间，完成后也是公司内部项目，所以这个文档应用我没法开源出来。
不过我可以告诉大家一个主要思路和步骤，想必复现出来也并不困难。
第一步让我们搞定这个项目的框架。
因为需要引入single-spa的utility应用，所以框架我直接用的是single-spa的基座，并且项目内含一个子应用用于展示文档。而utility应用直接引入线上开发环境的utility应用，避免团队成员重复书写组件代码，也解决了文档和实际应用不同步的问题。
通过这一步，我们解决了StoryBook方案中的痛点2和痛点3。
第二步我们需要载入markdown文件。
这一步肯定是通过webpack的加载器来做处理，这些加载器有的比较强大，可以直接将markdown文件转换为html。但是我并没有选择这种，而是直接用的raw-loader，将我们的markdown文件转换为字符串载入。
代码大致如下，这个比较简单，就不说了。
module.exports = { module: { rules: [ { test: /.md$/, use: 'raw-loader' } ] } } 第三步我们需要解析markdown文件生成文档，并解析其中的React组件，生成组件示例。
解析markdown文件转换为html文档，实际上有个比较强大的库，叫Showdown。
而我所用到的库react-showdown则是对Showdown的进一步封装，可以借助一个react组件将markdown和包含在markdown文件中的react组件渲染成html。
下面是它的一个官方示例：
import React from 'react'; import MarkdownView from 'react-showdown'; export default function App() { const markdown = ` # Welcome to React Showdown :+1: To get started, edit the markdown in `example/src/App.tsx`. | Column 1 | Column 2 | |----------|----------| | A1 | B1 | | A2 | B2 | `; return ( <MarkdownView markdown={markdown} options={{ tables: true, emoji: true }} /> ); }; 通过MarkdownView这个组件，可以将一串markdown格式的文本转化为html。
另外我们注意到它的选项，tables为true，如果不设置这个的话，markdown中的table格式将不会被转化成表格。第二个emoji为true是支持emoji转换。
这个时候你可能要问，这只是转换了一下markdown文件而已，转换react组件呢？
我们可以看一下下面这个官方示例：
import MarkdownView from 'react-showdown'; function CustomComponent({ name }: { name: string }) { return <span>Hello {name}!</span>; } const markdown = ` # 我是个标题: <CustomComponent name="world" />`; <MarkdownView markdown={markdown} components={{ CustomComponent }} /> 在markdown文本中可以直接写上CustomComponent这个自定义的react组件代码，然后在MarkdownView的components中传入CustomComponent即可。
生成的最终html中不仅会有个标题，标题下面还会展示一个叫hello world！的文本，而不是展示<CustomComponent name="world" />这个字符串。
排疑解难
看完了上面的原理，想必您已经可以实现这样的一个文档应用了。
不过在这个过程中您可能还是会遇到一些小麻烦，这里提前给您支个招。
麻烦1：markdown转换成html后的代码高亮处理。
因为我们做的是一个组件文档，那么肯定会涉及到代码展示。
markdown文件中的代码块,使用react-showndown转换后的并没有做高亮处理。
不过react-showdown是支持Showdown的各种扩展的，其中有个扩展叫showdown-highlight，通过这个扩展可以对代码块做高亮处理。
麻烦2：react-showndown只支持简单的组件。
虽然react-showndown可以解析react组件代码，但是它也只能简单解析这个组件。如果我们演示的示例比较复杂，涉及到一些函数，还有一些库的引用，很显然不能再markdown文件中直接写。
这里我建议直接将每个组件的示例写到一个独立的js中，这个js导出一个Demo组件，然后我们在markdown文件中直接引用这个demo组件即可。
大致代码如下：
import MarkdownView from 'react-showdown'; import ButtonDemo from './ButtonDemo'; const markdown = ` # 按钮组件 组件描述 ## 代码示例 <ButtonDemo /> ```tsx 这里贴出以ButtonDemo组件中的代码 ``` ## API | 属性 | 说明 |XXX| |----------|----------|-----| | title | 按钮文本 | XXX | | type | 按钮类型 | XXX | `; <MarkdownView markdown={markdown} components={{ ButtonDemo }} /> 通过上面这种方式，不论我们ButtonDemo中的逻辑和功能多么复杂，展示出来都是没问题的。
麻烦3：如何将这个文档应用做到简单好用。
看了上面的代码，可能有人会觉得应该没问题了。
但是我们得明白，我们这个东西是做给业务开发的人员用的，而不是做给我们自己用的。
我业务开发人员为什么要知道你这些什么 react-showdown 的代码？ 我业务开发人员还要学习你的这些鬼东西？ 不是每个人都想着学这些乱七八糟的技术好吗？ 我每天就只想在6点下班，就算你5分钟内给我讲明白了，你这个文档应用我用不用还两说。 你要是5分钟之内还讲不明白怎么用，那你休想我在这上面给一个公共组件写文档。 我们面对的基本就是这么一个场景，我们做这个应用是为了解决项目中实际面临的问题，是面向业务开发人员编程，而不是面向领导和KPI编程。
所以我们需要做到简单好用，将所有涉及到react-showdown这玩意的部分全部不被业务开发人员感知。
想象一下，写一个组件的文档，缩减到最少，就是一个markdown文件，和一个demo.js。
那么我们就只让业务开发人员去写这两个东西就行，把他们的工作量减少到最小。
就给他们两个文件夹，一个文件夹叫doc，里面放markdown文件，一个文件夹叫demo，里面放各个demo。
再用一个字典配置dict.js，去做个基本的配置。
如果现在有个Easy组件要写文档，那么我们的dict.js内容可能就是下面这样：
const dict=['Easy','Hard','XXX'] export defalt dict 只需要加个字符串Easy即可。
然后你可以在那么doc文件夹下加个markdown文件叫EasyMD.md，demo文件夹下加个文件叫EasyDemo.tsx。
之后的所有步骤全部由我们的文档应用解析dict.js后自动完成，无需用户操心。
通过这样的一种约定，我们可以将业务开发人员的工作量减到最小，把他们写组件文档的门槛降到最低。
具体代码实现就略过了，实现的关键词叫：import()函数，其他的不用多说了。
总结
虽然说这个文档应用是受前公司启发，而且因为开发时间就两天，所以比较简陋，但是至少我做到了比前公司的内部应用更简单方便，完全没有学习成本。
好了，自吹一波就得了，本篇博客到此结束。
如有疏漏之处，还请不吝赐教。
