微前端方案对比
什么是微前端
微前端类似微服务,并不是指某一具体的技术,而是一种整合了技术、策略和方法的宏观架构方案,是一种将多个可独立交付的小型前端应用聚合为一个整体的架构风格。
为什么选择微前端
微前端主要解决了两个问题:
项目迭代导致巨石应用,难以维护
兼容历史应用,实现增量开发
优点:
更灵活的技术栈选择
拓展多个技术团队
更快且独立的部署
…
缺点:
- 用户层面,不连贯的体验问题
- 多项目、多语言造成的维护成本增加
Why Not Iframe
微前端框架选择
本次改造使用一下技术栈
基座应用vue2.x
子应用vue2.x
路由模式均为hash
一. qiankun
图片来源:https://blog.csdn.net/xgangzai/article/details/128489706
基座应用
- 手动加载(可手动,可自动,自动加载需要修改main.js入口文件)
1 | <!-- qiankun路由落地页面 --> |
- 路由改造
1 | // router.js |
子应用
- 改造入口文件,暴露生命周期
1 | // main.js |
- 新增
public-path.js
文件,并在main.js
引入
1 | if (window.__POWERED_BY_QIANKUN__) { |
- 改造路由
1 | // router.js |
- 改造
webpack
打包
1 | // vue.config.js |
优点:
- 社区活跃,框架经过多个项目打磨,更加成熟
- 社区demo多,案例多
- 完备的沙箱方案,js 沙箱做了
SnapshotSandbox
、LegacySandbox
、ProxySandbox
三套渐进增强方案,css 沙箱做了strictStyleIsolation
、experimentalStyleIsolation
两套适用不同场景的方案
缺点:
- 项目侵入性强,接入成本高
- 页面展示多个子应用时,需要使用
momery
路由 - 官方文档比较简洁,需要多去社区看demo
二. wujie
基座应用
- 改造入口文件,注入无界
1 | // main.js |
- 新建无界页面,路由跳这里
1 | <template> |
子应用
- 改造入口文件
1 | // main.js |
优点:
- 改造成本低,有基于vue的
wujie-vue
和react的wujie-react
封装,开箱即用 - 子应用加载和普通 vue 组件加载并无二致,所有配置都收敛到组件的属性上。
webcomponent
+shadowdom
、js-iframe原生沙箱- 支持
plugin
- 子应用保活
- 更方便的全局组件挂载
- 浏览器降级处理
缺点:
- 社区不如qiankun和micro-app活跃
三、micro-app
基座应用
- 基座应用改造侵入性小
1 | // 安装 |
- 分配路由
1 | // router.js |
- 页面中使用,数据通信,生命周期
1 | <!-- my-page.vue --> |
子应用
- 子应用改造
1 | // main.js |
- 路由改造
1 | // router.js |
路由约束:
- 基座是hash路由,子应用也必须是hash路由
- 基座是history路由,子应用可以是hash或history路由
基础路由:
如果基座是history路由,子应用是hash路由,不需要设置基础路由baseroute
如果子应用只有一个页面,没有使用
react-router
,vue-router
之类,也不需要设置基础路由baseroutevue-router
在hash模式下无法通过base设置基础路由,需要创建一个空的路由页面,将其它路由作为它的children
Proxy
代理保证window
的纯净,因Proxy
没有更好的polyfill
方案,所以不支持Proxy
的浏览器(IE、低版本iOS等)无法运行micro-app
优点:
- 改造成本对比qiankun有所降低
- 简单的子应用(无路由跳转等)开箱即用
- 支持
plugin
webcomponet
、js沙箱、ShadowDom
等- 子应用保活
- 文档详细、完善,官方手把手demo教学,社区相对活跃
缺点:
- 复杂子应用有改造成本,需要改造路由才可以正常使用
- 公用组件挂载麻烦,没有原生支持
- 低版本浏览器兼容问题(IE等不支持
Proxy
的浏览器)
四. garfish
五. 本地跨域解决方案
1 | // vue.config.js |