记一次微前端技术选型
项目背景:
- app下架需要把所有页面都迁移到企业微信h5
- 规划架构:主应用提供菜单组件和公用方法,然后微应用需要渲染到指定的容器。所以要求微前端框架提供隔离样式的功能、以及通讯功能。
- 只给了一个月来接入主应用和子应用。子应用需要推动各部门来配合接入,月初提需求,月底上线第一批应用
- 基于时间紧迫,需要挑选可用,且接入成本低,社区活跃度高,遇到问题可以找到对应的解决方案的微前端框架
- 维度与评分
- 成本
接入成本
(接入微前端框架要改动的东西)改造成本
(基于这个微前端框架不支持的功能,需要自己实现的难度评估)
- 收益
微前端运行时功能完整性
微前端工程化
微前端运维
- 风险
社区活跃度
(github star数量、已解决issue数量)可维护性
(文档是否齐全、在技术社区是否可以找到对应的技术分享文章)可扩展性
(随着越来越多的微应用接入,是否会导致管理上的不便)
- 成本
- 刷新后iframe的url状态丢失,无法控制iframe页面的前进后退;
- 想实现子应用免登录需要跨域共享cookie,反而导致安全性降低;
- 全局弹窗无法实现
- 企业微信h5的iframe不支持跨域请求页面,详见这里
微前端运行时功能完整性
不能满足基本业务需求,直接放弃该方案。single-spa 功能上:
- 兼容多框架
- html entry
- 加载和渲染原理:路由劫持,下载入口html,渲染到目标容器
- 不支持js隔离、样式隔离
- 不支持应用间通讯
- 不支持预加载
- 没有考虑微前端工程化和运维
接入成本:
- 子应用需要安装依赖,以及注册生命周期函数
- 主应用需要自己编写加载子应用的逻辑
- 需要自己实现js隔离、样式隔离
- 需要自己实现预加载
- 需要自己实现应用间通讯
- 社区活跃度 github star数量
11.3k
、已解决issue数量532
(2022.6.27) - 文档齐全,demo多
- 功能上,只做了路由劫持、提供参数填写加载微应用的逻辑。需要自己实现应用隔离、预加载和应用间通讯。
微前端运行时功能完整性
低,得1分。没有考虑微前端工程化
和微前端运维
相关的功能。所以在收益这个维度,得分1/9
- 成本上,接入需要自己手写加载微应用的逻辑,且子应用需要额外安装依赖,接入成本高,得1分。需要自己实现应用隔离、通讯、以及预加载等,改造成本高,得1分。所以在成本这个维度得分
2/6
。 - 社区活跃度高,可维护性高;
- 基于single-spa完善以下功能:
a. 应用隔离
- js沙箱,根据Proxy的支持度以及是否多例,支持三种沙箱实现方式
- 样式隔离:支持shadow dom方案,以及实验式样式隔离
- 全局方法(setInterval、clearInterval、addEventListener、removeEventListener)劫持
c. 基于props来实现父子通讯
- 没有考虑工程化问题:如公用依赖,组件复用
- 没有考虑到微前端平台运维
- 接入成本:子应用需要接入生命周期代码;主应用需要接入注册微应用代码;
- 改造成本:需要自己考虑微前端工程化问题,以及微前端平台运维。
- 社区活跃度:github star 数量 12.8k (统计时间20220622)
- 文档齐全,demo多
功能上:
- 考虑了微前端的工程化问题,基于webapck5 MF功能解决公共依赖的问题,以及可以实现微组件共享。
- 不支持样式隔离和js隔离
- 它的设计是去中心化,每个子应用都可以再接入子应用,
接入成本:
- 所有应用都要迁移到webpack5
- monorepo组织几个代码仓库
- 基于webpack5 MF实现公共依赖和组件共享,需要另外做基建来统一引入这些包的入口。还有公建文档的问题。
- 微组件共享是基于vuera这个库来实现的,只支持vue和react的组建共享
- 需要自己实现应用隔离
- 社区活跃度:社区活跃度不高 star 1.8k (统计时间20220622)
- 文档不完善
emp比较适合大型且处于立项初期时选用。需要事前做monorepo的规划、样式统一规划。
microapp
功能上:
- 抛弃了路由劫持的思路,选用类web component的方案
- 基于CustomElement和样式隔离、js隔离来实现微应用的加载,所以子应用无需改动就可以接入
- 支持应用隔离
- 通过劫持底层接口实现了元素隔离
- 提供了插件系统
- 支持预加载
- 没有考虑工程化问题:如公用依赖,组件复用
- 没有考虑到微前端平台运维
接入成本:子应用无需改动,主应用需要接入微应用代码
改造成本:需要自己考虑微前端工程化问题,以及微前端平台运维。
风险:
- 这个框架基于CustomElement和Proxy API,前者针对低版本有polyfill,但后者没有,且目前官方文档说没有做兼容的计划
- 社区活跃度 star 2.7k(统计时间20220622)
- 文档齐全
iframe
、single-spa
在功能完善度上不足,所以放弃选择;emp
比较适合在项目初期选型使用,用约定来规避样式隔离和js隔离(所以 emp
没有把应用隔离考虑进去),比较适合在大型项目中使用;microapp
和qiankun
,功能完整度上比较好,尽管 microapp
比 qiankun
多了元素隔离功能、插件系统,且使用了类web component的思路降低子应用的接入成本。但基于 microapp
对 Proxy目前不考虑兼容,且社区活跃度上,qiankun
更胜一筹,工期短需要有一定的保障,所以最后选了qiankun
参考资料:
【记一次微前端技术选型】https://github.com/micro-zoe/...
https://github.com/efoxTeam/e...
https://juejin.cn/post/684668...
https://github.com/efoxTeam/e...
推荐阅读
- Redis|Redis 笔记 01(入门篇)
- 入一行,先别惦记能赚多少钱,先学着让自己值钱
- 数模学习|【数学建模学习笔记【集训十天】之第六天】
- 数模学习|【数学建模学习笔记【集训十天】之第五天】
- 该长的记性还是要长的
- 美国记忆专家TED演讲|美国记忆专家TED演讲 | 过目不忘的“记忆宫殿”,你也可以拥有 | 右脑开发课堂学员观后感
- 读书笔记
- 682.|682. 棒球比赛
- 亲子日记97天
- 营销特训营第10天成长日记