2021-06-06

架构设计

24 分钟读完 (大约 3568 个字)

Vite + React 组件开发实践

去年，在 “阿里技术” 上发表的《这一年我的对组件的思考》介绍了借助 TypeScript AST语法树解析，对 React 组件Props类型定义及注释提取，自动生成组件对应截图、用法、参数说明、README、Demo 等。在社区中取得了比较好的反响，同时应用在团队中也取得了较为不错的结果，现在内部组件系统中已经累计使用该方案沉淀 1000+ 的 React组件。

屏幕录制 2020-04-22 下午8.25.59.gif

之前我们是借助了 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

Vite Module Load Way

在这个思路的背景下，回到我们组件开发的场景再看会发现以下几个问题高度吻合：

组件库开发，实际上不需要编译全部组件。
组件开发，编译预览页面主要给开发者使用，浏览器兼容可控。
HMR(热更新) 能力在 Vite 加持下更加显得立竿见影，是以往组件开发和调试花费时间最多的地方。
Vite 中一切源码模块动态编译，也就是TypeScript类型定义 和 JS注释 也可以做到动态编译，大大缩小编译范围。

那么，以往像StoryBook和之前我们用于提取tsx组件类型定义的思路将可以做一个比较大的改变。

之前为了获取组件入参的类型数据会在webpack层面做插件用于动态分析export的tsx组件，在该组件下动态加入一段__docgenInfo的静态属性变量，将从AST分析得到的类型数据和注释信息注入进组件JS Bundle，从而进一步处理为动态参数设置：

TypeScript 对组件Props的定义

分析注入到JS Bundle中的内容

JS 中的数据描述

分析转换后实现的参数交互设置

通过分析转换实现动态参数设置

所以对于组件来说，实际上获取这一份类型定义的元数据对于组件本身来说是冗余的，不轮这个组件中的这部分元数据有没有被用到，都会在webpack编译过程中解析提取并注入到组件Bundle中，这显然是很低效的。

在Vite的思路中，完全可以在使用到组件元数据时，再获取其元数据信息，比如加载一个React组件为：

import ReactComponent from './component1.tsx'

那么加载其元数据即：

import ComponentTypeInfo from './component1.tsx.type.json';

// or
const ComponentTypeInfoPromise = import('./component1.tsx.type.json');

通过Vite中 Rollup 的插件能力加载 .type.json 文件类型，从而做到对应组件元数据的解析。同时借助Rollup本身对于编译依赖收集和HMR的能力，做到组件类型变化的热更新。

设计思路

以上是看到Vite的模块加载思路，得到的一些灵感和启发，从而做出的一个初步设想。

但如果真的要做这样一个基于Vite的React 、 Rax 组件开发套件，除了组件入参元数据的获取以外，当然还有其他需要解决的问题，首当其冲的就是对于 .md 的文件解析。

组件 Usage

参照 dumi 及 Icework 所提供的组件开发思路，组件Usage 完全可以以Markdown写文档的形式写到任何一个 .md 文件中，由编译器动态解析其中关于jsx,tsx,css,scss,less的代码区块，并且把它当做一段可执行的script 编译后，运行在页面中。

这样既是在写文档，又可以运行调试组件不同入参下组件表现情况，组件有多少中Case，可以写在不同的区块中交由用户自己选择查看，这个设计思路真是让人拍案叫绝！

最后，如果能结合上述提到 Vite 的 esbuild,动态加载 和 HMR能力，那么整个组件开发体验将会再一次得到质的飞跃。

所以针对Markdown文件需要做一个Vite插件来执行对.md的文件解析和加载，预期要实现的能力如下：

import &#123; content, modules &#125; from "./component1/README.md";

// content README.md 的原文内容
// modules 通过解析获得的`jsx`,`tsx`,`css`,`scss`,`less` 运行模块

预期设想效果，请点击放大查看

README.md 设想效果

组件 Runtime

一个常规的组件库目录应该是什么样的？不论是在一个单独的组件仓库，还是在一个已有的业务项目中，其实组件的目录结构大同小异，大致如下：

components
├── component1
│   ├── README.md 
│   ├── index.scss
│   └── index.tsx
├── component2
│   ├── README.md
│   ├── index.scss
│   └── index.tsx

在我们的设想中你可以在任意一个项目中启动组件开发模式，在运行vite-comp之后就可以看到一个专门针对组件开发的界面，在上面已经帮你解析并渲染出来了在README.md中编写的组件Usage，以及在index.tsx定义的interface，只需要访问不同的文件路径，即可查看对应组件的表现形态。

同时，最后可以帮你可以将这个界面上的全部内容编译打包，截图发布到NPM上，别人看到这个组件将会清晰看到其组件入参，用法，截图等，甚至可以打开Demo地址，修改组件参数来查看组件不同状态下的表现形态。

如果要实现这样的效果，则需要一套组件运行的Runtime进行支持，这样才可以协调React组件、README.md、TypeScript类型定义串联成我们所需要的组件调试+文档一体的组件开发页面。

在这样的Runtime中，同样需要借助Vite的模块解析能力，将其URL为**/*/(README|*).html的请求，转换为一段可访问的组件Runtime Html返回给浏览器，从而让浏览器运行真正的组件开发页面。

http://localhost:7000/components/component1/README.html
-> 
/components/component1/README.html 
->
/components/component1/README.md
-> 
Runtime Html

组件 Props Interface

正如我上述内容中讲到的，如果利用Vite添加一个对tsx的组件props interface类型解析的能力，也可以做成独立插件用于解析 .tsx.type.json 结尾的文件类型, 通过import这种类型的文件，从而让编译器动态解析其tsx文件中所定义的TypeScript类型，并作为模块返回给前端消费。

TypeScript Interface转换示意

其加载过程就可以当做是一个虚拟的模块，可以理解为你可以通过直接import一个虚拟的文件地址，获取到对应的React组件元信息：

// React Component
import Component from './component1.tsx';
// React Component Props Interface
import ComponentTypeInfo from './component1.tsx.type.json';

// or
const ComponentTypeInfoPromise = import('./component1.tsx.type.json');

由于这种解析能力并不是借助于esbuild进行，所以在转换性能上无法和组件主流程编译同步进行。

在请求到该文件类型时，需要考虑在Vite的 Serve 模式下，新开线程进行这部分内容编译，由于整个过程是异步行为，不会影响组件主流程渲染进度。当请求返回响应后，再用于渲染组件Props定义及侧边栏面板部分。

在热更新过程中，同样需要考虑到tsx文件修改范围是否涉及到TypeScript类型的更改，如果发现修改导致类型变化时，再触发HMR事件进行模块更新。

组件 Build

以上都是在讨论组件在Vite的Serve态(也就是开发态)下的情况，我们上文中大量借助Vite利用浏览器es module的加载能力，从而做的一些开发态的动态加载能力的扩展。

但是Vite在组件最终Build过程中是没有Server服务启动，当然也不会有浏览器动态加载，所以为了让别人也可以看到我们开发的组件，能够体验我们开发时调试组件的样子，就需要考虑为该组件编译产出一份可以被浏览器运行的html。

所以在Vite插件开发过程中，是需要考虑在Build状态下的编译路径的，如果是在Build状态下，Vite将使用Rollup的编译能力，那么就需要考虑手动提供所有组件的rollup.input(entries)。

在插件编写过程中，一定需要遵循Rollup所提供的插件加载生命周期，才能保证Build过程和Serve过程的模块加载逻辑和编译逻辑保持一致。

Vite vs Rollup

我一开始在实现的过程中，就是没有了解透彻Vite和Rollup的关系，在模块解析过程中依赖了大量Vite的Server提供的服务端中间件能力。导致在考虑到Build态时，才意识当其中的问题，最后几乎重新写了之前的加载逻辑。

总结

我姑且把这个方案（套件）称之为vite-comp，其大致的构成就是由Vite + 3 Vite Pugins构成，每个插件相互不耦合，相互职责也不相同，也就是说你可以拿到任意一个Vite插件去做别的用途，后续会考虑单独开源，分别是：

Markdown，用于解析.md文件，加载后可获取原文及jsx,tsx等可运行区块
TypeScript Interface，用于解析.tsx文件中对于export组件的props 类型定义
Vite Comp Runtime，用于运行组件开发态，编译最终组件文档

Vite Comp

结合Vite，已经实现了Vite模式下的React、Rax组件开发，它相比于之前使用webpack做的组件开发，已经体现出了以下几个大优势：

无惧大型组件库，即使有2000个组件在同一个项目中，启动依旧是<1000ms
高效的组件元数据加载流，项目一切依赖编译按需进行
毫秒级热更新响应，借助esbuild几乎是按下保存的一瞬间，就可以看到改动效果

预览体验

启动

Vite Comp 启动

Markdown 组件文档毫秒级响应

毫秒级Markdown响应

TypeScript类型识别

Vite 现在还是只是刚刚起步，这种全新的编译模式，已经给我带来了非常多的开发态收益，结合Vite的玩法未来一定还会层出不穷，比如Midway + lambda + Vite的前端一体化方案也是看得让人拍案叫绝，在这个欣欣向荣的前端大时代，相信不同前端产物都会和Vite结合出下一段传奇故事。

我是一个热爱生活的前端工程师！ Yooh！🤠

# JavaScript