如何接地气地接入微前端?

摘要:
对于现有站点,如何访问基于旧技术堆栈的微前端?我们必须对存量技术堆栈保持敬畏,隔离影响范围可控的基本要素,然后考虑实施微前端方案。因此,在这一基本要素和指导方针下,为了实施这项新技术,有必要充分了解现有技术解决方案和当前改造场地的比例,以及当前成熟的微型前端框架提供的能力差异。),我们仍然需要制定这样的着陆计划。

简介: 微前端带来明显好处的同时,也面临着痛点。对于已有站点,如何在老的技术栈基础上接入一个微前端?需要哪些通用功能?如何解决插件机制?本文分享一种微前端的接入方案和实现细则。

如何接地气地接入微前端?第1张
一 、前言

微前端,这个概念已经在国内不止一次的登上各大热门话题,它所解决的问题也很明显,这几个微前端所提到的痛点在我们团队所维护的项目中也是非常凸显。

但我始终认为,一个新的技术、浪潮,每每被讨论最热门的一定是他背后所代表的杰出思考。

"微前端就是...xx 框架,xx 技术"

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

在我所负责的项目和团队中,已经有非常大的存量技术栈和页面已经在线上运行,任何迭代升级都必须要保证小心翼翼,万无一失。

可以说,从一定程度来讲,微前端所带来的这些好处是从用户体验和技术维护方面的,对业务的价值并不能量化体现,落地这项技术秉着既要也要还要的指导方针。

我们对存量技术栈一定需要保持敬畏,隔离,影响范围可控的几个基本要素,然后再考虑落地实施微前端方案。

所以,在这个基本要素和指导方针下,要落地这项新的技术,一定要充分了解当前改造站点所存在的技术方案、占比以及当前成熟的微前端框架已提供的能力差异,切勿生搬硬套。

二 、背景

我所在团队维护的项目都是些 PC 操作后台(Workstation),这些工作台会存在不同的国家,不同时区,不同合作方等等问题。

如果需要开发一个新的页面需求,很可能投入进来的开发人员都来自不同团队,此时我们要在完成现有需求的同时还需要保证多个管理页面的风格统一,设计规范统一,组件统一,交互行为统一这非常困难。

当该业务需要迁移到另外一个工作台时,虽然需要保持逻辑一致,但导航栏、主题等却不同。

当前存量的方案都是采用 Java 直接进行 Template 渲染出 HTML,经过前面几代前辈的迭代,不同系统中已经存在几种不同技术栈产出的页面。

虽然都是 React 来实现的,但是前辈们都非常能折腾,没有一个是按照常规 React 组件形式开发出来的。

比如:

  • 大部分页面是通过一份 JSON 配置,消费组件生成的页面。
  • 部分页面是通过另外一个团队定义的 JSON 配置消费组件生成的,与上面 JSON 完全不一样。
  • 还有一部分页面,是通过一套页面发布平台提供的 JS Bundle 加载出来的。

面对这样的技术背景下,除了微笑的喊 MMP,含泪说着自己听不懂的话(存在即合理,不难要你干嘛?),还得接地气地出这样一个落地方案。

三 、方案 & 流程图

首先,需要明确的分析出站点所有页面,所需要加载的通用特性:

如何接地气地接入微前端?第2张

上述是精简过后的一些通用功能特性,这里简单做下介绍:

  • Layout Loader:用于加载不同工作台的导航
  • DADA Loader:用于加载 JSON 配置的页面
  • Source Code Loader:用于加载 JS Bundle
  • Micro Loader:用于处理微前端加载
  • Log Report:用于日志埋点
  • Time Zone:用于切换时区
  • i18n:用于切换多语言
  • Guider:用于统一管控用户引导

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

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

粗略统一归类后来看,页面的大体加载流程应该是这样:

如何接地气地接入微前端?第3张
四、 实现细则

基于上述一个加载思路,首先需要做的是页面加载路径收口,需要保证所有页面的加载入口是在一个统一的 Loader 下,然后才可以较为系统的处理所有页面的加载生命周期。

在收敛的同时,同样需要保持开放,对核心加载路径要保持插件化开放,随时支持不同的扩展能力,渲染技术栈接入。

1 、插件机制

所以,在主路径上,通过 Loader 加载配置进行处理,这份配置在主路径中提供上下文,然后交由插件进行消费,如图所示:

如何接地气地接入微前端?第4张

举个例子,拿一个独立的 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 、安全迁移

对于我所在团队负责的项目来说,万万做不得一刀切的方案,所以针对现有存量页面,需要完整分析当前存量技术栈:

如何接地气地接入微前端?第5张

针对上述存量页面来说,需要从左到右分批进行页面级别控制上线部署,对于左侧部分页面甚至需要做些项目改造后才可部署接入上线。

这类迁移测试需要处理出一套自动化 e2e 测试流程,通过分批迁移同时梳理出 微前端注册表 。

有了这两项流程保证及范围控制,当前方案所上线内容完全可控,剩下要处理的大部分就是较为重复的体力活了,覆盖率也可量化。

3、 微前端形态

按照上述方案迁移,那么预期的微前端形态将会是:

  • 每个开启微前端的页面都可成为主应用。
  • 微前端是插件可选项,如果因为微前端导致的业务异常可随时关闭。
  • 同为微前端的页面路由相互之间切换可实现局部刷新形态,而跳转至非微前端注册表中的页面则会直接页面跳转。随着微前端页面覆盖率提高,局部刷新的覆盖率也会逐渐提高。
  • 可通过不同扩展插件,加载不同技术栈类型的存量页面,转换为对应子应用。
如何接地气地接入微前端?第6张

在 SchemaResolver 中的注册和调用路径如下:

如何接地气地接入微前端?第7张
五 、总结

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

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

当前,通过 SchemaResolver,可以针对不同角色提供不同的开放能力:

  • 针对平台管理员,提供插件能力开放全局扩展能力。
  • 针对页面开发者,提供标准化接入方案路径,提供多种技术栈接入能力,并无感知提供微前端,多语言,埋点,菜单,主题加载等能力。解耦了不同系统公共能力,同时,这种方式可以让页面开发者快速将具体业务逻辑迁移到其他平台。
  • 针对第三方接入者,不需要关心了解系统菜单、主题接入方式,提供统一的接入口径,通过微前端隔离技术栈、隔离子应用样式。最后通过统一的页面系统管控,轻松入住对应平台,同时可以全局看到站点页面情况。

作者:开发者小助手_LS

原文链接

本文为阿里云原创内容,未经允许不得转载

免责声明:文章转载自《如何接地气地接入微前端?》仅用于学习参考。如对内容有疑问,请及时联系本站处理。

上篇小米手机_如何打开开发者模式?8266station初始化和智能配网问题下篇

宿迁高防,2C2G15M,22元/月;香港BGP,2C5G5M,25元/月 雨云优惠码:MjYwNzM=

相关文章

四: 使用vue搭建网站前端页面

---恢复内容开始--- 在搭建路由项目的时候的基本步骤 一:创建项目   安装好vue 搭好环境 (步骤在上篇博客中)   进入项目目录      cd   目录路径/ 目录名   创建项目          vue init webpack  项目名   效果:   项目文件结构:及作用    -- build...

前端框架现状调查

转自:前端框架现状调查        Ashley Nolan是来自英国食品速递公司JUST EAT的一名资深Web UI工程师。为了了解整个前端开发社区当前的知识和使用水平,他发起了一个面向前端开发人员的调查,问题涉及CSS、“任务执行器(Task Runner)”、JavaScript等方面。前期,他收到了649份回复。近日,参与者数量达到了1044。...

基于NodeJS的全栈式开发

随着不同终端(Pad/Mobile/PC)的兴起,对开发人员的要求越来越高,纯浏览器端的响应式已经不能满足用户体验的高要求,我们往往需要针对不同的终端开发定制的版本。为了提升开发效率,前后端分离的需求越来越被重视,后端负责业务/数据接口,前端负责展现/交互逻辑,同一份数据接口,我们可以定制开发多个版本。 这个话题最近被讨论得比较多,阿里有些BU也在进行一些...

结合丰富示例深入讲解Ajax架构和最佳实践——《深入Ajax:架构与最佳实践》

媒体评论 “本书不仅介绍了编程技术,而且全面讲解了Ajax应用程序的生命周期。如果你想成为一名专业的前端开发人员,一定会被本书中关于架构的真知灼见和最佳实践深深打动。” ——Andi Gutmans ,PHP创始人暨Zend技术公司CTO “本书循序渐进地讲述技术背后的最佳设计和实践,包括很多好的模式和实践。”                    ...

浅谈前后端分离与实践 之 nodejs 中间层服务

一、背景 书接上文,浅谈前后端分离与实践(一) 我们用mock服务器搭建起来了自己的前端数据模拟服务,前后端开发过程中只需定义好接口规范,便可以相互进行各自的开发任务。联调的时候,按照之前定义的开发规范进行数据联调便可以了。前后端的职能更加清晰: 后端 前端 提供数据 接收数据,返回数据 处理业务逻辑 处理渲染逻辑 Server-side...

1-1 sacc(scss)入门

定义: CSS 预处理器定义了一种新的语言,其基本思想是,用一种专门的编程语言,为 CSS 增加了一些编程的特性,将 CSS 作为目标生成文件,然后开发者就只要使用这种语言进行编码工作。 通俗的说,“CSS 预处理器用一种专门的编程语言,进行 Web 页面样式设计,然后再编译成正常的 CSS 文件,以供项目使用。CSS 预处理器为 CSS 增加一些编程的特...