基于qiankun的微前端渐进式升级

摘要

• 技术框架老旧，依赖也较多较老，且很多已经停止维护；
  
  
• 功能耦合，代码逻辑复杂，一个小的改动，可能影响很多功能；
• 代码冗余，存在着许多冗余代码，组件化开发困难，代码复用困难；
• 新需求不断，开发效率越来越低，开发体验较差。

  
  

• 项目功能较多，全量升级时间较长；
• 新需求不断，边重构边迭代，会有重复开发问题；
• 回归测试成本高，风险高；
• 团队开发人力有限。
  
  

2.1技术选型

• iframe，这个是大家比较熟悉的，甚至在微前端概念出现之前大家就在用的方案， iframe不是单页应用；

  
  
• 还有一类是自己实现了微前端功能的框架，比如比较成熟的single-spa，有的基于single-s

  ‍‍‍‍‍

  pa，或者类似于single-spa的，我统一把他们叫作

  类single-spa方案；
• Webpack5 Module Federation 可以把多个无单独依赖的、单独部署的应用合为一个，或者可以更细粒度的，打包一个小的微模块，来实现更细粒度的微前端；
• ESM是ES Module的缩写

  ，是ECMAScript 2015中提出的一种前端模块化手段；
• Web Components是由google推出的包括浏览器原生组件Custom Element、Shadow DOM、HTML templates三种技术规范。
  
  

• qiankun是基于single-spa的，原项目是AngularJs的框架，single-spa提供了一套single-spa-angularjs的中

  间件；
• qiankun基于import-html-entry实现了HTML Entry，可以直接将原项目的HTML文件作为子应用的接入入口；
• qiankun实现了single-spa没有实现的js沙箱和css隔离。

2.3接入步骤

• 注册子应用，引入子应用生命周期
• 获取菜单权限，将未重构的页面统一增加/ng路由前缀
• 通过路由前缀（/ng）来调用挂载子应用
  
  

• 引入single-spa-angularjs中间件库，导出相应的生命周期钩子
• window.__POWERED_BY_QIANKUN__判断是否是为qiankun子应用，设置路由前缀，控制菜单、水印等渲染，非登录状态跳转主应用登录页
  
  

  ‍

2.4问题解决

• 新增功能页面直接在主应用内实现，可以直接通过主应用的路由直接访问到不用做处理；
• 已重构的功能页面，通过一个UrlMap的来配置化管理，转换成已重构的主应用的路由地址，然后主应用访问到已重构的功能页面;
• 将未重构的页面统一增加/subApp前缀，当点击URL前缀为/subApp时，qiankun会将子应用挂载到指定ID为subapp-viewport的container 中，同时依次调用子应用暴露出的生命周期钩子；在子应用被挂载的时候，可以通过window.__POWERED_BY_QIANKUN__来判断，不进行渲染原项目的导航，并统一给路由增加/subApp的前缀，这样在子应用的路由就可以加载到为重构的子应用页面。通过qiankun提供的应用间通信方法，主应用通知子应用当前要访问的子应用路由地址，来保证子应用页面能够正确加载。
  
  

  
  

• 增量升级，快速接入新框架，开发新的功能，避免全量重构重复开发问题；
• 渐进式升级，可根据产品需求，灵活地对经常的迭代的功能模块进行升级重构；
• 低风险， 每次上线都是根据需求上线部分功能，降低了重构上线的风险；
• 低入侵，原项目仍可独立运行、开发、部署。