|
概述 微前端概念来源于微服务，摒弃大型单体方式，将前端整体分解为小而简单的块，可以独立开发，测试和部署。同时能够聚合程一个应用呈现给用户。 解决的问题：- 工程越来越大
- 限制于一个技术栈
- 项目越大，打包，编译速度变慢。持续集成部署也越来越困难
微前端分类实现微前端，本质上就是在运行应用时加载应用。有以下几种方案 通过搭建基座、配置中心来管理子应用。例如基于single spa的qiankun 通过约定进行互调，但会遇到处理第三方依赖的问题。 脱离基座模式，每个应用之前可以彼此分享资源。例如webpack5的联邦模块（Module Federation） 相关技术基本能够完成微前端的需求，但是最大的问题在于隔离性无法突破，导致应用上下文无法被共享，带来开发体验，用户体验不佳的情况，具体如下
- 不是单页应用，会导致浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
- 弹框类的功能无法应用到整个大应用中，只能在对应的窗口内展示。
- 由于可能应用间不是在相同的域内，主应用的 cookie 要透传到根域名都不同的子应用中才能实现免登录效果。
- 每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程，占用大量资源的同时也在极大地消耗资源。
- iframe的特性导致搜索引擎无法获取到其中的内容，进而无法实现应用的seo
优点：
- 技术栈无关：Web Components是浏览器原生组件，那即是在任何框架中都可以使用。
- 独立开发：使用Web Components开发的应用无需与其他应用间产生任何关联。
- 应用间隔离： Shadow DOM的特性，各个引入的微应用间可以达到相互隔离的效果。
缺点就是兼容性不太好 优点：
- 无技术栈限制：ESM加载的只是js内容，无论哪个框架，最终都要编译成js
- 应用单独开发： ESM只是js的一种规范，不会影响应用的开发模式。
- 多应用整合： 只要将微应用以ESM的方式暴露出来，就能正常加载。
- 远程加载模块: ESM能够直接请求cdn资源，这是它与生俱来的能力。
缺点也是兼容性不太好
技术框架国外的项目，只做了两件事：加载微应用、维护微应用状态（初始化、挂载、卸载），只是解决了路由问题和应用入口 蚂蚁出品，基于single spa。 优点：
- 基于single-spa封装，提供了更加开箱即用的 API
- 技术栈无关，任意技术栈的应用均可 使用/接入
- HTML Entry 接入方式，接入微应用像使用 iframe 一样简单
- 样式隔离，确保微应用之间样式互相不干扰
- JS 沙箱，确保微应用之间 全局变量/事件 不冲突
- 资源预加载，在浏览器空闲时间预加载未打开的微应用资源，加速微应用打开速度
不足： 基于Webpack5的新特性Module Federation（模块联邦） 优点：
- 基于Webpack5的新特性Module Federation实现，达到第三方依赖共享，减少不必要的代码引入的目的
- 每个微应用独立部署运行，并通过cdn的方式引入主程序中，因此只需要部署一次，便可以提供给任何基于Module Federation的应用使用。并且此部分代码是远程引入，无需参与应用的打包。
- 动态更新微应用：EMP是通过cdn加载微应用，因此每个微应用中的代码有变动时，无需重新打包发布新的整合应用便能加载到最新的微应用。
- 去中心化，每个微应用间都可以引入其他的微应用，无中心应用的概念。
- 跨技术栈组件式调用，提供了在主应用框架中可以调用其他框架组件的能力
- 按需加载，开发者可以选择只加载微应用中需要的部分，而不是强制只能将整个应用全部加载。
- 应用间通信，每一个应用都可以进行状态共享，就像在使用npm模块进行开发一样便捷。
- 生成对应技术栈模板，它能像cerate-react-app一样，也能像create-vue-app一样，通过指令一键搭建好开发环境，减少开发者的负担。
- 远程拉取ts声明文件，emp-cli中内置了拉取远程应用中代码声明文件的能力，让使用ts开发的开发者不再为代码报错而烦恼。
EMP除了具备微前端的能力外，还实现了跨应用状态共享、跨框架组件调用的能力，这是现有框架所不具备的优秀特性！ 不足的地方也很明显：对 webpack 强依赖，老旧项目不友好； 腾讯出品，webcomponent 容器 + iframe 沙箱 优点：
| 
发表于 2024-3-19 14:17:54
发表于 2024-7-1 15:20:59