腾讯开源的 hel,提供了一种运行时引入远程模块的能力,模块部署在 CDN,远程模块发布后,不需要重新构建发布,就能生效。
个人觉得它的实现原理非常的不错,因此分享给大家。
远程模块可以作为微模块(模块级别的微前端),是页面级别的微前端的一种补充,因为页面级别的微前端,如 qiankun、无界等,它们的粒度太粗了,有时候需要更细粒度的微前端,例如:组件、函数级别的。这种场景,就可以使用远程模块,来实现微模块的效果。
import helMicro from 'hel-micro';
export async function callRemoteMethod() {
const lib = await helMicro.preFetchLib('hel-tpl-remote-lib');
return lib.num.random(22);
}
hel-micro
模块helMicro.preFetchLib
拉取远程模块整个使用过程非常的简单易懂,但这样无法使用 TS 类型检查。
于是又有了以下的写法:
需要先项目入口调用:
await helMicro.preFetchLib('hel-tpl-remote-lib');
然后代码中就可以这样使用了:
import remoteLib from 'hel-tpl-remote-lib';
function callRemoteMethod() {
return remoteLib.num.random(19);
}
TS 类型则是由 hel-tpl-remote-lib
这个 npm 仓库提供。
发布 CDN,在浏览器运行时,调用 helMicro.preFetchLib
真正拉取代码
用于开发时的类型提示,上传到 npm。开发时安装并使用该 npm 包,可以获得 TS 类型提示
元数据是一份 json 配置清单,是在远程模块构建完成后,从构架产物中提取生成的。它记录了远程模块的名称、**入口脚本路径**等信息
helMicro.preFetchLib
时,先拉取元数据,从元数据中获取到入口脚本的 url,然后拉取远程模块入口并执行,最后 helMicro.preFetchLib
将模块返回,代码中就可以直接使用了。import
代理模块,实际上是从远程模块的缓存中读取模块。因此,必须要等待 helMicro.preFetchLib
拉取完成后,import
的代理模块才能够获取到远程模块hel 的默认拉取元数据的方式,是根据远程模块名称,到 unpkg CDN 对应的 npm 包下,获取元数据 meta_data.json 文件。这个拉取元数据的过程也可以开发者自定义。
整个流程非常简单,但难度在于,如何构建打包出代理模块和远程模块
代理模块负责以下内容:
hel 提供了 exposeLib
函数,用于读取远程模块的缓存
打包代理模块时,参考以下代码作为构建入口:
import type { LibProperties } from './你真正的模块代码';
import { exposeLib } from 'hel-lib-proxy';
// 读取远程模块缓存,远程模块名为:hel-tpl-remote-lib
export const lib = exposeLib<LibProperties>('hel-tpl-remote-lib');
// export 类型
export type Lib = LibProperties;
// export 远程模块的缓存代码
export default lib;
该入口文件主要做了以下事情:
exposeLib
,将远程模块的缓存,暴露出来以上述代码作为入口打包,实际上并没有将模块真实代码打包到产物中。因此代理模块,是一个非常小的模块,没有任何的模块逻辑。
在项目中使用远程模块 hel-tpl-remote-lib
,最后打包只会打包代理模块这一小部分代码,不会将真正的代码打包到项目的产物中,因此还能提升项目的构建速度。
真正的代码,是运行时,在 preFetchLib
拉取远程模块时加载并运行的。
只需要在 package.json
中声明 typing
字段:
{
"main": "hel_proxy/entry.js",
"typings": "typings/index.d.ts",
}
typing
的值为构建时生成的 TS 类型声明文件的路径。main
则用于声明代理模块的入口,指向的是打包后的产物。代理模块直接发布到 npm 即可,按 npm 包的用法正常引入和使用即可
远程模块的职责如下:
preFetchLib
函数,远程模块加载完成index.html
,用于提取元数据,例如提取出远程模块的入口(加载时,需要首先拉取哪些代码)要做到以上的内容,远程的模块,也需要用一个入口文件再包一层,伪代码如下:
import { libReady } from '@tencent/hel-lib-proxy';
async function main() {
// 这里是 import 真正的模块代码了
const lib = await import('./你真正的模块代码');
// 注意此处传递的是 default
libReady('hel-tpl-remote-lib', lib.default);
}
main().catch(console.error);
加载入口时立即调用 main
函数:
libReady
并传入远程模块的值,该函数会通知 preFetchLib
,远程模块已经加载完成如果一个远程模块,依赖另外一个远程模块,怎么办?
假如:hel-tpl-remote-lib
依赖 other-lib
,other-lib
为另一个远程模块。即
// hel-tpl-remote-lib 的模块代码
import xxx from "other-lib"
那就 import other-lib
前,先执行 preFetchLib
,拉取 other-lib
。这样 other-lib
的代理模块,就能正确获取到内容。
import { LIB_NAME } from '../src/configs/subApp';
import { libReady } from '@tencent/hel-lib-proxy';
async function main() {
// 如有其他远程包依赖并且需要在内部使用静态导入的语法,可使用 preFetchLib 来加载这些包体
const { preFetchLib } = await import('@tencent/hel-micro');
await preFetchLib('other-lib');
// 必须要用动态 import,因为如果当前包,还依赖其他的 hel 微前端依赖,需要 preFetchLib 之后,再进行引入。
const lib = await import('./你真正的模块代码');
// 注意此处传递的是 default
libReady('hel-tpl-remote-lib', lib.default);
}
如果存在嵌套的远程模块,就必须要用动态 import 引入真正的模块代码
await import('./你真正的模块代码')
hel 通过分析 index.html
,来提取元数据,最重要的是要提取出模块的入口脚本,因为打包产物可能会有多个文件,要确定哪个才是入口。
假如有以下 HTML:
<!doctype html>
<html lang="en">
<script>
这是一串内联 script
</script>
<script
src="https://unpkg.com/hel-tpl-remote-lib@2.0.0/hel_dist/static/js/main.5ab2b93c.chunk.js"
></script>
</html>
那么会提取到两个入口脚本:
main.5ab2b93c.chunk.js
上述 index.html
会得到以下元数据(节选):
{
bodyAssetList: [
{
"tag": "script",
"attrs": {
"src": "https://unpkg.com/hel-tpl-remote-lib@2.0.0/hel_dist/hel_userChunk_1.js"
}
},
{
"tag": "script",
"attrs": {
"src": "https://unpkg.com/hel-tpl-remote-lib@2.0.0/hel_dist/static/js/main.5ab2b93c.chunk.js"
}
}
]
}
注意这里的资源路径是完整的 url 了。
preFetchLib
函数会读取元数据,然后拉取这些入口脚本。
开源版本的 hel,远程模块和元数据,同样会发布到 npm。这样就可以从 unpkg
这个 CDN,直接拉取到元数据和远程模块
从元数据的入口脚本可以看出,入口脚本的路径,已经是指向了 unpkg
以上内容,就是一个完整的 hel 的原理:
preFetchLib
拉取远程模块,然后直接可以拿到远程模块的对象难点则在于如何打包远程模块和代理模块,需要遵守特定的规范:
preFetchLib
函数,加载完成index.html
提取出入口脚本但你觉得这就完了吗?其实没有。
hel 提供了自定义拉取元数据的能力,这意味着,我们有了控制的返回元数据的能力,元数据中有远程模块的入口,因此能控制拉取的远程模块。
下面是一个例子:
元数据通过版本管理平台的接口拉取。
通过在版本管理平台上配置,可以返回的元数据的对应的远程模块版本,从而做到控制远程模块的版本号,能做到回滚,灰度等能力。
上述版本管理平台,其实在腾讯内部已经实现,但目前仍未开源,但从 github 上已经看到是计划中了
有了自定义拉取元数据的能力,这个过程就会有非常大的自由度,由此可以衍生出一个非常大的微模块生态。理论上可以做到但不限于以下的效果:
不过截止目前(2022.12.13),开源 hel 目前提供的部署方式,只是部署到 unpkg CDN 上,对于公司项目来说,不太适合,需要提供更多的最佳实践;它的开源生态,也有待完善。
但不得不承认的是,hel 的整个思路,的确是较为优秀,值得学习和研究, 能够作为一种优秀的远程模块/微模块方案。
最后也希望 hel 能越做越好吧~
如果这篇文章对您有所帮助,可以点赞加收藏👍,您的鼓励是我创作路上的最大的动力。
也可以关注我的公众号订阅后续的文章:Candy 的修仙秘籍(点击可跳转)
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。