项目使用qiankun 改造的背景:
项目A、项目B、项目C;
项目A和项目B具有清晰的服务边界,从服务类型的角度能够分为两个项目。
在公司项目一体化的背景下,所有的项目又应该是一个项目。
项目B研发启动的时候
1. 由于开发时间紧张;
2. 项目B需要共用A项目中的“项目模块”和“人员管理”模块;
3. 项目B中的功能模块根据项目A的路由进行激活加载;
基于以上的情况,采取了在项目A中增加模块进行项目B的开发,
由于B项目包含在A项目中,当A项目和B项目同时开始需求迭代的时候,两个开发人员开始代码合并的时候简直就是灾难,需要花费大量的时间小心谨慎的进行这项工作。
为了不使项目A变为巨石应用,需要将A项目进行解构。
微前端架构旨在解决单体应用在一个相对长的时间跨度下,由于参与的人员、团队的增多、变迁,从一个普通应用演变成一个巨石应用(Frontend Monolith)后,随之而来的应用不可维护的问题。
提到微前端,第一个想到的肯定是iframe,iframe嵌入网页几乎没有什么改造成本。
我们的项目为什么不使用iframe?
iframe 是在主应用中嵌入子应用系统,iframe 为子应用提供了一个完美的隔离环境,完美的样式隔离和js 隔离。
iframe 所带来的问题:
1. iframe拥有独立的window 。独立的浏览器缓存(无法便捷的实现单点登陆。例如:主应用登陆后将token 存储在sessionStorage中,子应用无法直接拿到token。)
2. 每次子应用的进入都是一次浏览器上下文重建,资源重新加载的过程。
3. url 不同步,浏览器舒心,iframe url 状态丢失,后退、前进按钮无法使用。
为什么选用qiankun
1. 技术栈无关。
2. 主应用与微应用能够独立运行,独立开发。
3. 微应用与主应用之间做到了该隔离的隔离,不该隔离的共用。(浏览器缓存可共用)
当遇到像我们这种项目情况的时候:
主应用与微应用基地相同,意味着,两个项目的缓存操作方法相同,vuex store方法相同时,应该首选采取qiankun 接入微应用的方式。
由于qinkun 没有隔离浏览器缓存,因此,可以不用考虑子应用的登录问题,菜单栏tab 的显示问题。
简直比德芙还丝滑!!