北京高级网站建设,普陀专业做网站,宿松住房和城乡建设局网站,网站建设大致分哪几个板块简介#xff1a; 毫不夸张的说#xff0c;Vite 给前端带来的绝对是一次革命性的变化。或者也可以说是 Vite 背后整合的 esbuild 、 Browser es modules、HMR、Pre-Bundling 等这些社区中关于 JS 编译发展的先进工具和思路#xff0c;在 Vite 这样的整合推动下#xff0c;给…简介 毫不夸张的说Vite 给前端带来的绝对是一次革命性的变化。或者也可以说是 Vite 背后整合的 esbuild 、 Browser es modules、HMR、Pre-Bundling 等这些社区中关于 JS 编译发展的先进工具和思路在 Vite 这样的整合推动下给前端开发带来了革命性变化。 作者 | 风水 来源 | 阿里技术公众号
去年发表的《一个好的组件应该是什么样的》 一文介绍了借助 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 组件类型定义的思路将可以做一个比较大的改变。
之前为了获取组件入参的类型数据会在 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 结合出下一段传奇故事。
原文链接 本文为阿里云原创内容未经允许不得转载。
