去年发表的《一个好的组件应该是什么样的？》 一文介绍了借助 TypeScript AST 语法树解析，对 React 组件 Props 类型定义及注释提取，自动生成组件对应 截图、用法、参数说明、README、Demo 等。在社区中取得了比较好的反响，同时应用在团队中也取得了较为不错的结果，现在内部组件系统中已经累计使用该方案沉淀 1000+ 的 React 组件。
之前我们是借助了 webpack + TypeScript 做了一套用于开发 React 组件的脚手架套件，当开发者要组件开发时，即可直接使用脚手架初始化对应项目结构进行开发。
虽然主路径上确实解决了组件开发中所遇到的组件无图无真相、组件参数文档缺失、组件用法文档缺失、组件 Demo 缺失、组件无法索引、组件产物不规范等内部组件管理和沉淀上的问题，但 Webpack 的方案始终还是会让组件开发多一层编译，当一个组件库沉淀超过 300+ 时，引入依赖不断增长，还是会带来组件编译上的负荷导致开发者开发体验下降。
一 Vite 带来的曙光
Vite 给前端带来的绝对是一次革命性的变化，这么说毫不夸张。
或许应该说是 Vite 背后整合的 esbuild 、 Browser es modules、HMR、Pre-Bundling 等这些社区中关于 JS 编译发展的先进工具和思路，在 Vite 这样的整合推动下，给前端开发带来了革命性变化。
我很早就说过，任何一个框架或者库的出现最有价值的一定不是它的代码本身，而是这些代码背后所带来的新思路、新启发。所以我在写文章的时候，也很注重能把我思考最后执行的整个过程讲清楚。
Vite 为什么快，主要是 esbuild 进行 pre-bundles dependencies + 浏览器 native ESM 动态编译，这里我不做过多赘述，详细参考：Vite: The Problems
在这个思路的背景下，回到我们组件开发的场景再看会发现以下几个问题高度吻合：
1、组件库开发，实际上不需要编译全部组件。
2、组件开发，编译预览页面主要给开发者使用，浏览器兼容可控。
3、HMR（热更新）能力在 Vite 加持下更加显得立竿见影，是以往组件开发和调试花费时间最多的地方。
4、Vite 中一切源码模块动态编译，也就是 TypeScript 类型定义和 JS 注释也可以做到动态编译，大大缩小编译范围。
那么，以往像 StoryBook 和之前我们用于提取 tsx 组件类型定义的思路将可以做一个比较大的改变。
之前为了获取组件入参的类型数据会在 Wwebpack 层面做插件用于动态分析 export 的 tsx 组件，在该组件下动态加入一段 __docgenInfo 的静态属性变量，将从 AST 分析得到的类型数据和注释信息注入进组件 JS Bundle，从而进一步处理为动态参数设置：
TypeScript 对组件 Props 的定义
分析注入到 JS Bundle 中的内容
分析转换后实现的参数交互设置
所以对于组件来说，实际上获取这一份类型定义的元数据对于组件本身来说是冗余的，不论这个组件中的这部分元数据有没有被用到，都会在 Webpack 编译过程中解析提取并注入到组件 Bundle 中，这显然是很低效的。
在 Vite 的思路中，完全可以在使用到组件元数据时，再获取其元数据信息，比如加载一个 React 组件为：
那么加载其元数据即：
通过 Vite 中 Rollup 的插件能力加载 .type.json 文件类型，从而做到对应组件元数据的解析。同时借助 Rollup 本身对于编译依赖收集和 HMR 的能力，做到组件类型变化的热更新。
二 设计思路
以上是看到 Vite 的模块加载思路，得到的一些灵感和启发，从而做出的一个初步设想。
但如果真的要做这样一个基于 Vite 的 React 、 Rax 组件开发套件，除了组件入参元数据的获取以外，当然还有其他需要解决的问题，首当其冲的就是对于 .md 的文件解析。
1 组件 Usage
参照 dumi 及 Icework 所提供的组件开发思路，组件 Usage 完全可以以 Markdown 写文档的形式写到任何一个 .md 文件中，由编译器动态解析其中关于 jsx、tsx、css、scss、less 的代码区块，并且把它当做一段可执行的 script 编译后，运行在页面中。
这样既是在写文档，又可以运行调试组件不同入参下组件表现情况，组件有多少中Case，可以写在不同的区块中交由用户自己选择查看，这个设计思路真是让人拍案叫绝！
最后，如果能结合上述提到 Vite 的 esbuild 动态加载和 HMR 能力，那么整个组件开发体验将会再一次得到质的飞跃。
所以针对 Markdown 文件需要做一个 Vite 插件来执行对 .md 的文件解析和加载，预期要实现的能力如下：
预期设想效果，请点击放大查看：
2 组件 Runtime
一个常规的组件库目录应该是什么样的？不论是在一个单独的组件仓库，还是在一个已有的业务项目中，其实组件的目录结构大同小异，大致如下：
同时，最后可以帮你可以将这个界面上的全部内容编译打包，截图发布到 NPM 上，别人看到这个组件将会清晰看到其组件入参，用法，截图等，甚至可以打开 Demo 地址，修改组件参数来查看组件不同状态下的表现形态。
如果要实现这样的效果，则需要一套组件运行的 Runtime 进行支持，这样才可以协调 React 组件、README.md、TypeScript 类型定义串联成我们所需要的组件调试+文档一体的组件开发页面。
在这样的 Runtime 中，同样需要借助 Vite 的模块解析能力，将其 URL 为 **/*/(README|*).html 的请求，转换为一段可访问的组件 Runtime Html 返回给浏览器，从而让浏览器运行真正的组件开发页面。
3 组件 Props Interface
正如我上述内容中讲到的，如果利用 Vite 添加一个对 tsx 的组件 props interface 类型解析的能力，也可以做成独立插件用于解析 .tsx.type.json 结尾的文件类型，通过 import 这种类型的文件，从而让编译器动态解析其 tsx 文件中所定义的 TypeScript 类型，并作为模块返回给前端消费。
支付宝广告其加载过程就可以当做是一个虚拟的模块，可以理解为你可以通过直接 import 一个虚拟的文件地址，获取到对应的 React 组件元信息：
在请求到该文件类型时，需要考虑在 Vite 的 Serve 模式下，新开线程进行这部分内容编译，由于整个过程是异步行为，不会影响组件主流程渲染进度。当请求返回响应后，再用于渲染组件 Props 定义及侧边栏面板部分。
在热更新过程中，同样需要考虑到 tsx 文件修改范围是否涉及到 TypeScript 类型的更改，如果发现修改导致类型变化时，再触发 HMR 事件进行模块更新。
评论列表