一次微前端的改造记录

前言

由于公司的一些需求，需要去了解 iframe 和 qiankun 两种微前端方案，特此记录一下。

微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还可以独立运行、独立开发、独立部署。

iframe

HTML 内联框架元素，能够将另一个 HTML 页面嵌入到当前页面

<iframe src="文件路径"></iframe>

postMessage

• 
  
• 
  

  window.postMessage() 方法可以安全地实现跨源通信：postMessage 讲解

  
  
  
• 
  

  通常来说，对于两个不同页面的脚本，只有当他们页面位于具有相同的协议（通常为 https），端口号（443 为 https 的默认值），以及主机时，这两个脚本才能互相通信。window.postMessage() 方法提供了一种受控机制来规避此限制，只要正确的使用，这种方法就很安全

  
  

  otherWindow.postMessage(message, targetOrigin, [transfer]);
  

  
  
  
• 
  

  postMessage 的兼容性

  
  
  

实现思路

整体架构

以我们公司的真实项目为例：

一个父站点，很多子站点，不同的子站点即为完全独立的不同的项目
父站点包括：

1. 
   
2. 公共部分：header 部分、左侧菜单部分都是公共的组件
   
3. 主区域部分（子站点区域）：需要展示不同子站点的业务部分
   

父子站点通信（如何展示不同的站点页面）

上面已经介绍过 iframe 和 postMessage：我们通过 iframe 去加载不同项目的线上地址

1. 
   
2. 我们新建一个通用组件，无论菜单路由指向何处都指向这个组件，渲染这个组件
   
3. 在这个组件中监听路由的变化，返回不同的线上地址，让 iframe 去加载对应的内容（公司项目比较老，还是使用的 vue2）
   

<template>

  <div class="container">

    <iframe :src="src"></iframe>

  </div>

</template>


<script>

export default {

  data() {

    return {

      src: '',

    };

  },

  mounted() {

    this.updateIframe(); // 生命周期加载一次，否则页面空白，第一次监听不到

  },

  watch: {

    $route() {

      this.updateIframe();

    },

  },

  methods: {

    updateIframe() {

      // 更新 src

    },

  },

};

</script>

3. 
   
4. 菜单以及子站点线上地址怎么来：目前我们的做法是单独的菜单配置，通过接口去拿，配置菜单的时候同事配置好 iframe 线上地址，这样就可以一起拿到了
   
   
5. 那我们究竟如何通信呢？
   父站点（补充上面的代码）：
   

<template>

  <div class="container">

    <iframe :src="src" id="iframe"></iframe>

  </div>

</template>

<script>

export default {

  data() {

    return {

      src: '',

    };

  },

  mounted() {

    this.getMessage();

    this.updateIframe(); // 生命周期加载一次，否则页面空白，第一次监听不到，同样的也可以使用 iframe 的 onload 方法

  },

  watch: {

    $route() {

      this.updateIframe();

    },

  },

  methods: {

    updateIframe() {

      // 更新 src

    },

    messageCallBack(data) {

      // 这边可以接收一些子站点的数据，去做一些逻辑判断，比如要在iframe加载完之后，父站点再去发消息给子站点，不然肯定存在问题

      // 可以传递一些信息给子站点

      this.postMessage({

        data: {},

      });

    },

    postMessage(data) {

      document.getElementById('iframe').contentWindow.postMessage(JSON.stringify(data), '*');

    },

    getMessage() {

      window.addEventListener('message', this.messageCallBack);

    },

  },

};

</script>

5. 
   
6. 子站点也一样在需要的地方通过 postMessage 去发送或者接受数据（比如我们子站点每次都加载首页，然后接收到路由信息，再在子项目中跳转到对应页面）
   

需要干掉 iframe 滚动条吗

当然需要，不然多丑，加入以下代码即可去掉：

#app {

  -ms-overflow-style: none; /* IE 和 Edge 浏览器隐藏滚动条 */
scrollbar-width: none; /* FireFox隐藏浏览器滚动条 */

}
/* Chrome浏览器隐藏滚动条 */
#app::-webkit-scrollbar {
display: none;

}

弹窗是否能覆盖整个屏幕

UI 不同步，DOM 结构不共享。 iframe 里来一个带遮罩层的弹框，只会在 iframe 区域内，为了好看，我们需要让它在整个屏幕的中间

解决：

• 
  
• 使得 iframe 区域的宽高本身就和屏幕宽高相等，子站点内部添加 padding ，使内容区缩小到原本子站点 content 区域；
  
• 正常情况下，父站点 header、左侧菜单部分的层级需要高于 iframe 的层级（iframe 不会阻止这些区域的点击）；
  
• 当用户点了新建按钮，对话框出现的时候，给父项目发送一条消息，让父项目调高 iframe 的层级，遮罩便可以覆盖全屏。
  

这样的解决的缺点：每次打开弹窗，都得先发送 postMessage 数据，逻辑显得多余，对于新手不友好；可是为了好看，只能这样了。

iframe 方案总结

好用的地方：

• 
  
• 业务解耦
  
• 技术隔离，vue、react 互不影响
  
• 项目拆分，上线快速，对其他项目无影响
  
• iframe 的硬隔离使得各个项目的 JS 和 CSS 完全独立，不会产生样式污染和变量冲突
  

存在的缺点：

• 
  
• 布局约束：不给定高度，会塌陷；iframe 内的 div 无法全屏（iframe 标签设置 allow="fullscreen" 属性即可）
  
• 不利于 seo，会当成 2 个页面，破坏了语义化 ，对无障碍可访问性支持不好
  
• url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用
  
• 性能开销，慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程
  

还需要解决的问题：

• 
  
• 全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果；至于怎么传，可以根据每个公司得实际情况去定
  

qiankun

接下来在 iframe 的基础下扩展下 qiankun，在使用方面还是简单的
qiankun 使用指南

父项目中

值得注意的是，我们需要增加一个类型，如果是 qiankun 的项目，需要全部指向新增的 qiankun 组件

<template>

  <div>

    <div id="microContainer" class="microContainer"></div>

  </div>

</template>


<script>

import fetchData from './fetchData'; // 一些逻辑处理

import { loadMicroApp } from 'qiankun';

import { getToken } from '@/...';


export default {

  data() {

    return {

      microRef: null,

    };

  },

  methods: {

    fetch(route) {

      fetchData(route).then(({ data }) => {

        const { name, entry } = data;


        this.microRef = loadMicroApp({

          name,

          entry,

          container: '#yourContainer',

          props: {

            router: this.$router,

            data: {

              // 一些参数

            },

            token: getToken(),

          },

        });

      });

    },

    unregisterApplication() {

      this.microAppRef.mountPromise.then(() => this.microAppRef.unmount());

    },

  },

  mounted() {

    this.fetch(this.$route);

  },

  beforeDestroy() {

    this.unregisterApplication();

  },

};

</script>

子项目中

在 src 目录新增文件 public-path.js

iif (window.__POWERED_BY_QIANKUN__) {
// 动态设置子应用的基础路径
// 使用 window.__INJECTED_PUBLIC_PATH_BY_QIANKUN__ 变量来获取主应用传递的基础路径

  __webpack_public_path__ = window.__INJECTED_PUBLIC_PATH_BY_QIANKUN__;

}

子项目中需要导出 bootstrap、mount、unmount 三个生命周期钩子，以供主应用在适当的时机调用

const render = (parent = {}) => {
if (window.__POWERED_BY_QIANKUN__) {
// 渲染 qiankun 的路由

  } else {
// 渲染正常的路由

  }

};

//全局变量来判断环境，独立运行时
if (!window.__POWERED_BY_QIANKUN__) {
render();

}
/**

 * bootstrap 只会在微应用初始化的时候调用一次，下次微应用重新进入时会直接调用 mount 钩子，不会再重复触发 bootstrap。

 * 通常我们可以在这里做一些全局变量的初始化，比如不会在 unmount 阶段被销毁的应用级别的缓存等。

 */
export async function bootstrap() {
console.log('react app bootstraped');

}

/**

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

 */
export async function mount(props) {
render(props.data);

}

/**

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

 */
export async function unmount(props) {
ReactDOM.unmountComponentAtNode(

    props.container ? props.container.querySelector('#root') : document.getElementById('root')

  );

}

/**

 * 可选生命周期钩子，仅使用 loadMicroApp 方式加载微应用时生效

 */
export async function update(props) {
console.log('update props', props);

}

子站点 webpack 配置

const packageName = require('./package.json').name;

module.exports = {
output: {
library: `${packageName}-[name]`,
libraryTarget: 'umd', // 把子应用打包成 umd 库格式，让 qiankun 拿到其 export 的生命周期函数
jsonpFunction: `webpackJsonp_${packageName}`,

  },

};

路由方面：qiankun 使用父站点的路由，在子站点获取到路由信息，然后加载不同的组件，如果单独运行子站点，则需要适配自己的路由组件，做一些差异化处理就好了

qiankun 总结

• 
  
• qiankun 自带 js/css 沙箱功能
  
  • 
    
  • js 隔离：Proxy 沙箱，它将 window 上的所有属性遍历拷贝生成一个新的 fakeWindow 对象，紧接着使用 proxy 代理这个 fakeWindow，用户对 window 操作全部被拦截下来，只作用于在这个 fakeWindow 之上
    
  • css 隔离：ShadowDOM 样式沙箱会被开启。在这种模式下 qiankun 会为每个微应用的容器包裹上一个 shadow dom 节点，从而确保微应用的样式不会对全局造成影响；
    
  
  
  
• qiankun 支持子项目预请求功能
  
• 支持复用公共依赖
  
  • 
    
  • webpack 配置 externals：子项目独立运行时，这些依赖的来源有且仅有 index.html 中的外链 script 标签
    
  • 可以给子项目 index.html 中公共依赖的 script 和 link 标签加上 ignore 属性；有了这个属性，qiankun 便不会再去加载这个 js/css，而子项目独立运行，这些 js/css 仍能被加载
    
  
  
  

存在的问题：

• 
  
• css 污染问题
  
  • 
    
  • 全局 CSS：如果子站点中使用了全局 CSS 样式（如直接写在 HTML 中的 标签或通过 引入的外部样式表），这些全局样式可能会影响整个页面，包括父站点和其他子站点。
    
  • CSS 命名冲突：如果子站点和父站点使用相同的 CSS 类名或样式选择器，它们的样式规则可能会相互覆盖或产生不可预料的效果。为避免冲突，可以采用命名约定或 CSS 模块化来隔离样式。
    
  
  
  

总结

目前只是初步接入了 qiankun，后续还会基于 qiankun 做一些优化，当然不考虑一些因素的情况下，个人觉得 iframe 依旧是最完美的沙箱隔离，当然目前在我们的项目中，他们是共存的，各有优劣。微前端也是前端工