qiankun微前端(乾坤微前端原理)

本篇文章给大家谈谈qiankun微前端,以及乾坤微前端原理对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。

本文目录一览:

阿里 qiankun 微前端框架实践

qiankun ——— 一套完整的微前岁森巧端解决乎键方案:

如图所示,在qiankun框架中,有主程序与子程序。主程序会留出指定的DOM作为子程序的容器,并且通过主程序里的路由转发加载子应用。

修改主程序main.js注册子应用

修改主程App.vue注册子应用的容器

main.js

Demo: github.com/justworkhar…

与传统的父子组件通信一样,父程序通过props向子程序传递信春凳息。子程序通过回调函数向父程序传递信息。

qiankun框架说白了就是通过在主程中添加一个展示子程序的DOM,经过路由判断做转发加载子程序。

微前端——乾坤qiankun Demo

微前端就是将不同的功能按照橡源不同的维度拆分成多个子应用。通过主应用来加载这些子应用。微前端的核心在于拆,拆完后在合!

我们可以将一个应用划分成若干个子应用,将子应用打包成一个个的 lib 。当路径切换 时加载不同的子应用。这样每个子应用都梁坦态是独立的,技术栈也不用做限制了!从而解决了前端协同开发问题。

文档地址:

2018 年 Single-SPA 诞生了, single-spa 是一个用于前端微服务化的 JavaScript 前端解决方案 ( 本身没有处理样式隔离, js 执行隔离 ) 实现了路由劫持和应用加载。

2019 年 qiankun 基于 Single-SPA, 提供了更加开箱即用的 API ( single-spa + sandbox + import-html-entry ) 做到了,技术栈无关、并且接入简单(像 i frame 一样简单)。

这里我们打算建立三个项目进行实操,一个Vue项目充当主应用,另一个Vue和React应用充当子应用

基座:qiankun-base 子应用:qiankun-vue、qiankun-react

react + react-router 技术栈的主应用:只需要让子应用的 activeRule 包含主应用的这个路由即可。

vue + vue-router 技术栈的主应用:

用绝对路径,不用用相对路径,例如

qiankun 只能解决子项目之间的样式相互污染,不能解决子项目的样式污染主项目的样式

冲突的样式,采用BEM命名信孝方式

子应用,需要增加 update 钩子以便主应用手动更新微应用

主应用,直接调用子应用实例的 update 方法即可

[img]

微前端 -- 乾坤(一)

在 toB 的前端开发工作中,我们往往就会遇到如下困境:

基座模式

通过一个主应用,来管理其它应用。设计难度小,方便实践,但是通用度低。

自组织模式。应用之间是平等的,不存在相互管理的模式。设计难度大,不方便实施,但是通用度高。

就当前而言,基座模式实施起来比较方便,方案也岩裂橘是蛮多的。

注册表模式

和微服务架构相似,不论是哪种微前端方式,都需要有一个应用注册表的服务。这个应用注册表拥有每个应用及对应的入口,即路由。

它可以是一个固定值的配置文件,如 JSON 文件,又或者是一个可动态更新的配置,又或者是一种动态的服务。

作用:

应用注册。即提供新的微前端应用,向应用注册表注册功能。

应用发现。让主应用可以寻找到其它应用。

首先看一下它的用法:

微前端每个应用都拥有自己的生命周期:

bootstrap, 只会在微应用初始化的时候调用一次,粗团下次微应用重新进入时会直接调用 mount 钩子,不会再重复触发 bootstrap。 通常我们可以在这里做一些全局变量的初始化,比如不会在 unmount 阶段被销毁的应用级别的缓存等。

Mount,源明应用每次进入都会调用 mount 方法,通常我们在这里触发应用的渲染方法

Unload,删除应用的生命周期

Unmount,应用每次 切出/卸载 会调用的方法,通常在这里我们会卸载微应用的应用实例

乾坤,作为一款微前端领域的知名框架,其建立在single-spa基础上。相较于single-spa,乾坤做了两件重要的事情,其一是加载资源,第二是进行资源隔离。而资源隔离又分为Js资源隔离和css资源隔离.

每个微应用对全局的影响都会局限在微应用自己的作用域内。比如 A 应用在 window 上新增了个属性 test,这个属性只能在 A 应用自己的作用域通过 window.test 获取到,主应用或者其他应用都无法拿到这个变量。

1、快照沙箱

2、支持多应用的代理沙箱

标签列表