关于前端:聊聊微前端的原理和实践

本文首发于 vivo 互联网技术微信公众号
链接：https://mp.weixin.qq.com/s/2qH9qMNpU_LuLEBTsDUKzA
作者：Tan Xin

本文对微前端的概念和场景进行科普，介绍一些支流的微前端的实现库及其用法，并解说局部这些库的原理和实际常识。

在我的项目迭代中，随着业务的发展壮大，我的项目的功能模块通常也会越来越多。可能原来所有的代码模块都在一个仓库里，由一个团队负责。但随着功能模块越来越多，一个团队可能负责不过去，须要多个团队来专门保护不同的模块。相应的代码也会被拆到多个仓库里，并且各模块能独立开发、部署更新。通常尽管我的项目被拆成了多个模块，但为了维持整体统一性以及用户体验，各模块仍然都会挂在对立的入口下。

下面所述场景就是典型的微前端场景，相似于后端的微服务架构，它将 web 利用由繁多的单体利用转变为多个小型前端利用聚合为一的利用。

通常，要实现下面相似的需要，咱们很容易会想到应用 iframe 的形式来实现。在入口框架中用 iframe 来显示子模块的页面，切换子模块时，iframe 也跟着切换成对应子模块页面的 url。

尽管 iframe 是比拟容易实现的，但通常也会有一些问题：

显示区域受限制，比方子项目中显示弹窗蒙层时，蒙层只会笼罩 iframe 区域，无奈笼罩整个页面，内容也无奈真正居中。
页面浏览记录无奈主动被记录，刷新页面后 iframe 又主动回到首页。
全局上下文齐全隔离，变量不共享，页面间通信比拟麻烦，比方子项目与主题框架、子项目之间通信等，只能采纳 postMessage 形式。
速度较慢，每次进入子利用时都要重建整个上下文。

下面所列问题，有些能够解决，有些甚至都没法或者很难解决。总的来说，iframe 是一个比拟快捷的计划，但不是最好的计划，会对体验有很多限度。如果强行打各种 patch，复杂度又上来了，最初可能得失相当。

方才咱们讲了 iframe 实现微前端的一些弊病，次要起因就是这些利用还是在各自独立的页面内，这就导致了一些人造的限度。而 single-spa 微前端计划联合了 MPA 和 SPA 的劣势，能够在单个页面内集成多个利用，并且是技术栈无关的。

如上图就是采纳 single-spa 实现微前端的整体流程：

资源模块加载器： 用来加载子项目初始化资源。咱们将子项目的入口 js 构建成 umd 格局，而后应用模块加载器近程加载，通常会应用 SystemJs（不是必须）通用模块加载器来进行加载。

子利用资源配置表： 用来记录各个子利用的入口资源 url 信息，以便在切换不同子利用时应用模块加载器去近程加载。因为每次子利用更新后入口资源的 hash 通常会变动，所以须要服务端定时去更新该配置表，以便框架能及时加载子利用最新的资源。

留神：single-spa 自身是不反对子利用资源列表的，每个子利用只能将本人所有初始化资源打包到一个入口 js 中。如果子利用初始化资源有多个文件（能够通过 webpack-manifest-plugin 生成利用初始化资源清单），就须要依照上述形式来增加额定解决。

<!DOCTYPE html>
<html>
  
<head>
  <!-- 在 systemjs 中注册模块 -->
  <script type="systemjs-importmap">
    {
      "imports": {
        "app1": "http://localhost:8081/js/app.js",
        "app2": "http://localhost:8082/js/app.js",
        "single-spa": "https://cdnjs.cloudflare.com/ajax/libs/single-spa/4.3.7/system/single-spa.min.js",
        "vue": "https://cdn.jsdelivr.net/npm/vue@2.6.10/dist/vue.js",
        "vue-router": "https://cdn.jsdelivr.net/npm/vue-router@3.0.7/dist/vue-router.min.js",
        "vuex": "https://cdnjs.cloudflare.com/ajax/libs/vuex/3.1.2/vuex.min.js"
      }
    }
</script>
</head>
  
<body>
  <div></div>
  <!-- 加载 systemjs -->
  <script src="https://cdnjs.cloudflare.com/ajax/libs/systemjs/6.1.1/system.min.js"></script>
  <script src="https://cdnjs.cloudflare.com/ajax/libs/systemjs/6.1.1/extras/amd.min.js"></script>
  <script src="https://cdnjs.cloudflare.com/ajax/libs/systemjs/6.1.1/extras/named-exports.js"></script>
  <script src="https://cdnjs.cloudflare.com/ajax/libs/systemjs/6.1.1/extras/named-register.min.js"></script>
  <script src="https://cdnjs.cloudflare.com/ajax/libs/systemjs/6.1.1/extras/use-default.min.js"></script>
  <script>
    (function () {
      // 加载公共 js 库
      Promise.all([System.import('single-spa'), System.import('vue'), System.import('vue-router'), System.import('vuex')]).then(function (modules) {var singleSpa = modules[0];
        var Vue = modules[1];
        var VueRouter = modules[2];
        var Vuex = modules[3];
  
        Vue.use(VueRouter)
        Vue.use(Vuex)
  
        // single-spa 注册子利用
        singleSpa.registerApplication(
          'app1',
          () => System.import('app1'),
          location => location.pathname.startsWith('/app1')
        )
  
        singleSpa.registerApplication(
          'app2',
          () => System.import('app2'),
          location => location.pathname.startsWith('/app2')
        )
  
        // 启动
        singleSpa.start();})
    })()
</script>
</body>
  
</html>

为了简略展现，上述只是框架入口 html 的一个简略 demo，并没有解析子利用资源配置表来加载相应资源。在入口中咱们注册了子利用，并确定了子利用的激活机会。

子利用资源配置表是齐全自定义的，只有入口加载器这边依照约定的标准来解析加载资源，并依照 single-spa 的生命周期钩子来解决好这些资源的挂载。

咱们还能够将一些公共的资源库资源库（如上 vue、vue-router 等）抽取到入口中，这样各个子利用不须要再蕴含这些库文件了，能够减小资源文件大小，晋升加载速度。子利用中构建时要外置这些库，比方用 webpack 构建时如下：

externals: ['vue', 'vue-router', 'vuex']

import './set-public-path'
import Vue from 'vue'
import App from './App.vue'
import router from './router'
import singleSpaVue from 'single-spa-vue'
  
Vue.config.productionTip = false
  
if (process.env.NODE_ENV === 'development') {
  // 开发环境间接渲染
  new Vue({
    router,
    render: h => h(App)
  }).$mount('#app')
}
  
const vueLifecycles = singleSpaVue({
  Vue,
  appOptions: {render: (h) => h(App),
    router
  }
})
  
export const bootstrap = vueLifecycles.bootstrap
export const mount = vueLifecycles.mount
export const unmount = vueLifecycles.unmount

如上咱们的子利用是 vue 开发的，须要用 single-spa-vue 来包装下，而后导出生命周期的钩子函数。为了不便开发，咱们能够判断下运行环境，如果是开发环境的话，就间接渲染到页面上。

set-public-path.js

仔细的同学就会留神到，子利用代码中运行了 set-public-path.js。那么这个文件是干嘛用的呢？先来看下：

import {setPublicPath} from 'systemjs-webpack-interop'
setPublicPath('app1', 2)

从名字也能看出，systemjs-webpack-interop 是针对在 systemjs 中应用 webpack 构建的 bundle 的场景的。家喻户晓，webpack 构建代码时，能够通过 output.publicPath 选项指定要加载资源的 url 前缀，这在传统的 spa 中不会有问题，但在 single-spa 的页面中可能会有问题。比方 output.publicPath: ‘/xx’ 的状况，webpack 会认为异步资源加载的 url 域名为以后页面的域名，这在传统 spa 中不会有问题，但在 single-spa 的场景下异步资源就会加载失败，因为子利用的异步资源与框架页面的 url 域名并不是一样的。所以须要各个子利用自行在入口中执行上述代码，这会设置子利用的异步资源 url 前缀与子利用的入口 js 统一，这样加载的门路就不会谬误了。

setPublicPath 代码如下：

export function setPublicPath(systemjsModuleName, rootDirectoryLevel) {if (!rootDirectoryLevel) {rootDirectoryLevel = 1;}
 
 
  if (
    typeof systemjsModuleName !== "string" ||
    systemjsModuleName.trim().length === 0) {
 
    throw Error("systemjs-webpack-interop: setPublicPath(systemjsModuleName) must be called with a non-empty string'systemjsModuleName'"
 
    );
 
  }
 
 
  if (
    typeof rootDirectoryLevel !== "number" ||
    rootDirectoryLevel <= 0 ||
    !Number.isInteger(rootDirectoryLevel)
  ) {
 
    throw Error("systemjs-webpack-interop: setPublicPath(systemjsModuleName, rootDirectoryLevel) must be called with a positive integer'rootDirectoryLevel'"
    );
 
  }
 
 
  let moduleUrl;
  try {moduleUrl = window.System.resolve(systemjsModuleName);
    if (!moduleUrl) {throw Error()
 
    }
 
 
  } catch (err) {
 
    throw Error(
      "systemjs-webpack-interop: There is no such module'" +
        systemjsModuleName +
        "'in the SystemJS registry. Did you misspell the name of your module?"
    );
 
 
  }
 
  __webpack_public_path__ = resolveDirectory(moduleUrl, rootDirectoryLevel);
 
}
 
function resolveDirectory(urlString, rootDirectoryLevel) {const url = new URL(urlString);
  const pathname = new URL(urlString).pathname;
  let numDirsProcessed = 0,
    index = pathname.length;
 
  while (numDirsProcessed !== rootDirectoryLevel && index >= 0) {const char = pathname[--index];
    if (char === "/") {numDirsProcessed++;}
  }
 
  if (numDirsProcessed !== rootDirectoryLevel) {
    throw Error(
      "systemjs-webpack-interop: rootDirectoryLevel (" +
        rootDirectoryLevel +
        ") is greater than the number of directories (" +
        numDirsProcessed +
        ") in the URL path" +
        fullUrl
    );
 
  }
 
  url.pathname = url.pathname.slice(0, index + 1);
  return url.href;
 
}

如下面提到过，如果子利用初始化资源有多个文件（比方通常咱们会将 css、npm 模块抽离成一个独自的文件），那么咱们就要自行保护一个子利用资源列表并做一些额定解决，这个工作往往也是比拟繁琐的；
将多个子利用都集成在一个页面中，css 和 js 都是很有可能产生抵触的。尽管咱们能够制订标准，比方各子项目应用惟一地命名前缀等，但这种人为约定往往又是不那么靠谱。对于 css，咱们还能够在构建时应用一些工具主动增加前缀，这样能够比拟靠谱的防止抵触；对于 js 来说，比拟靠谱的形式可能就是人为制作沙箱，让子利用的 js 都运行在各自的沙箱中，但这实现起来就比较复杂了。

其实，曾经有个基于 single-spa 的开源库 qiankun 曾经帮咱们解决了下面提到的问题，其有如下特色：

解析子利用入口时，不是解析的 js 文件，二是间接解析子利用的 html 文件。就算子利用更新了，其入口 html 文件的 url 始终不会变，并且残缺的蕴含了所有的初始化资源 url，所以不必再自行保护子利用的资源列表了。
子利用挂载时，会主动进行一些非凡解决，能够确保子利用所有的资源 dom（包含 js 增加的 style 标签等）都集中在子利用根节点 dom 下。子利用卸载时，对应的整个 dom 都移除了，这样也就防止了款式抵触。
提供了 js 沙箱，子利用挂载时，会对全局 window 对象代理、对全局事件监听进行劫持等，确保各子利用都运行在本人的沙箱内，这样也就防止了 js 抵触。

蕴含多个 spa 利用的 demo

子利用 dom 构造如下

当然，在前端越来越宏大简单的场景中，微前端计划也不是银弹，但确是值得摸索实际的方向。

single-spa
qiankun
可能是你见过最欠缺的微前端解决方案

更多内容敬请关注 vivo 互联网技术 微信公众号

注：转载文章请先与微信号：Labs2020 分割。

关于前端:聊聊微前端的原理和实践

一、微前端

二、single-spa

1、框架入口

2、子利用入口

三、single-spa 的有余

四、qiankun

五、参考文献

Just My Socks（注册教程内含优惠码）

关于前端:聊聊微前端的原理和实践

一、微前端

二、single-spa

1、框架入口

2、子利用入口

三、single-spa 的有余

四、qiankun

五、参考文献

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）