关于前端:如何接地气地接入微前端

4次阅读

共计 3475 个字符，预计需要花费 9 分钟才能阅读完成。

简介：微前端带来显著益处的同时，也面临着痛点。对于已有站点，如何在老的技术栈根底上接入一个微前端？须要哪些通用性能？如何解决插件机制？本文分享一种微前端的接入计划和实现细则。

微前端，这个概念曾经在国内不止一次的登上各大热门话题，它所解决的问题也很显著，这几个微前端所提到的痛点在咱们团队所保护的我的项目中也是十分凸显。

但我始终认为，一个新的技术、浪潮，每每被探讨最热门的肯定是他背地所代表的卓越思考。

“ 微前端就是 …xx 框架，xx 技术 ”

这种话就有点把这种卓越的思路说的局限了，我只能认为他是外行人，来蹭这个词的热度。

在我所负责的我的项目和团队中，曾经有十分大的存量技术栈和页面曾经在线上运行，任何迭代降级都必须要保障小心翼翼，十拿九稳。

能够说，从肯定水平来讲，微前端所带来的这些益处是从用户体验和技术保护方面的，对业务的价值并不能量化体现，落地这项技术秉着既要也要还要的指导方针。

咱们对存量技术栈肯定须要放弃敬畏，隔离，影响范畴可控的几个基本要素，而后再思考落地施行微前端计划。

所以，在这个基本要素和指导方针下，要落地这项新的技术，肯定要充沛理解以后革新站点所存在的技术计划、占比以及以后成熟的微前端框架已提供的能力差异，切勿生吞活剥。

我所在团队保护的我的项目都是些 PC 操作后盾（Workstation），这些工作台会存在不同的国家，不同时区，不同合作方等等问题。

如果须要开发一个新的页面需要，很可能投入进来的开发人员都来自不同团队，此时咱们要在实现现有需要的同时还须要保障多个治理页面的格调对立，设计规范对立，组件对立，交互行为对立这十分艰难。

当该业务须要迁徙到另外一个工作台时，尽管须要放弃逻辑统一，但导航栏、主题等却不同。

以后存量的计划都是采纳 Java 间接进行 Template 渲染出 HTML，通过后面几代前辈的迭代，不同零碎中曾经存在几种不同技术栈产出的页面。

尽管都是 React 来实现的，然而前辈们都十分能折腾，没有一个是依照惯例 React 组件模式开发进去的。

比方：

大部分页面是通过一份 JSON 配置，生产组件生成的页面。
局部页面是通过另外一个团队定义的 JSON 配置生产组件生成的，与下面 JSON 齐全不一样。
还有一部分页面，是通过一套页面公布平台提供的 JS Bundle 加载进去的。

面对这样的技术背景下，除了微笑的喊 MMP，含泪说着本人听不懂的话（存在即正当，不难要你干嘛？），还得接地气地出这样一个落地计划。

首先，须要明确的剖析出站点所有页面，所须要加载的通用个性：

上述是精简过后的一些通用性能个性，这里简略做下介绍：

Layout Loader：用于加载不同工作台的导航
DADA Loader：用于加载 JSON 配置的页面
Source Code Loader：用于加载 JS Bundle
Micro Loader：用于解决微前端加载
Log Report：用于日志埋点
Time Zone：用于切换时区
i18n：用于切换多语言
Guider：用于对立管控用户疏导

除此以外可能还会存在以下这些页面扩大能力：

安全监控
流量管控
弹窗管控
问卷调查
答疑机器人

粗略对立归类起初看，页面的大体加载流程应该是这样：

基于上述一个加载思路，首先须要做的是页面加载门路收口，须要保障所有页面的加载入口是在一个对立的 Loader 下，而后才能够较为零碎的解决所有页面的加载生命周期。

在收敛的同时，同样须要放弃凋谢，对外围加载门路要放弃插件化凋谢，随时反对不同的扩大能力，渲染技术栈接入。

1、插件机制

所以，在主门路上，通过 Loader 加载配置进行解决，这份配置在主门路中提供上下文，而后交由插件进行生产，如图所示：

举个例子，拿一个独立的 JS Bundle 类型的子利用来说：

<div id="root"></div>
<script src="https://cdn.address/schema-resolver/index.js"></script>
<script src="https://cdn.address/schema-resolver/plugin/layout.js"></script>
<script src="https://cdn.address/schema-resolver/plugin/source-code.js"></script>
<script src="https://cdn.address/schema-resolver/plugin/micro-loader.js"></script>
<script src="https://cdn.address/schema-resolver/plugin/i18n.js"></script>

<script>
  SchemaResolver.render(
    {
      micro: true,
      host: "dev.address",
      hfType: "layout1",
      externals: ["//{HOST}/theme1/index.css"],
      // host is cdn prefix, the resource maybe in different env & country
      resource: {
        js: "/index.js",
        css: "/index.css",
      },
    },
    {container: document.querySelector("#root") }
  );
</script>

通过上述的 Plugin 引入，即可开启和生产不同的配置。

这里引入了 Layout Plugin，该插件会生产 hfType 字段而后去加载对于的 Layout 资源提供 Container 交给下一个环节。

依照配置，以后页面开启了微前端，那么 Micro Loader 将会生产提供下来的 Container，而后建设沙箱（这里基于 qiankun），再提供 Container 进去。

最初交由 SourceCode Plugin 进行 Bundle 加载运行和渲染。如果这里是另外一种渲染协定或者技术栈，则能够依据不同配置交由不同插件生产 Container。

这个过程中，每个环节的插件是不依赖的，可插拔的。

比方：

如果不加载 Layout Plugin 将不会生产 hfType 字段，也就不会将 Layout 插件逻辑注入到 getContainer 办法中，那么将间接失去由最外层下穿的 Container 进行渲染，也就不会有菜单相干透出。

如果不加载 Micro Plugin 同样不会有微前端的逻辑注入，也就不会建设沙箱，那么页面渲染流程将会依照惯例模式持续运行。

2、平安迁徙

对于我所在团队负责的我的项目来说，万万做不得一刀切的计划，所以针对现有存量页面，须要残缺剖析以后存量技术栈：

针对上述存量页面来说，须要从左到右分批进行页面级别管制上线部署，对于左侧局部页面甚至须要做些我的项目革新后才可部署接入上线。

这类迁徙测试须要解决出一套自动化 e2e 测试流程，通过分批迁徙同时梳理出微前端注册表。

有了这两项流程保障及范畴管制，以后计划所上线内容齐全可控，剩下要解决的大部分就是较为反复的体力活了，覆盖率也可量化。

3、微前端状态

依照上述计划迁徙，那么预期的微前端状态将会是：

每个开启微前端的页面都可成为主利用。
微前端是插件可选项，如果因为微前端导致的业务异样可随时敞开。
同为微前端的页面路由相互之间切换可实现部分刷新状态，而跳转至非微前端注册表中的页面则会间接页面跳转。随着微前端页面覆盖率进步，部分刷新的覆盖率也会逐步进步。
可通过不同扩大插件，加载不同技术栈类型的存量页面，转换为对应子利用。

在 SchemaResolver 中的注册和调用门路如下：

透过技术看实质，微前端所代表的卓越思维，才是真正解决具体问题关键所在，只有解决了具体的业务问题，这项技术才有价值转换。

不要为了微前端做微前端，不要为了小程序做小程序。

以后，通过 SchemaResolver，能够针对不同角色提供不同的凋谢能力：

针对平台管理员，提供插件能力凋谢全局扩大能力。
针对页面开发者，提供标准化接入计划门路，提供多种技术栈接入能力，并无感知提供微前端，多语言，埋点，菜单，主题加载等能力。解耦了不同零碎公共能力，同时，这种形式能够让页面开发者疾速将具体业务逻辑迁徙到其余平台。
针对第三方接入者，不须要关怀理解零碎菜单、主题接入形式，提供对立的接入口径，通过微前端隔离技术栈、隔离子利用款式。最初通过对立的页面零碎管控，轻松入住对应平台，同时能够全局看到站点页面状况。

作者：开发者小助手_LS
原文链接
本文为阿里云原创内容，未经容许不得转载

正文完