美文网首页
2023年了铁汁,难道你还不会微前端吗?

2023年了铁汁,难道你还不会微前端吗?

作者: Nicholas_liang | 来源:发表于2023-01-09 10:38 被阅读0次

    今天就聊一聊微前端,一起学习进步。

    微前端就是可以一个主项目跑多个子项目【 vue、react 甚至 jquery 等不同项目】,它们之间的 JS、CSS 相互隔离运行,不会相互影响,但也有通信机制可以通信。

    那么微前端到底是怎么实现的呢?

    其实它是这样的:当路由切换的时候,去下载对应应用的代码,然后跑在el【容器】里。

    目前比较主流的微前端框架有几个:

    阿里的乾坤 qiankun.umijs.org/zh/cookbook

    腾讯的无界 wujie-micro.github.io/doc/

    京东的 https://zeroing.jd.com/micro-app/docs.html#/

    single_spa single-spa.js.org/

    下面我们看看主流框架的各自优缺点:

    1、qiankun

    qiankun 方案是基于 single-spa 的微前端方案

    特点

    html entry 的方式引入子应用,相比 js entry 极大的降低了应用改造的成本;

    完备的沙箱方案,js 沙箱做了 SnapshotSandbox、LegacySandbox、ProxySandbox 三套渐进增强方案,css 沙箱做了 strictStyleIsolation、experimentalStyleIsolation 两套适用不同场景的方案;

    做了静态资源预加载能力;

    缺点

    适配成本比较高,工程化、生命周期、静态资源路径、路由等都要做一系列的适配工作;

    css 沙箱采用严格隔离会有各种问题,js 沙箱在某些场景下执行性能下降严重;

    无法同时激活多个子应用,也不支持子应用保活; 无法支持 vite 等 esmodule 脚本运行;

    2、micro-app

    micro-app 是基于 webcomponent + qiankun sandbox 的微前端方案。

    特点

    借鉴了WebComponent的思想,通过CustomElement结合自定义的ShadowDom,将微前端封装成一个类WebComponent组件,从而实现微前端的组件化渲染。

    并且由于自定义ShadowDom的隔离特性,micro-app不需要像single-spa和qiankun一样要求子应用修改渲染逻辑并暴露出方法,也不需要修改webpack配置,是目前市面上接入微前端成本最低的方案

    缺点

    css 沙箱依然无法绝对的隔离,js 沙箱做全局变量查找缓存,性能有所优化;

    支持 vite 运行,但必须使用 plugin 改造子应用,且 js 代码没办法做沙箱隔离;

    对于不支持 webcompnent 的浏览器没有做降级处理;

    3、无界

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

    特点

    子应用的加载和卸载能力【页面需要从一个子应用切换到另一个子应用,框架必须具备加载、渲染、切换的能力】

    子应用独立运行的能力【子应用运行会污染全局的 window 对象,样式会污染其他应用,必须有效的隔离起来】

    子应用路由状态保持能力【激活子应用后,浏览器刷新、前进、后退子应用的路由都应该可以正常工作】

    应用间通信的能力【应用间可以方便、快捷的通信】

    优势

    多应用同时激活在线

    框架具备同时激活多应用,并保持这些应用路由同步的能力

    组件式的使用方式

    无需注册,更无需路由适配,在组件内使用,跟随组件装载、卸载

    应用级别的 keep-alive

    子应用开启保活模式后,应用发生切换时整个子应用的状态可以保存下来不丢失,结合预执行模式可以获得类似ssr的打开体验

    纯净无污染

    无界利用iframewebcomponent来搭建天然的js隔离沙箱和css隔离沙箱

    利用iframehistory和主应用的history在同一个top-level browsing context来搭建天然的路由同步机制

    副作用局限在沙箱内部,子应用切换无需任何清理工作,没有额外的切换成本

    性能和体积兼具

    子应用执行性能和原生一致,子应用实例instance运行在iframewindow上下文中,避免with(proxyWindow){code}这样指定代码执行上下文导致的性能下降,但是多了实例化iframe的一次性的开销,可以通过proload提前实例化

    体积比较轻量,借助iframewebcomponent来实现沙箱,有效的减小了代码量

    开箱即用不管是样式的兼容、路由的处理、弹窗的处理、热更新的加载,子应用完成接入即可开箱即用无需额外处理,应用接入成本也极低

    缺点

    基于路由匹配,无法同时激活多个子应用,也不支持子应用保活

    改造成本较大,从 webpack、代码、路由等等都要做一系列的适配

    css 沙箱无法绝对的隔离,js 沙箱在某些场景下执行性能下降严重

    无法支持 vite 等 ESM 脚本运行

    个人认为无界还是很强大的。

    无界使用

    1、安装 推荐使用vue3版本

    npm i wujie-vue3 -S

    2、引入

    无界

    import WujieVue from "wujie-vue3";

    app.use(WujieVue)

    micro-app

    $ npm i @micro-zoe/micro-app --save

    import microApp from '@micro-zoe/micro-app'        

    microApp.start()

    3、使用

    首先配置路由

    不同的路由对应不同的微前端引入方式

    path: /project4对应:

    <WujieVue width="100%" height="80vh" name="App" :url="url" :sync="true"></WujieVue>

    path: /project2对应:

    <micro-app class="pone-wrap" name='App2' url='url' baseroute='/project2'></micro-app>    

    点击跳转到对应的微前端引入的路由,并加载对应的url内容,Wujie加载速度比Micro-app肉眼可见的快。

    相关文章

      网友评论

          本文标题:2023年了铁汁,难道你还不会微前端吗?

          本文链接:https://www.haomeiwen.com/subject/zkppcdtx.html