演示地址
仓库地址
前言
-
如何理解微前端？独立部署，无感加载，环境隔离？
-
微前端能解决什么问题？不影响老系统前提下开发新业务享受新技术带来的便利？拆分系统分散到各开发小组方便维护？
-
目前主流微前端框架 qiankun 是否满足上述所有诉求？
在尝试过用 vite 搭建 qiankun 项目后，我发现几个问题：
-
1、开发环境下主应用访问不到子应用，即使网上有很多方案，但始终还是做不到 js 沙箱和 css 样式绝对隔离
-
2、微应用切换时依然是加载所有资源，并不会比刷新页面加载的资源少
既然加载的资源不会比刷新页面少，那么我们可不可以直接刷新页面呢？只要首屏资源足够轻量，响应速度足够快，同样可以达到无感切换。我参与过不少用 webpack 搭建的 qiankun 项目，几乎所有项目都是主应用加载菜单，子应用业务内容在右侧主体区域显示的模式。那么换个思路，所以业务应用都优先加载菜单，通过本地缓存记录菜单数据、状态甚至滚动位置，是否就可以达到无感刷新切换应用的效果？而用这种传统的刷新页面方式根本不用考虑 js 、css 被其它应用污染的问题。
对比
| 方案 | 乾坤 | 万象 |
|---|---|---|
| 运行方式 | 拦截子应用代码，经过转换再挂载到主应用 | 没有主子应用之分，只有简单的加载公共菜单 |
| 沙箱隔离 | 支持 js、css 沙隔离，但 js 通过 with 限制作用域，css 通过自动添加前缀，转换过程中有性能损耗 | 天然隔离，无须各种转换，切换应用直接刷新页面，不存在性能损耗 |
| 子应用 | 支持 | 不支持 |
| 更新部署 | 只有主应用更新时，无须更新子应用 | 公共菜单更新时，需要更新所有应用 |
| 复杂度 | 主子应用使用相同技术栈比较容易上手，使用不同技术栈样式隔离比较头疼 | 为了保障菜单加载速度，达到无感刷新效果，使用纯原生技术开发，对维护菜单的开发者技术要求较高 |
| 掌控度 | 遇到bug需要向社区反馈，等待解决方案，自行修改源码难度较高 | 整体就一个菜单组件的代码量，完全可以自行修改源码 |
| 成熟度 | 蚂蚁内部服务了超过 2000+ 线上应用 | 新鲜出炉，还没遇到什么坑，理论上应该没什么坑 |
目录结构
--/
|-- common/ # 公共组件模块
|-- wanxiang/
|-- app1/ # 应用1，独立仓库
|-- package.json
|-- app2/ # 应用2，独立仓库
|-- package.json
|-- package.json
|-- .gitignore # 忽略掉 app1 和 app2
如上图目录结构，有3个git仓库，一个公共的，一个 app1，一个 app2
app1 和 app2 都可以通过配置依赖路径别名加载 common 的资源，朴素无华，没有花里胡哨的模块联邦。
多仓库模式能有效解决开发团队的权限问题，同时避免了 git 历史记录洪流。
开始
<!-- index.html -->
<head></head>
<body>
<div id="app"></div>
<!-- 将 main.js 替换为 entry.js -->
<script src="entry.js"></script>
</body>
// enrty.js
import { start, setMenus } from 'common/wanxiang/index.js'
start(`#app`, () => {
// 关键点，显示完主体菜单再加载业务代码
import('./main.js')
// 加载菜单数据
fetch('/menu').then(res => res.json()).then(res => {
setMenus(res.data)
})
})
后语
万象不是框架也不是插件，是一种方案，一种管理大规模前端应用的方案，没有具体的标准，根据各自项目需求对公共菜单进行调整，因此每个项目都会有不同的表象，遂取名为“万象”。
