前端搭建低代码平台，微前端如何选型？

背景

1.首先我们可以先来想一下，日常工作中我们是如何进行代码复用的？

• 复制粘贴 Ctrl cv
• 抽离封装模块
• 打npm包

2.但是，以上方法，会存在哪些问题呢？

--复制粘贴

• 增加重复的代码
• 复用代码逻辑发生变动时需要处处修改
• 违反 Don’t Repeat Yourself 原则

--抽离封装模块

• 仅适用于当前项目，无法兼容多个项目要使用同一个模块的情景

--打npm包或库

• 还蛮通用的…但是也有其他问题：
• 发布效率低下
• 当迭代npm包内的逻辑业务：发布npm包 -> 告诉其他使用的伙伴更新npm ->再各自构建发布一次 (繁琐极了)

于是微前端诞生了，用来将大型项目进行拆分和解耦。

一、微前端是什么？

微前端概念是从微服务概念扩展而来的，摒弃大型单体方式，将前端整体分解为小而简单的块。这些块可以独立开发、测试和部署，同时仍然聚合为一个产品出现在客户面前。

微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用后，随之而来产生的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见。

二、三大特性

• 无技术栈限制
• 应用单独开发、测试和部署、交付
• 多应用整合

三、现有微前端解决方案

1、iframe

iframe是html提供的标签，能加载其他web应用的内容，并且能兼容所有的浏览器。

不足：

• 不是单页应用，会导致浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
• 弹框类的功能无法应用到整个大应用中，只能在对应的窗口内展示。 由于可能应用间不是在相同的域内，主应用的 cookie，要透传到根域名都不同的子应用中才能实现免登录效果。
• 每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程，占用大量资源的同时也在极大地消耗资源。

经过以上思考，拓展总结： iframe的特性导致搜索引擎无法获取到其中的内容，进而无法实现应用的seo。

2、Web Components

Web Component 是一套不同的技术，允许你创建可重用的定制元素（它们的功能封装在你的代码之外），并且在你的 web 应用中使用它们。Web Component包括Custom Element、Shadow DOM、HTML templates 三种技术规范。

点击查看MDM对它的定义

Web Component具备微前端的几个特性：

1. 技术栈无关：Web Components是浏览器原生组件，在任何框架中都可以使用。
2. 样式隔离：使用 Shadow DOM 可以实现样式的完全隔离，防止不同组件之间的样式冲突。
3. 可重用性：创建的 Web Component 可以在多个项目中重复使用，提高了代码的复用率。

不足：

1. 对于不熟悉 Web Components 的开发者来说，学习和使用这些 API 可能有一定的学习曲线，需要理解 Shadow DOM、Custom Elements 和 HTML Templates 等概念。
2. 缺少生态和社区支持，社区支持和文档资源相对较少，解决问题和获取帮助不如其他框架方便。

3、ESM

ESM是ES Module的缩写，是Ecma script 2015中提出的一种前端模块化手段

也是符合以下几点：

1. 无技术栈限制：ESM加载的只是js内容，无论哪个框架，最终都要编译成js。因此，无论哪种框架，ESM都能加载。
2. 应用单独开发：ESM只是js的一种规范，不会影响应用的开发模式。
3. 多应用整合：只要将微应用以ESM的方式暴露出来，就能正常加载。
4. 远程加载模块: ESM能够直接请求cdn资源，这是它与生俱来的能力。

不足：兼容性问题

4、EMP

EMP是由欢聚时代业务中台自主研发的最年轻的单页微前端解决方案，除了具备微前端的能力外，还实现了跨应用状态共享、跨框架组件调用的能力。

具备以下几大特点：

• 每个微应用独立部署运行 跨技术栈组件式调用。
• 应用间通信，每一个应用都可以进行状态共享，就像在使用npm模块进行开发一样便捷。
• 每个微应用独立部署运行。

不足：EMP的社区支持和文档可能不如其他成熟的微前端框架丰富。虽然EMP支持跨技术栈组件调用，但它主要基于Vue.js和Element UI。如果项目中需要使用其他框架或库，可能会遇到兼容性问题。

5、Fronts

Fronts 是一个基于 Webpack 的 Module Federation API 设计的渐进式微前端框架。它强调颗粒间的去中心化依赖管理，并支持多种运行模式来满足不同的微前端架构需求。

• 支持非 Module Federation - 虽然 Fronts 基于 Module Federation 概念，但它依然支持任何传统且不支持 Module Federation 的前端应用。
• 去中心化配置 - 只需要在每个 Fronts 应用中设置 site.json，就像设置一个 package.json 一样简单，Fronts 支持多层嵌套的微前端。
• 跨框架 - 没有任何现代前端框架限定。
• 代码分割/懒加载 - 支持在 Fronts 应用内进行代码拆分和导出共享模块，它可以被其他 Fronts 应用作为依赖模块进行懒加载。
• CSS 隔离 - 可选的 CSS 隔离设定，并根据不同的渲染方式，有宽松隔离和严格隔离的可选项。
• 生命周期 - 每个 Fronts 应用的 Entry 支持简洁的生命周期接口。
• Web Components 和 iFrame - 支持多种前端运行时容器用于不同隔离环境的要求。
• 多种构建模式 - 同时支持在微前端模式和非微前端模式构建，兼容动态化的运行时集成和静态化的构建时集成。
• Monorepo 和 TypeScript - 良好支持 Monorepo 和 TypeScript，它们和 Fronts 是非常适合架构在一起的技术栈。
• 版本控制 - Fronts 提供的版本控制可用于高效和动态的即时交付应用，当然也包括支持灰度发布。
• 零劫持 - Fronts 不做任何执行容器上的环境全局公共 API 劫持，保持运行环境的原始性，避免可能带来的性能损失和安全问题。
• 通用化消息通讯 - Fronts 提供简洁通用的响应式 API，它支持前端绝大部分原生 API。

不足：学习曲线较陡峭、构建时间可能较长。

6、无界（文档）

基于 webcomponent 容器 + iframe 沙箱，能够完善的解决适配成本、样式隔离、运行性能、页面白屏、子应用通信、子应用保活、多应用激活、vite 框架支持、应用共享等用户的核心诉求。

1.成本低：无界微前端的成本非常低，主要体现在主应用的使用成本、子应用的适配成本两个方面。

• 主应用使用成本低：主应用使用无界不需要学习额外的知识，无界提供基于 vue 封装的 wujie-vue 和基于 react 封装的 wujie-react，用户可以当成普通组件一样加载子应用。
• 子应用适配成本低：当运行的方式是重建模式时，子应用可以不做任何改造就在无界框架中运行，其他模式需要适当的做一些生命周期改造工作。

2.速度快：无界微前端非常快，主要体现在首屏打开快、运行速度快两个方面

3.原生隔离：无界微前端实现了 css 沙箱和 js 沙箱的原生隔离，子应用不用担心污染问题。

4.功能强大：无界微前端的功能非常强大，支持子应用保活、子应用内嵌、多应用激活、去中心化通信、生命周期、插件系统、vite 框架支持、兼容 IE9、应用共享。

不足：iframe沙箱可能带来性能开销和通信复杂性，生命周期管理在复杂环境中可能变得更复杂。

7、qiankun

在微前端界，qiankun算得上是最早成型且知名度最广的框架了，它是真正意义上的单页微前端框架

具备以下几大特点：

1. 基于single-spa封装，提供了更加开箱即用的 API。
2. 技术栈无关，任意技术栈的应用均可使用/接入，不论是 React/Vue/Angular/JQuery 还是其他的框架。
3. HTML Entry 接入方式，让你接入微应用像使用 iframe 一样简单。
4. 样式隔离，确保微应用之间样式互相不干扰。
5. JS 沙箱，确保微应用之间全局变量/事件不冲突。
6. 资源预加载，在浏览器空闲时间预加载未打开的微应用资源，加速微应用打开速度。
7. umi 插件，提供了 @umijs/plugin-qiankun 供 umi 应用一键切换成微前端架构系统。
8. 活跃的社区/文档支持。

不足：qiankun是基于single-spa封装的，因此它的功能和限制也受到single-spa的影响。虽然提供了开箱即用的API，但对于复杂的微前端架构，配置和管理可能会变得复杂。

四、我们选择的方案

结合公司产品和现有项目的技术框架（vue2），我们采取的是qianku方案，首先我们的路由模式是hash模式，要将hash改成history。

为什么我们要把原本的hash改成history？

qiankun接入外部服务时，父容器需要适应路由方式history（当前开发平台为hash，即/#/）

-- hash路由：子应用也必须是hash路由，且需继承主应用的基础路径。

-- history路由：主应用如果是history，则子应用可以是history也可以是hash。

如何将路由从****hash改成history？这个会再出一篇文章详细讲解，敬请期待。

引入qiankun并使用（src外层作为主应用）

1.安装qiankun依赖

yarn add qiankun # 或者 npm i qiankun -S

主应用使用qiankun

a.承载微应用（我们选择了创建容器的方式，可以根据实际情况来传递一些参数给微应用）

<template><div class="info"><div @click="changeChildState">改变子路由状态(测试)</div><!-- 目标容器 --><div id="subapp-viewport"></div></div></template><script>import { registerMicroApps, start, initGlobalState }from 'qiankun'export default{// 对应微应用的name  name: 'apply-manage',data(){return{// 全局状态      actions:null}},mounted(){// 传递给微应用的值const initialState ={      router: '/test'}// 初始化全局状态（可选）this.actions =initGlobalState(initialState)// 注册微应用registerMicroApps([{// 微应用名字，需要和微应用的package.json的name一致/微应用全局导出的name一致        name: 'apply-manage',// 微应用入口// 1、内部子模块直接指向对应的入口，到时候需要区分生产/本地// 2、外部应用直接指向其入口        entry: 'http://localhost:8081/apply',// 触发加载微应用的路由        activeRule: '/temApply',// 容器id        container: '#subapp-viewport',// 子应用挂载的div,// 可选，需要传递给微应用的参数        props:{          test1: 'testtt'}}],{// 下面是微应用加载时候的一些钩子函数      beforeLoad: app =>{        console.log('before load app.name====>>', app.name)},beforeMount:[        app =>{          console.log('[LifeCycle] before mount %c%s', 'color: green;', app.name)}],afterMount:[        app =>{          console.log('[LifeCycle] after mount %c%s', 'color: green;', app.name)}],afterUnmount:[        app =>{          console.log('[LifeCycle] after unmount %c%s', 'color: green;', app.name)}]})// 改变传递给微应用时候会触发的函数this.actions.onGlobalStateChange((newState, prev)=>{// state: 变更后的状态; prev 变更前的状态      console.log('main change', JSON.stringify(newState), JSON.stringify(prev))})// 启动 qiankunstart({// 沙箱隔离      sandbox:true,// 可选，有第三方js引入时使用      excludeAssetFilter: assetUrl =>{// 白名单协议：子应用下如需要放行动态加载的css/js资源，可以在链接上带上参数 _custom-exclude_=MAINconst whiteWords =['_custom-exclude_=MAIN']return whiteWords.some(w =>{return assetUrl.includes(w)})}})},methods:{// 测试改变全局状态changeChildState(){// 按一级属性设置全局状态，微应用中只能修改已存在的一级属性，会同步到微应用this.actions.setGlobalState({        router: 'routerNameMap[name]'})}},beforeDestroy(){// 移除当前应用的状态监听，微应用 umount 时会默认调用this.actions.offGlobalStateChange()}}</script><style lang="less" scoped></style>

b.设置容器对应的路由

路由后面的(.*)*需要携带，不然会微应用子路由会出现404

微应用工程要做什么

c.引入public-path.js

• public-path.js

/* eslint-disable camelcase */if(window.__POWERED_BY_QIANKUN__){  __webpack_public_path__ = window.__INJECTED_PUBLIC_PATH_BY_QIANKUN__}

• main.js

// 第一行import './public-path'xxxx

d.导出相应的生命周期钩子

main.js

// 第一行import './public-path'let instance =nullfunctionrender(props){// 作为独立项目if(!props){/* eslint-disable no-new */newVue({      router,      store,render: h =>h(App)}).$mount('#app')return}// 作为微应用时const{ container, usePicker }=props  instance =newVue({    router,    store,data(){return{        usePicker}},render: h =>h(App)}).$mount(container ? container.querySelector('#app'): '#app')// if (props.router) {//   router.push({//     name: props.router//   })// }}// 独立运行时if(!window.__POWERED_BY_QIANKUN__){render()}(global=>{// apply-manage跟主应用加载微应用时候的name一致global['apply-manage']={    bootstrap:()=>{return Promise.resolve()},mount:(props)=>{// 全局状态更改时候触发      props.onGlobalStateChange(state =>{// setTimeout(() => {// router.push({//   name: state.router// })// }, 500)},true)returnrender(props)},unmount:()=>{      instance.$destroy()return Promise.resolve()}}})(window)

e.如果是history模式的话，要设置routerbase为主应用那边的触发路由

主应用容器

微应用

f.需要区分好独立运行和作为微应用运行时候的各项功能配置

例子：独立运行要登录，作为微应用时候直接获取主应用的登录状态等等

主应用&微应用通讯

g.思路

主应用采用原生方式实现订阅机制（以下称为eventBus），并挂载在window上，使主&子应用共用一份eventBus机制。

h.实现

这个会再出一篇文章详细讲解，敬请期待。

FAQ

官网常见文集文档：常见问题 - qiankun

1.使用第三方链接报跨域

· 解决方案：手动加载

2.父子组件中加载两个monaco编辑器，其中实例放在data中会页面卡死

· 方案：将editor属性从data移除

3.主应用&微应用通讯规范

五、总结

对于低代码平台，推荐优先考虑 qiankun，因为它提供了技术栈无关性、样式隔离、JS沙箱、跨应用通信、性能优化以及活跃的社区支持。这些特性使得qiankun非常适合需要支持多种技术栈和高度可扩展性的低代码平台。

如果你的项目需要更细粒度的控制和更复杂的配置，可以考虑 fronts，它提供了更多的灵活性和高级功能，但需要更多的配置和学习成本。

如果你特别关注低成本和快速集成，并且对iframe沙箱带来的限制能够接受，那么 无界 也是一个不错的选择。

最终的选择应该基于你的具体需求、团队的技术栈和经验，以及项目的长期发展规划。

点点关注，下期精彩继续！

道一云七巧-与你在技术领域共同成长

更多技术知识分享：https://bbs.qiqiao668.com/