getComputedStyle 是一个可以获取当前元素所有最终使用的CSS属性值。返回的是一个CSS样式声明对象(objectCSSStyleDeclaration) getComputedStyle 方法获取的是最终应用在元素上的所有CSS属性对象(包括默认),而element.style只能获取元素style属性中的CSS样式。
在 toB 的前端开发工作中,我们往往就会遇到如下困境:
基座模式
通过一个主应用,来管理其它应用。设计难度小,方便实践,但是通用度低。
自组织模式。应用之间是平等的,不存在相互管理的模式。设计难度大,不方便实施,但是通用度高。
就当前而言,基座模式实施起来比较方便,方案也是蛮多的。
注册表模式
和微服务架构相似,不论是哪种微前端方式,都需要有一个应用注册表的服务。这个应用注册表拥有每个应用及对应的入口,即路由。
它可以是一个固定值的配置文件,如 JSON 文件,又或者是一个可动态更新的配置,又或者是一种动态的服务。
作用:
应用注册。即提供新的微前端应用,向应用注册表注册功能。
应用发现。让主应用可以寻找到其它应用。
首先看一下它的用法:
https://qiankun.umijs.org/zh/guide/getting-started
微前端每个应用都拥有自己的生命周期:
bootstrap, 只会在微应用初始化的时候调用一次,下次微应用重新进入时会直接调用 mount 钩子,不会再重复触发 bootstrap。 通常我们可以在这里做一些全局变量的初始化,比如不会在 unmount 阶段被销毁的应用级别的缓存等。
Mount,应用每次进入都会调用 mount 方法,通常我们在这里触发应用的渲染方法
Unload,删除应用的生命周期
Unmount,应用每次 切出/卸载 会调用的方法,通常在这里我们会卸载微应用的应用实例
乾坤,作为一款微前端领域的知名框架,其建立在single-spa基础上。相较于single-spa,乾坤做了两件重要的事情,其一是加载资源,第二是进行资源隔离。而资源隔离又分为Js资源隔离和css资源隔离.
每个微应用对全局的影响都会局限在微应用自己的作用域内。比如 A 应用在 window 上新增了个属性 test,这个属性只能在 A 应用自己的作用域通过 window.test 获取到,主应用或者其他应用都无法拿到这个变量。
1、快照沙箱
2、支持多应用的代理沙箱