qiankun微前端框架处理

https://blog.csdn.net/qq_41694291/article/details/113842872

答题分为以下几点

• 什么是微前端，为什么要用（解决什么问题）
• 优势
• 常见的微前端方案有哪些
• 我们用的是哪个微前端方案
• qiankun与single-spa相比好在什么地方

什么是微前端，为什么要用（解决什么问题）

概念：微前端的概念借鉴于后端的微服务，一般以业务功能为拆分单元
解决问题：大型项目的变更、扩展、维护困难的问题

优势

• 技术兼容性好、子应用可以基于不同的技术框架
• 拆分后体积变小，代码内聚性更强，每个子应用只是一个业务模块
• 能够独立开发、编译、部署
• 耦合性低，可独自开发，互不干扰
• 可维护和扩展性好，可专门升级某一个功能

缺点

总体积变大，插件可上传cdn，但公共函数资源不便于共享

常见的微前端方案有哪些

iframe：隔离性和兼容性好，性能和使用感差（性能差因为不会有缓存，每次重新加载）
基座模式：基于路由分发，由基座监听路由变化，加载不同的应用，实现应用解耦，single-spa、qiankun
组合式集成：组件单独打包发布，类似于npm包
EMP：主要基于Webpack5 Module Federation
web components：

为什么不用iframe

iframe 最大的特性就是提供了浏览器原生的硬隔离方案，不论是样式隔离、js 隔离这类问题统统都能被完美解决。但他的最大问题也在于他的隔离性无法被突破，导致应用间上下文无法被共享，随之带来的开发体验、产品体验的问题。

1. url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
2. UI 不同步，DOM 结构不共享。想象一下屏幕右下角 1/4 的 iframe 里来一个带遮罩层的弹框，同时我们要求这个弹框要浏览器居中显示，还要浏览器 resize 时自动居中..
3. 全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。
4. 慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程。

我们用的是哪个微前端方案

我们采用的是qiankun，主要思路是将一个大应用，拆分为更小的、可独立开发、测试、部署的子应用。

传统的大型项目：所有模块都在一个应用里，由应用本身负责路由管理，属于应用分发路由方式
拆分微应用的项目：属于基座模式下的系统架构，各应用互相独立，单独运行在不同的服务上，基座（基座一般是用户最终访问的应用）根据路由去加载不同的应用到页面上，即路由分发应用方式

qiankun与single-spa对比

微前端主要需要解决的问题有两个

• 应用加载与切换

• 应用隔离与通信

  
  
  image.png

qiankun和single-spa对比

image.png

activePath与当前的hash对比一致