去年,在 “阿里技术” 上发表的《这一年我的对组件的思考》 介绍了借助 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
在这个思路的背景下,回到我们组件开发的场景再看会发现以下几个问题高度吻合:
- 组件库开发,实际上不需要编译全部组件。
- 组件开发,编译预览页面主要给开发者使用,浏览器兼容可控。
HMR(热更新)
能力在Vite
加持下更加显得立竿见影,是以往组件开发和调试花费时间最多的地方。Vite
中一切源码模块动态编译,也就是TypeScript类型定义
和JS注释
也可以做到动态编译,大大缩小编译范围。
那么,以往像StoryBook
和之前我们用于提取tsx
组件类型定义的思路将可以做一个比较大的改变。
之前为了获取组件入参的类型数据会在webpack
层面做插件用于动态分析export
的tsx
组件,在该组件下动态加入一段__docgenInfo
的静态属性变量,将从AST
分析得到的 类型数据 和 注释信息 注入进组件JS Bundle
,从而进一步处理为动态参数设置:
TypeScript 对组件Props的定义
分析注入到JS Bundle中的内容
分析转换后实现的参数交互设置
所以对于组件来说,实际上获取这一份类型定义的元数据
对于组件本身来说是冗余的,不轮这个组件中的这部分元数据
有没有被用到,都会在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 { content, modules } from "./component1/README.md";
// content README.md 的原文内容
// modules 通过解析获得的`jsx`,`tsx`,`css`,`scss`,`less` 运行模块
预期设想效果,请点击放大查看
组件 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
类型,并作为模块返回给前端消费。
其加载过程就可以当做是一个虚拟的模块,可以理解为你可以通过直接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
和Rollup
的关系,在模块解析过程中依赖了大量Vite
的Server
提供的服务端中间件能力。导致在考虑到Build
态时,才意识当其中的问题,最后几乎重新写了之前的加载逻辑。
总结
我姑且把这个方案(套件)称之为vite-comp
,其大致的构成就是由Vite
+ 3 Vite Pugins
构成,每个插件相互不耦合,相互职责也不相同,也就是说你可以拿到任意一个Vite
插件去做别的用途,后续会考虑单独开源,分别是:
- Markdown,用于解析
.md
文件,加载后可获取原文及jsx
,tsx
等可运行区块 - TypeScript Interface,用于解析
.tsx
文件中对于export
组件的props
类型定义 - Vite Comp Runtime,用于运行组件开发态,编译最终组件文档
结合Vite
,已经实现了Vite
模式下的React
、Rax
组件开发,它相比于之前使用webpack
做的组件开发,已经体现出了以下几个大优势:
- 无惧大型组件库,即使有2000个组件在同一个项目中,启动依旧是
<1000ms
- 高效的组件元数据加载流,项目一切依赖编译按需进行
- 毫秒级热更新响应,借助
esbuild
几乎是按下保存的一瞬间,就可以看到改动效果
预览体验
启动
Markdown 组件文档毫秒级响应
TypeScript类型识别
Vite
现在还是只是刚刚起步,这种全新的编译模式,已经给我带来了非常多的开发态收益,结合Vite
的玩法未来一定还会层出不穷,比如Midway + lambda + Vite
的前端一体化方案也是看得让人拍案叫绝,在这个欣欣向荣的前端大时代,相信不同前端产物都会和Vite
结合出下一段传奇故事。
我是一个热爱生活的前端工程师! Yooh!🤠