Vite 微前端实践,实现一个组件化的方案

前端迷

共 7185字,需浏览 15分钟

 ·

2022-02-27 05:49

什么是微前端

微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。

微前端借鉴了微服务的架构理念,将一个庞大的前端应用拆分为多个独立灵活的小型应用,每个应用都可以独立开发、独立运行、独立部署,再将这些小型应用联合为一个完整的应用。微前端既可以将多个项目融合为一,又可以减少项目之间的耦合,提升项目扩展性,相比一整块的前端仓库,微前端架构下的前端仓库倾向于更小更灵活。

特性

  • 技术栈无关 主框架不限制接入应用的技术栈,子应用可自主选择技术栈
  • 独立开发/部署 各个团队之间仓库独立,单独部署,互不依赖
  • 增量升级 当一个应用庞大之后,技术升级或重构相当麻烦,而微应用具备渐进式升级的特性
  • 独立运行时 微应用之间运行时互不依赖,有独立的状态管理
  • 提升效率 应用越庞大,越难以维护,协作效率越低下。微应用可以很好拆分,提升效率

目前可用的微前端方案

微前端的方案目前有以下几种类型:

基于 iframe 完全隔离的方案

作为前端开发,我们对 iframe 已经非常熟悉了,在一个应用中可以独立运行另一个应用。它具有显著的优点:

  1. 非常简单,无需任何改造
  2. 完美隔离,JS、CSS 都是独立的运行环境
  3. 不限制使用,页面上可以放多个 iframe 来组合业务

当然,缺点也非常突出:

  1. 无法保持路由状态,刷新后路由状态就丢失
  2. 完全的隔离导致与子应用的交互变得极其困难
  3. iframe 中的弹窗无法突破其本身
  4. 整个应用全量资源加载,加载太慢

这些显著的缺点也催生了其他方案的产生。

基于 single-spa 路由劫持方案

single-spa 通过劫持路由的方式来做子应用之间的切换,但接入方式需要融合自身的路由,有一定的局限性。

qiankun 孵化自蚂蚁金融科技基于微前端架构的云产品统一接入平台。它对 single-spa 做了一层封装。主要解决了 single-spa 的一些痛点和不足。通过 import-html-entry 包解析 HTML 获取资源路径,然后对资源进行解析、加载。

通过对执行环境的修改,它实现了 JS 沙箱样式隔离 等特性。

京东 micro-app 方案

京东 micro-app 并没有沿袭 single-spa 的思路,而是借鉴了 WebComponent 的思想,通过 CustomElement 结合自定义的 ShadowDom,将微前端封装成一个类 webComponents 组件,从而实现微前端的组件化渲染。

Vite 上使用微前端

我们从 我们从 UmiJS 迁移到了 Vite 之后,微前端也成为了势在必行,当时也调研了很多方案。

为什么没用 qiankun

qiankun 是目前是社区主流微前端方案。它虽然很完善、流行,但最大的问题就是不支持 Vite。它基于 import-html-entry 解析 HTML 来获取资源,由于 qiankun 是通过 eval 来执行这些 js 的内容,而 Vite 中的 script 标签类型是 type="module",里面包含 import/export 等模块代码, 所以会报错:不允许在非 type="module"script 里面使用 import

退一步实现,我们采用了 single-spa 的方式,并使用 systemjs 的方式进行了微前端加载方案,也踩了不少的坑。single-spa 没有一个友好的教程来接入,文档虽然多,但大多都在讲概念,当时让人觉得有一种深奥的感觉。

后来看了它的源码发现,这都是些什么……里面大部分代码都是围绕路由劫持而展开的,根本没有文档上那种高大上的感觉。而我们又用不到它路由劫持的功能,那我们为什么要用它?

从组件化的层面来说 single-spa 这种方式实现得一点都不优雅。

  1. 它劫持了路由,与 react-router 和组件化的思维格格不入
  2. 接入方式一大堆繁杂的配置
  3. 单实例的方案,即同一时刻,只有一个子应用被展示

后来琢磨着 single-spa 的缺点,我们可以自己实现一个组件化的微前端方案。

如何实现一个简单、透明、组件化的方案

通过组件化思维实现一个微应用非常简单:子应用导出一个方法,主应用加载子应用并调用该方法,并传入一个 Element 节点参数,子应用得到该 Element 节点,将本身的组件 appendChildElement 节点上。


类型约定

在此之前我们需要约定一个主应用与子应用之间的一个交互方式。主要通过三个钩子来保证应用的正确执行、更新、和卸载。

类型定义:

export interface AppConfig {
// 挂载
mount?: (props: unknown) => void;
// 更新
render?: (props: unknown) => ReactNode | void;
// 卸载
unmount?: () => void;
}

子应用导出

通过类型的约定,我们可以将子应用导出:mountrenderunmount 为主要钩子。

React 子应用实现:

export default (container: HTMLElement) => {
let handleRender: (props: AppProps) => void;

// 包裹一个新的组件,用作更新处理
function Main(props: AppProps) {
const [state, setState] = React.useState(props);
// 将 setState 方法提取给 render 函数调用,保持父子应用触发更新
handleRender = setState;
return <App {...state} />;
}

return {
mount(props: AppProps) {
ReactDOM.render(<Main {...props} />, container);
},
render(props: AppProps) {
handleRender?.(props);
},
unmount() {
ReactDOM.unmountComponentAtNode(container);
},
};
};

Vue 子应用实现:

import { createApp } from 'vue';
import App from './App.vue';

export default (container: HTMLElement) => {
// 创建
const app = createApp(App);
return {
mount() {
// 装载
app.mount(container);
},
unmount() {
// 卸载
app.unmount();
},
};
};

主应用实现

React 实现

其核心代码仅十余行,主要处理与子应用交互 (为了易读性,隐藏了错误处理代码)

export function MicroApp({ entry, ...props }: MicroAppProps) {
// 传递给子应用的节点
const containerRef = useRef(null);
// 子应用配置
const configRef = useRef();

useLayoutEffect(() => {
import(/* @vite-ignore */ entry).then((res) => {
// 将 div 传给子应用渲染
const config = res.default(containerRef.current);
// 调用子应用的装载方法
config.mount?.(props);
configRef.current = config;
});
return () => {
// 调用子应用的卸载方法
configRef.current?.unmount?.();
configRef.current = undefined;
};
}, [entry]);

return <div ref={containerRef}>{configRef.current?.render?.(props)}div>;
}

完成,现在已经实现了主应用与子应用的装载、更新、卸载的操作。现在,它是一个组件,可以同时渲染出多个不同的子应用,这点就比 single-spa 优雅很多。

entry 子应用地址,当然真实情况会根据 devprod 模式给出不同的地址:

"micro-app" entry="//localhost:3002/src/main.tsx" />

Vue 实现