Vite + React 组件开发实践

时间  2021-06-18 标签 css html 前端 webpack web json 浏览器 前端工程师 框架 less

简介： 绝不夸张的说，Vite 给前端带来的绝对是一次革命性的变化。或者也能够说是 Vite 背后整合的 esbuild 、 Browser es modules、HMR、Pre-Bundling 等这些社区中关于 JS 编译发展的先进工具和思路，在 Vite 这样的整合推进下，给前端开发带来了革命性变化。css

做者 | 风水
来源 | 阿里技术公众号html

去年发表的《一个好的组件应该是什么样的？》 一文介绍了借助 TypeScript AST 语法树解析，对 React 组件 Props 类型定义及注释提取，自动生成组件对应 截图、用法、参数说明、README、Demo 等。在社区中取得了比较好的反响，同时应用在团队中也取得了较为不错的结果，如今内部组件系统中已经累计使用该方案沉淀 1000+ 的 React 组件。前端

以前咱们是借助了 webpack + TypeScript 作了一套用于开发 React 组件的脚手架套件，当开发者要组件开发时，便可直接使用脚手架初始化对应项目结构进行开发。webpack

虽然主路径上确实解决了组件开发中所遇到的组件无图无真相、组件参数文档缺失、组件用法文档缺失、组件 Demo 缺失、组件没法索引、组件产物不规范等内部组件管理和沉淀上的问题，但 Webpack 的方案始终仍是会让组件开发多一层编译，当一个组件库沉淀超过 300+ 时，引入依赖不断增加，仍是会带来组件编译上的负荷致使开发者开发体验降低。web

一 Vite 带来的曙光

Vite 给前端带来的绝对是一次革命性的变化，这么说绝不夸张。json

或许应该说是 Vite 背后整合的 esbuild 、 Browser es modules、HMR、Pre-Bundling 等这些社区中关于 JS 编译发展的先进工具和思路，在 Vite 这样的整合推进下，给前端开发带来了革命性变化。浏览器

我很早就说过，任何一个框架或者库的出现最有价值的必定不是它的代码自己，而是这些代码背后所带来的新思路、新启发。因此我在写文章的时候，也很注重能把我思考最后执行的整个过程讲清楚。前端工程师

Vite 为何快，主要是 esbuild 进行 pre-bundles dependencies + 浏览器 native ESM 动态编译，这里我不作过多赘述，详细参考：Vite: The Problems框架

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

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

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

以前为了获取组件入参的类型数据会在 Wwebpack 层面作插件用于动态分析 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 的文件解析。

1 组件 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` 运行模块

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

2 组件 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

3 组件 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！

相关连接
https://vitejs.dev/guide/why.html#the-problems
https://d.umijs.org/
https://ice.work/

前端开发技术图谱

6 大知识点，14 个课程，680 个课时，将前端开发知识和实战经验融入图谱，包含 HTML 、CSS、JavaScript 、jQuery 、Vue 、React 、Angular 、NodeJS 等前端开发必备技能，帮你迅速提高。

本文为阿里云原创内容，未经容许不得转载。

联系我们 沪ICP备13005482号-10