前言
在上一篇文章【微前端】single-spa 到底是个什么鬼 聊到了 single-spa 这个框架仅仅实现了子应用的生命周期的调度以及 url 变化的监听。微前端的一个特点都没有实现，严格来说算不上微前端框架。
今天就来聊一个真正的微前端框架：qiankun。同样地，本文不会教大家怎么实现一个 Demo，因为官方的 Github 已经有一个很好的 Demo 了，如果你觉得官网的 Demo 太复杂了，也可以看我自己实现的小 Demo。
qiankun 到底做了什么
首先，qiankun 并不是单一个框架，它在 single-spa 基础上添加更多的功能。以下是 qiankun 提供的特性：
- 实现了子应用的加载，在原有 single-spa 的 JS Entry 基础上再提供了 HTML Entry
- 样式和 JS 隔离
- 更多的生命周期：beforeMount, afterMount, beforeUnmount, afterUnmount
- 子应用预加载
- 全局状态管理
- 全局错误处理
接下来不会一个特性一个特性地讲，因为这样会很无聊，讲完你也只能知道这是个啥，不能深入了解是怎么来的。所以我更愿意聊一下这些特性是怎么来的，它们是怎么被想到的。
多入口
先复习一下 single-spa 是怎么注册子应用的：
singleSpa.registerApplication(
'appName',
() => System.import('appName'),
location => location.pathname.startsWith('appName'),
);
可以看到 single-spa 采用 JS Entry 的方式接入微应用，也即：输出一个 JS，然后 bootstrap, mount, unmount 函数。
但是事件并没有这么简单：我们项目一般都会将静态资源放到 CDN 上来加速。为了不受缓存的影响，我们还会将 JS 文件命名成 contenthash 的乱码文件名： jlkasjfdlkj.jalkjdsflk.js。这样一来，每次子应用一发布，入口 JS 文件名肯定又要改了，导致主应用引入的 JS url 又得改了。麻烦！
打包成单个 JS 文件的另一个问题就是打包的优化都没了：按需加载、首屏资源加载优化、css 独立打包等优化措施全 ️。
很多时候，子应用一般都已经是线上的应用了，比如 https://abcd.com。微前端融合多个子应用本质上不就是融合多个 HTML 嘛？那为什么不给你子应用的 HTML，主应用就自动接入收工了呢？操作起来应该和在 和插入 src 是一样的才对味。
这种通过提供 HTML 入口来接入子应用的方式就叫 HTML Entry。 qiankun 的一大亮点就是提供了 HTML Entry，在调用 qiankun 的注册子应用函数时可以这么写：
registerMicroApps([
{
name: 'react app', // 子应用名
entry: '//localhost:7100', // 子应用 html 或网址
container: '#yourContainer', // 挂载容器选择器
activeRule: '/yourActiveRule', // 激活路由
},
]);
start(); // Go
用起来毫不费力，只需要在 JS 入口加上 single-spa 的生命周期钩子，再发布就可以直接接入了。
import-html-entry
然而，HTML Entry 并不是给个 HTML 的 url 就可以直接接入整个子应用这么简单了。子应用的 HTML 文件就是一堆乱七八糟的标签文本。, 的玩意
css.process(mountDOM, stylesheetElement, appName);
}
}
return rawDOMAppendOrInsertBefore.call(mountDOM, stylesheetElement, referenceNode); // 插入到挂载容器上
}
case SCRIPT_TAG_NAME: {
const { src, text } = element as HTMLScriptElement;
if (element.src) { // 处理外链 JS
execScripts(null, [src], proxy, { // 获取并执行 JS
fetch,
strictGlobal,
});
return rawDOMAppendOrInsertBefore.call(mountDOM, dynamicScriptCommentElement, referenceNode); // 插入到挂载容器上
}
// 处理内联 JS
execScripts(null, [``], proxy, { strictGlobal });
return rawDOMAppendOrInsertBefore.call(mountDOM, dynamicInlineScriptCommentElement, referenceNode);
}
default:
break;
}
当在创建沙箱时打完补丁后，在处理样式和 JS 脚本时就可以针对当前子应用来应用样式和 JS 了。上面我们还注意到 CSS 样式文本是被保存的，所以当子应用 remount 的时候，这些样式也可以作为缓存直接一波补上，不需要再做处理了。
剩下的补丁都是给 historyListeners, setInterval, addEventListeners, removeEventListeners 做的补丁，无非就是 mount 时记录 listeners 以及一些添加的值，在 unmount 的时候再一次性执行掉或者删除掉，不再赘述。
更多的生命周期
如果当前项目迁移成子应用，在入口的 JS 就不得不配合 qiankun 来做一些改动，而这些改动有可能影响子应用的独立运行。比如，接入了微前端后，可能就不得不在本地先起一个主应用，再起一个子应用，然后才能做开发和调试，那这也太蛋疼了。
为了解决子应用也能独立运行的问题，qiankun 注入了一些变量，来告诉子应用说：喂，你现在是儿子，要用子应用的渲染方式。而当子应用获取不到这些注入的变量时，它就知道：哦，我现在要独立运行了，用回原来的渲染方式就可以了，比如：
if (window. __POWERED_BY_QIANKUN__) {
console.log('微前端场景')
renderAsSubApp()
} else {
console.log('单体场景')
previousRenderApp()
}
怎么注入就是个问题了，不能简单的 window.__POWERED_BY_QIANKUN__ = true 就完事了，因为子应用会在编译时就要这个变量了。所以，qiankun 在 single-spa 提供的生命周期 load, mount, unmount 前做了变量的注入，伪代码如下：
// getAddOn
export default function getAddOn(global: Window): FrameworkLifeCycles {
return {
async beforeLoad() {
// eslint-disable-next-line no-param-reassign
global.__POWERED_BY_QIANKUN__ = true;
},
async beforeMount() {
// eslint-disable-next-line no-param-reassign
global.__POWERED_BY_QIANKUN__ = true;
},
async beforeUnmount() {
// eslint-disable-next-line no-param-reassign
delete global.__POWERED_BY_QIANKUN__;
},
};
}
// loadApp
const addOnLifeCycles = getAddOn(window)
return {
load: [addOnLifeCycles.beforeLoad, subApp.load],
mount: [addOnLifeCycles.mount, subApp.mount],
unmount: [addOnLifeCycles.unmount, subApp.unmount]
}
总结一下，新增的生命周期有：
- beforeLoad
- beforeMount
- afterMount
- beforeUnmount
- afterUnmount
loadApp
好了，上面就是加载一个子应用的所有步骤了，这里先做个小总结：
- import-html-entry 解析 html，获取 JavaScript, CSS, HTML
- 创建容器 container，同时加上 css 样式隔离：在 container 上添加 Shadow DOM 或者对 CSS 文本 添加前缀实现 Scoped CSS
- 创建沙箱，监听 window 的变化，并对一些函数打上补丁
- 提供更多的生命周期，在 beforeXXX 里注入一些 qiankun 提供的变量
- 返回带有 bootstrap, mount, unmount 属性的对象
预加载
从上面可以看到加载一个子应用的时候需要很多的步骤，我们不禁想到：如果在 mount 第一个子应用空闲时候，可以预先加载别的子应用，那之后切换子应用就可以更快了，也即子应用预加载。
在空闲的时候干一些事，可以使用浏览器提供的 requestIdleCallback。OK，那我们再来定义一下“预加载”是什么，其实就是把 CSS 和 JS 下载下来就完事了，所以 qiankun 的源码也是很简单的：
requestIdleCallback(async () => {
const { getExternalScripts, getExternalStyleSheets } = await importEntry(entry, opts);
requestIdleCallback(getExternalStyleSheets);
requestIdleCallback(getExternalScripts);
});
现在，我们再来脑洞大开一下：难道一下子就要所有子应用都要预加载么？不见得吧？有可能一些子应用要预加载，一些不需要。
所以 qiankun 提供了三种预加载策略：
- 全部子应用都立马预加载
- 全部子应用都在第一个子应用加载后才预加载
- 在
criticalAppNames数组里的子应用要立马预加载，在minorAppsName数组里的子应用在第一个子应用加载后才预加载
源码实现如下：
export function doPrefetchStrategy(
apps: AppMetadata[],
prefetchStrategy: PrefetchStrategy,
importEntryOpts?: ImportEntryOpts,
) {
const appsName2Apps = (names: string[]): AppMetadata[] => apps.filter((app) => names.includes(app.name));
if (Array.isArray(prefetchStrategy)) {
// 全部都在第一个子应用加载后才预加载
prefetchAfterFirstMounted(appsName2Apps(prefetchStrategy as string[]), importEntryOpts);
} else if (isFunction(prefetchStrategy)) {
(async () => {
// 一半一半
const { criticalAppNames = [], minorAppsName = [] } = await prefetchStrategy(apps);
prefetchImmediately(appsName2Apps(criticalAppNames), importEntryOpts);
prefetchAfterFirstMounted(appsName2Apps(minorAppsName), importEntryOpts);
})();
} else {
switch (prefetchStrategy) {
case true: // 全部都在第一个子应用加载后才预加载
prefetchAfterFirstMounted(apps, importEntryOpts);
break;
case 'all': // 全部子应用都立马预加载
prefetchImmediately(apps, importEntryOpts);
break;
default:
break;
}
}
}
全局状态管理
全局状态很有可能出现在微前端的场景中，比如主应用提供可以一些初始化好的 SDK。刚开始先传个未初始好的 SDK，等主应用把 SDK 初始化好了，再通过回调通知子应用：醒醒，SDK 准备好了。
这种思路和 Redux, Event Bus 一模一样。 状态都存在 window 的 gloablState 全局对象里，再添加一个 onGlobalStateChange 回调就完事了，实现伪代码如下：
let gloablState = {}
let deps = {}
// 触发全局监听
function emitGlobal(state: Record, prevState: Record) {
Object.keys(deps).forEach((id: string) => {
if (deps[id] instanceof Function) {
deps[id](cloneDeep(state), cloneDeep(prevState));
}
});
}
// 添加全局状态变化的监听器
function onGlobalStateChange(callback: OnGlobalStateChangeCallback, fireImmediately?: boolean) {
deps[id] = callback;
if (fireImmediately) {
const cloneState = cloneDeep(globalState);
callback(cloneState, cloneState);
}
}
// 更新 globalState
function setGlobalState(state: Record = {}) {
const prevState = globalState
globalState = {...cloneDeep(globalState), ...state}
emitGlobal(globalState, prevState);
}
// 注销该应用下的依赖
function offGlobalStateChange() {
delete deps[id];
}
onGlobalStateChange 添加监听器，当调用 setGlobalState 更新值，值改了，调用 emitGlobal，执行所有对应的监听器。调用 offGlobalStateChange 删掉监听器。Easy ~
全局错误处理
主要监听了 error 和 unhandledrejection 两个错误事件：
export function addGlobalUncaughtErrorHandler(errorHandler: OnErrorEventHandlerNonNull): void {
window.addEventListener('error', errorHandler);
window.addEventListener('unhandledrejection', errorHandler);
}
export function removeGlobalUncaughtErrorHandler(errorHandler: (...args: any[]) => any) {
window.removeEventListener('error', errorHandler);
window.removeEventListener('unhandledrejection', errorHandler);
}
使用的时候添加监听器，不要的时候移除监听器，不废话。
总结
再次总结一下 qiankun 做了什么事情：
- 实现 loadApp 函数，是最关键、重要的一步
- 实现 CSS 样式隔离，主要有 Shadow DOM 和 Scoped CSS 两种方案
- 实现沙箱，JS 隔离，主要对 window 对象、各种 listeners 和方法进行隔离
- 提供很多生命周期，并在一些
beforeXXX的钩子里注入 qiankun 提供的变量
- 提供预加载，提前下载 HTML、CSS、JS，并有三种策略
- 全部立马预加载
- 全部在第一个加载后预加载
- 一些立马预加载，一些在第一个加载后预加载
- 提供全局状态管理，类似 Redux，Event Bus
- 提供全局错误处理，主要监听 error 和 unhandledrejection 两个事件
最后
虽然阿里说：“可能是你见过最完善的微前端解决方案”。但是从上面对源码的解读也可以看出来，qiankun 也有一些事情没有做的。比如没有对 localStorage 进行隔离，如果多个子应用都用到 localStorage 就有可能冲突了，除此之外，还有 cookie, indexedDB 的共享等。再比如如果单个页面下多个子应用都依赖了前端路由怎么办呢？当然这里的质疑也仅是我个人的猜想。
另一件事想说的是：微前端的难点并不是 single-spa 的生命周期、路由挟持。而是如何加载好一个子应用。从上面可以看到，有很多 hacky 的编码，比如在选择器前面加前缀，将子应用的 ,