原题目:若何面向未来和浏览器规范设计 DDD 框架

我们是谁?

首先先先容一下我们的团队:我们是一个已经有百号人的前端团队,我们的同砚也遍布在北京、上海、杭州以及北美这些地方,这些都市都有我们的 base,我们在做的事情,是致力于提供互联网商业变现的更佳解决方案,践行“信息缔造价值”理念。在这里,你将对接字节跳动百亿流量的全产物矩阵,见证公司全新营业线的孵化生长,支持公司千亿规模的收入增进。在这里的每一分每一秒,你都能亲自感受到字节跳动的蓬勃生机。

虽然我们是营业团队,但我们也在做许多与时俱进的手艺建设,其中包罗有:前端现代化工程化系统升级、Node 能力探索、一键式 CD 工具、组件服务化、前端国际化通用解决方案、可视化页面搭建系统、商业智能 BI 系统、前端自动化 E2E 测试、面向未来的微前端设计模式等等。 在支持营业不停演进的历程中,我们实验不停探索手艺赋能营业的更优实践。而且在分享的最后也有我们的福利环节噢,我将为人人献上咱们团队的内推绿色通道,若是人人听完我的分享,以为我们在做的事情很有趣,而且你也想和我们一起做手艺,并在做手艺的历程中实现落地,那就迎接快来投递哟。

人人看到的上面这张图,就是我们的“海景”工位,可以俯瞰海淀的景物以及远处的北京,稀奇惬意。

提要

接下来就是今天分享的主题,这是整个分享的纲领。虽然说今天我们是在先容一个我们自己沉淀的解决方案,然则我们不会把太多的篇幅放在我们的解决方案的先容以及宣传上,今天的分享,更多地是和人人一起回到我们刚做这件事的起点,一起重新去不停以解决问题的思绪挖掘现阶段前端手艺热门的现实价值

以是分享内容主要是分为 4 个部门:

第一个环节: 透过征象看本看本质

为什么微前端会火?

实在现如今微前端的观点早已经不是什么新鲜的词了,业内也有许多实现优异的实现或者框架和库。好比我们第一类中的 Shoelace,借助一些特定实现或者浏览器的一些原生能力,例如浏览器提出的 Web Components 规范,能够产出一套抹平框架的组件库;Webpack5 推出的 Module Federation 能力,也再一次把微前端理念推上了“热搜”,许多业内的同寅都以为,他或许会成为微前端在生产中更进一步的“银弹”;固然,也有一些已经被投放在生产中的实践,好比以 single-spa 为焦点支持起的传统“微前端”解决方案,基于它封装的优异实现 Qiankun,一直都是最近微前端生态中的热门。

那在这历程中对微前端感兴趣的同砚是否有去思索过一个问题:为什么微前端在已往一段时间会火起来呢,或者说,微服务这样一套后端设计,前端工程师们又在其中发现了什么价值而让这么多人热衷于此呢?是人人在追赶手艺噱头,照样真的有迫切需要这项手艺去解决的问题呢?我们带着这些问题,透过这个征象去看一个在我们的一样平常开发中,经常会遇到的一个案例:

我们经常会沉淀一些营业组件(若是你的逻辑对照优雅可抽象?),当其余同砚或者系统有同样的实现需求时,就会希望复用我们的组件能力,最简朴的方式可能就是 copy 对应的代码或者文件,固然若是是更优异的实践的话,我们会把可复用的组件打成一个 npm package,配上友好的文档,也可以快速供应其他同砚快速复用。这也有了业内最近很常见的组件库、组件市场已经物料市场等等平台,然则有一天,这样看似稳固的逻辑复用历程迎来的一个新的挑战:

有一个使用 Vue 的团队以为我们的实现很优异,他们也希望能复用我们已经梳理好的这样一个营业组件,这时刻问题就来了:我们通过 React 手艺栈编写的组件,怎么才气更友好地被 Vue 团队所复用呢?

固然问题一定是有解决方案的, ReactDOM.render 可以辅助我们实现跨框架复用组件挂载的能力,然则我们也需要分外去处置 props 的通报以及转变的监听,可能要使用像全局变量状态治理机制或者一些事宜模式,才气把这样原有的能力去支持起来,否则组件的传参机制相当于就无法使用了。 复用的流程似乎更先变得庞大了起来。

组件的跨框架复用问题对于组件库而言可能要加倍显著,以是为了更好地解决开发者的使用体验,一个优异的组件库可能不得不产出基于差别框架的多套组件库,好比说我们对照熟悉 antd,它就有 antd-react 和 antd-vue 这样针对两大差别框架的两个版本,但实在它们的交互或者说功效基本都是类似的。同理,在许多我们开发的历程中,也会遇到“看到了一个实现优异的组件,很贴合我们的需求,然则 Vue 却成为了它原罪,由于团队的手艺栈是 react”。

以是这里可以总结一下,一个想要多框架兼容的组件库投入成本,更多时刻是: 人力* 时间* N(框架种类)。随着前端生长,最近有 Svelte 等框架也逐步泛起,以是未来是不是 N 的数目就会逐步增添了。

然则在这个时刻我们不禁会发生一个疑问,人人不知道也有没有过这样的思索:**本质上前端的器械都是 HTML、CSS和 *** ,为什么前端似乎越生长复用能力越弱了呢?**好比说上到一个完整的系统,下到一个小而轻的组件,手艺上的差异实在往往成为了它们复用能力的护城河。

以是实在在这样的一个场景下,我们所熟悉的微前端的方案就应运而生了。综上所述,对于那些面向更广手艺栈的组件或者系统所需要的,就是在逻辑抽象或者复用的历程中,前端工程师们不需要思量语言是什么,框架是什么,亦或是原本的项目环境是什么。

探寻本质

那若是我们想要明白微前端系统是什么,就得深挖微前端或者说前端微服务的本质,到底是什么。我们得先来思索一个问题:微前端焦点理念中的 微服务,它的本质是什么,要怎么明白 DDD 模式在前端领域的运用?

我们可以先看下后端微服务的实现是怎样的。后端的微服务的实现,实在就是把能够自力的逻辑抽象成实体,来让它到达更天真的“可插拔”复用性,不用思量语言,不用思量框架,甚至不用思量环境(基于 Docker),和我们最初的预期很相符。就如我们图中的示例所示,一个庞大系统中的各项服务,都可以拆分成单一实体,封装成镜像之后,可以被带到任何需要它的地方实例化以便复用。就像我们图中所示,一个庞大系统内里它可能有各项服务,好比登录、数据剖析这些服务,都可以被拆分成单例实体,封装成镜像之后,它就可以被带到任何地方去复用。维护的时刻,开发者可能只要更专注于它这样的一个抽象出来的单体服务。

以是我们是不是可以这样子去总结: 在编程的天下中最主要的是抽象能力。以是微服务的革新历程,本质上就是抽象的历程。

若是我们探寻到了这样的一个微服务的这样的本质之后,那又要若何去明白前端微服务呢?以是凭据适才这样思绪,我们可以实验一个更勇敢的想法:前端的微服务,不但单指一个系统,或者说是一个网页,正如后端微服务的设计理念一样,实在前端网页上的随便部门或者说随便结构、随便元素,都能被抽象成为一个微服务的实体,在其他系统或者网页中快速集成复用,与现在的组件化模式差别,微服务的形式,更在于让这些抽象不再需要思量语言是什么,框架是什么。但实在本质上,微前端也是实现组件化理念的一种形式,也可以说,是组件化系统中的一个子集。

那业内或者社区是不是已经有成熟的微前端解决方案能够解决上述问题了呢?就像我们一更先所说的,实在社区上已经有许多实现优异的产物了。那我们就一起来深入剖析一下吧。

这边我直接抛一个我们剖析后的结论吧:实在社区竞品都很优异,能解决问题,但照样能总结出一点,就还不够丝滑。可能人人看到这里就会以为有些争议,咱们先不着急,待我们细细品来。

路由驱动式微前端实现

这里就拿我们以为实现更优异的框架之一 —— single-spa 举例,之以是我们会这么以为,缘故原由在于业内稀奇是许多海内各家公司的最终解决方案,或是像 qiankun 这样优异的微前端框架,都是基于 single-spa 建设或者封装的,以是至少说在海内,是很具代表,或者很有参考价值的。

Single-spa 有一个特点: 它是一个路由驱动式的前端框架,实在现在许多微前端框架都是以这种路由驱动式的这样焦点去实现的。我们也看到左边图上贴出来的这样的一个示例代码,本质上我们需要给一些我们的路由或者是我们的一系列服务,去注册好一些特定名称的生命周期(好比 mount、bootstrap 等等)并 export 出去,这样就完成了一个微应用的封装的历程。第二个图,就是主应用或者说微前装基座,它注册林林总总微应用的逻辑,由于它是一个路由驱动式的微前端框架,以是我们需要声明哪些路由需要去激活哪些微应用,以是 Single-spa 的原理焦点我们可以从官方的 Demo 中看出,它就是在路由转变时判断激活和销毁应用,通过触发子应用对应的生命周期来实现应用切换的历程。

以是综上所述我们可以发现,实在 single-spa 已经能够承接很大一部门的微前端解决方案了,得益于生命周期的设计,开发者完全可以自由设置子应用的渲染逻辑,这样就能到达抹平框架的效果。固然,针对上述的剖析,我们也可以总结出 single-spa 在实践中的几个痛点:

  1. 主应用需要感知庞大的子应用的注册以及调剂逻辑,包罗像 Single-spa 内里,它也是封装了一些好比监听路由转变的事宜,然后去调剂,包罗我们需要对主应用或者微前端基座应用去做这样的一个逻辑,来支持子应用的一系列的调剂能力。好比说刚刚我们注册路由的逻辑也是一部门,实在并不是很“丝滑”,虽然在框架层已经帮你做了,然则我们真正在实践 Single-spa 的时刻,我们的更大部门的事情量投入往往不是在子应用的封装上,我们更多的时刻是在搭主应用。

  2. 子应用并不直接感知父应用的状态转变。好比第一点中我们说到会有一个用于占位的 DOM。但它若是有一些好比 React 内里的 prop 的转变需要向子应用通报,我们更多时刻得通过事宜或者全局状态治理机,去完成卖力交互,来实现更新。以是这虽然说回归的 HTML 本质,由于我们最早可能都是在写林林总总的 addEventListerner,但随着 React 和 Vue 这样的框架的生长,前端开发者更习惯于这种声明式的数据通报的开发习惯。

  3. single-spa 在设计上对于微应用或者微前端的子应用的抽象粒度就是停留在路由级别,对于抽象局限有所限制,这个点自己还可以做的加倍极致。像我们最更先说的,一个微应用可以上到一个完整的系统,下到一个 Button 组件,实在都是可以被抽象的。

以是凭据我们适才剖析和总结,我们可以总结出 single-spa 以及由它延伸出的路由式驱动框架的优势和劣势:

  • 优势:对老系统的一些逻辑,好比封装好的一些系统,它可以实现快速的承接,由于它不会侵入老系统的营业,以是可以快速的去封装微应用的子应用,这也是它的亮点。

  • 劣势:我们更关注的是它的主从应用在设计上实在并不是有太大的关联。主应用更多只是完成子应用的生命周期的调剂。

以是就有了像 qiankun 这样的成套解决方案来解决一些 single-spa 层面在开发上的痛点,然则挪用执行生命周期这样的设计简直会在先天上有一些约束,而且甩掉了一些优异的原生 DOM 能力,通过监听路由级其余转变来完成应用切换,也基本表明晰 single-spa 的设计目的就是聚焦于页面级或者说是路由级的微前端应用

基于浏览器原生能力提供的微前端实现

固然业内对于微前端,另有一种这样更官方的实现方式,就是用浏览器原生提供的 Web Components API。之以是前端会进入组件化时代,亦或是厥后有微前端这一系列的组件抽象复用的观点,实在也是得益于 W3C 早在 2012 年提出的这套规范,那时刻前端似乎照样 JQ 的时代,虽然这套规范一直不温不火,而且你可能在已往时常会听到一些社区对它的吐槽,然则这套规范所转达的前端组件化设计理念,也成为了像三大框架这些现代化前端组件框架的启蒙。

实在早在 Web Components 被提出之后,很快就有一批“有志之士”投入到这项新规范的探索历程中了,在这个历程中,也产出许多极具代表性和里程碑意义的工具,就好比业内对照著名的 x-tag 另有 Polymer,借助这类框架提供的系统,你就不需要关注底层的 Web Components 若何实现,就能快速将一个你自己的营业组件“酿成”一个 浏览器原生就能支持的 HTML 标签啦~就像上图右边 x-tag 官网一个实现:它把一个时钟组件酿成了一个原生的 HTML 标签 —— x-clock,只要把这个标签插入到 HTML 内里,就能直接使用这个时钟组件了。以是基于这类框架提供的系统,你就不需要关注底层 Web Components 怎么去实现,就能够快速地使用浏览器原生 API 的能力把你的营业组件酿成一个能够让浏览器原生就支持的 HTML 标签。

不仅仅是云云,许多社区爱好者们也借鉴这套头脑产出了一些对开发加倍友好的基于 Web Components 的抹平开发系统的微前端框架,腾讯开源的 Omi 就是一个很好例子,使用 Omi 系统编写的组件,可以快速被拿到随便逻辑中去复用。

固然,甚至也有一些解决方案,连组件封装的逻辑都帮你处置好了,Shoelace 就是一个再好不过的例子了,这里的组件生态就像 Antd 一样恬静,而且比起 Antd 更恬静的是,你都不需要体贴开发的手艺栈,在引入 Shoelace 的 SDK 之后,你就可以直接通过使用原生 HTML Tag 的方式来使用这些早已帮你封装好的组件。就像它官方谁人示例,就像你若是想要使用一个它帮你封装好的 button 组件,你只要直接写一个 sl-button 就能够使用组件的能力了。

然则上述的这些基于 Web Components 的框架都有一个局限,那就是都是自建的系统,好比若是想要编写一个跨框架的组件,它们都有一套自己的 DSL,需要通过甚至一整条构建工具链来完成,就像上述的几个示例所示,若是想要快速承接已有逻辑,势必会有较大的革新或者对接成本,要么就是,你一更先就应该在这整套系统下编程。

那若是我们想要自己遵照原生的 Web Components API 封装一个微应用,这样的方案也是可行的嘛?实在一切并不庞大,这里我提供了一个快速实现一个 Web Component 的 Demo,整体的逻辑也并不庞大,也就是像十多行代码就能解决的事:

总结与思索

以是我们就在思索,有没一种解决方案既能像 single-spa 一样对原有逻辑友好,但又不限制微应用的粒度,又能复用 Web Components 的天真性,能把我们的原有逻辑酿成一个原生 HTML 标签被快速复用,这样我们的主应用也不需要有什么支持成本。

在 Magic 项目启动前,我们并没有找到这样的实践,因此我们也坚信,这或许会是一个契机。

前期调研

微前端要解决的一个焦点问题就是便捷地跨框架。那回到每个框架的本质来看,不论是 ReactDOM.render 照样 Vue.$mount 等等前端框架的渲染逻辑,虽然底层的实现纷歧定是 ,然则详细的效果,完全可以明白为就是往我们传入的 MOUNT_NODE 上 ,一个前端控件,一定是需要在页面上有一个占位符去实现挂载的。

以是,为了实现我们的想法,我们的思绪即是:用 Web Components 提供微应用的容器,借鉴 Single-spa 的设计,通过子应用生命周期等方式向用户提供自界说渲染逻辑,以便快速支持原有逻辑。而且,在运行时,实在开发者就能够快速完成上述的所有流程。

若是说到要使用 Web Components,大多数人的第一反映就是兼容性问题,以是我们首先需要明确一点,Web Components 自己不是一个规范,它是一个规范的合集,其中的明细由于实现上另有逻辑上的缘故原由,兼容性各不相同,而就我们现在的计划而言,我们最多使用到的,可能也就是 Custom Elements 和 Shadow DOM ,也都是业内许多主流框架都市使用的特征。我们先来看看官方给出的 Web Components 的兼容性讲述

而且 W3C 也提供了官方的 Polyfill,能够强化 Web Components 向下兼容的能力。实在我们可以看到像好比说 IE Edge、IE11+,包罗现代化的浏览器,实在都能在 Polyfill 的支持下完成兼容。

以是若是回到我们一更先的设计初衷,我们现在就是在做一场面向未来的探索,正如 Vue3 坚持使用 Proxy 以到达极致性能而放弃低版本 IE 一样,我们可能不会更多的去思量浏览器兼容性为我们带来的约束。就好比现如今早已成为前端基础的 ES6,在五年之前,不也还只是一份提案嘛,以是我们更希望着眼未来。因此我们以为, 手艺的探索,更主要的是向前看

,

欧博手机版

欢迎进入欧博手机版(Allbet Game):www.aLLbetgame.us,欧博官网是欧博集团的官方网站。欧博官网开放Allbet注册、Allbe *** 、Allbet电脑客户端、Allbet手机版下载等业务。

,

方案产出 —— 一个纯粹的工具函数

以是在明确了可行性以及详细的实践思绪之后,我们产出了 Magic 这样一套解决方案。这就是我们开源项目的 Github 地址,人人也可以直接上我们 Bytedance 的 github organization 里搜 magic 关键字也能快速找到,人人可以详细领会一下。以是明确了这样一个项目的可行性以及详细的这样一个实践思绪之后,我们就产出了这样一套解决方案,这个解决方案大概是什么样呢?

这套解决方案的现实形态,实在就是一个稀奇简朴而又存粹的工具函数。如下示例代码所示,你的组件,只需要用这个工具函数一包,就马上能够酿成一个 Web Components 微应用。

在这里,引入了我们的工具函数 Magic 之后,你只需要像 single-spa 那样,把你的原有逻辑(组件、区块、甚至是一个完整的营业系统)包装成一个相符 Magic 生命周期的 *** Module,而且想一个让你自己知足的 component tag name,Magic 就会自动帮你处置完剩下的所有事情。

我们生命周期的执行历程,实在和一个 HTML Element 转变历程实在是完全一致的。由于我们知道基于 Web Components,你的一个组件或者说是你的微服务、微应用,它就是最终酿成一个原生的 HTML Element。然后它就会履历好比说被 到 document 内里天生原生 DOM 等等一系列历程,在这样的历程中也会触发像 bootstrap 事宜等等生命周期。

而且在这样一套模式下,在这样一套模式下,组件的包装变得加倍天真,你可以以随便形式将你的微应用 Module 作为参数传入 Magic,不论是内陆包照样服务化的形态,只要它是相符 Magic 生命周期规范的子应用模块,export 了特定名称事宜回调。

将你的组件“服务化”起来

组件的复用人人可能会习惯性地想到发了一个 npm 包,你可以直接通过我们平时最常用的 import from 这样一个形式,就可以直接把这样的一个 *** Module 给引入进来了,这时刻你只需要通报给 magic 的第二个参数就行。

固然, Magic 解决方案,更建议或者说能让它更具现时代意义的模块加载方式,应该是服务化组件的形态。

好比现阶段我们在开发中接触最多的 UMD 形式的包,若是你的微应用 Module 已经通过 UMD 等方式部署在远端服务器上,就可以直接通过 拉取你的远端:

固然,我们并不希望 UMD 带来的 window 污染可能会造成一些不能预知的风险,而且我们也期望加倍拥抱未来的方式,好比说浏览器已经支持的通过 E *** 拉取一个远端包的方式:

这里实在有一个被民众所遗忘然则实践时稀奇好用的模块化工具 —— System *** ,若是你是使用 System *** 注册的包,那一切就变得格外简朴了,你的远端包直接通过 System.import 引入即可:

而 System *** 相比于之前的其他模块化机制的优势,也显而易见,主要是以下几点:

  1. 比起 Common *** 或者 NPM package 这样一个形式,你就不需要关注 npm install 的一个历程,这实在也是所有服务化包的优异特征,包罗人人看到 deno 以及浏览器原生的 ES Module 能力,实在前端大趋势也是更推许直接拉远端包的这样一个形式,由于 node_modules 这器械实在是太烦人了。

  2. 比起 UMD,就是你不需要去关注 window 上这样的一个全局变量污染,这也是 UMD 的这样的一个这样的一个坑,或者说是有时刻会坑到你的一个点。

  3. 比起 ES Module,实在你就不需要体贴兼容性问题了,System *** 可比 E *** odule 的兼容性要更好。

我们可以来总结一下各类型拉包机制的差异:

  • 好比说我们适才说到像好比说有一些 Local Module,好比说你内陆写一些文件,可能更多是对接这样的一个 npm 包形式的这样一个子应用。

  • 像 UMD,它是现阶段服务化组件的这样的一个通用实现,然则我们适才说到它会有一个 window 变量污染的这样一个不能预知的风险。

  • ES Module,可能会去服务化组件或者说服务化库的官方认可的未来,但现在来说,可能还会有一些兼容性的瓶颈。

  • 人人这边实在也会想到 Webpack5 的 Module Federation,这个我们一会马上就会把它单独拿出来讨论

  • 而我们最推荐的 System *** ,你既能实现服务化能力,又不用忧郁兼容问题

人人可能之前都市以为这个器械会是微前端的银弹。我们在做实践的时刻,我们发现要用 Module Federation 的能力,不论是我们主从应用,我们一定是要依托这样的一个 Webpack 构建系统支持的,或者说是我们得依赖这个系统才气把这样的一个模块化的能力去运行起来。但许多时刻好比说我们组件更多会用 rollup 或者一些更轻量的构建工具去简朴打个包,我们可能很少会在组件开发上用到像 Webpack 这么重的一些工具,然则它简直会成为像营业系统这样重量级的 web 应用之间快速去复用逻辑的一个更佳的选择,由于我们营业系统基本都是 Webpack 支持的。

而且,在 Vite 公布之后,更多的工程师都从像 Vite、snowpack 这样一些基于 E *** 的构建工具,看到了未来前端工程的基建雏形,随着浏览器对 E *** 的支持性日趋成熟,未来我们可能都不在需要基于依赖图剖析的打包工具了

以是试着问自己一个问题: 未来,一定照样 Webpack 吗?

Web Components 的局限处置

实在聊完了 Module 的加载人人是不是感受 Magic 的基本功效和逻辑都已经说完了,但实在一切在现在还并不是那么完善,我们再来看看到我们现在这一步,这个方案还存在的一些局限性。实在这个方案的基本局限泉源与 Web Components 的基本局限,主要是由于 HTML 是文本语言,文本语言中哪会像脚本语言这样有指针、引用类型的观点呢,以是我们通过可以通过 Web Components 通报的数据,只有文本类型的数据。但平时在我们的现实开发中,最经常打交道的却是那些引用类型的数据。

以是许多框架都市通过种种语法糖,来解决这个问题,以保障用户的开发体验。好比 LitElement 的例子,人人是不是以为很眼熟,和 Vue 很像对吧,有的框架会选择通过一些 DSL 在构建时或者通过运行时 AST 剖析去处置这些事情。

Magic 也提供了同样的能力为 Web Components 的传参实现了升级,但一切比你想象的要简朴的多,若是你希望像你的微前端子应用通报一个引用类型的数据,可以使用 magic 通过命名导出的 useProps 方式对引用类型的数据举行包裹,上方的示例就是我们在 React 中想要实现透传引用类型数据的实现,看起来是不是稀奇便捷。

我们也看一下最终在浏览器控制台的输出实在也是相符预期的。我们也看到了像 callback 也是一个引用类型的函数数据。

在这边我们可能需要分外弥补一点,人人可能想到好比说要解决这种只能透传字符串的问题,或者说增强这种字符串限制能力的一个方式实在就是序列化。可能也有许多人会想到,好比说我把 Function 通过一些工具序列化转化一下,或者说我把一个工具序列化一下,是不是也能实现透传。实在我们最更先也是这么去思索的,但人人会习惯性地遗漏一点,就是序列化和反序列化历程,它这个工具的引用你要怎么去做一个保障。

由于序列化之后,除非你再加一个参数才气或者一段其他内存在存放这个数据的原始指向,在序列化之后新的这个引用数据才气找到它原本的指向,否则许多判断逻辑是不是就会直接不相符预期了。不仅仅云云,像工具上的 setter、getter 这些挂在原型链的数据,也都市随着序列化所有丢失了,这实在是致命的,或者说是你这个框架,为了实现数据透传的能力把用户的数据变样了,那一定是不行的,以是我们就接纳这样的一个 useProps 的方式。这样既能保留这样一个引用,也能让人人写起来更恬静,就像写 React Hooks 一样,也加倍相符人人的编码习惯。

综上所述,实在我们使用 Magic 的流程也可以总结为以下三步:

若何保证微应用能够多方对接

我们提到微前端或者说微服务的系统中,你的微应用一定是要做到自由插拔的能力,但要实现自由插拔的话,有一个必须要解决一个问题: 若何让它能够平滑地多处对接?当微应用被拿到差别的逻辑里,可能需要有差别的这样的一个适配层,或者说胶水层来处置多方的适配,但这些逻辑一定不能耦合在微应用的焦点逻辑内里,由于他们并不是通用的。

在微服务的架构里有一个对照著名的“六边形架构”的观点,在这个架构设计中,内部逻辑不会关注外部逻辑的界说,可以通过适配器模式让统一套逻辑适配差别的对接逻辑。这样的设计能够很大水平提升统一套微应用的复用潜力,而 Magic 插件的设计,就是借鉴了这样一套架构头脑,插件在 Magic 系统中饰演的,就是适配器的角色。

这里举一个形象点的例子:例如组件市场中已经有一个其他工程师孝敬的 user-info 组件,它支持传入一个用户的名称并使用封装好的原生样式将其展示出来,这个组件能够知足网站开发者在样式和交互上的需求,然则网站从数据库中获取到的用户名称都是小写的,产物或者营业方要求网站在页面中需要把名称中的所有字符转化为大写的形式。

思量到逻辑的封装和抽象,网站开发者没必要每次都在通报名称的时刻做一遍大小写的转化,此时就可以将名称转换成大写的逻辑抽象成 Magic Plugin,通过插件机制为 magic 的数据通报历程统一增添一个数据格式化的流程。这时刻,开发者就可以直接向组件中通报从后端数据库中拿到的名称数据,不需要显式地在逻辑中执行名称的大小写转化操作,若是需要展示大写的控件,可以直接使用经由 Plugin 自界说的 user-info-upper 控件。

固然,名称转大写只是一个稀奇简朴的示例,真正在营业上的定制化实现一定会是加倍庞大的场景,这插件机制,就是为了将这个定制化的口子铺开交给开发者自由去界说。以是,当你需要在 Magic 执行时定制化一些你自己的逻辑,就可以在社区中搜索已有的,或者是自己编写一个相符你需求预期的 Plugin 来实现为 magic 原有的逻辑赋能。

固然,这些都还只是 magic 的其中一部门能力而已,我们另有更多功效等着你来探索,后续我们会不停对外产出相关的先容文档,让人人更周全、深入领会那些关于 Magic 的充满魅力的器械。

我们的焦点竞争力

人人一定都市问的一个问题,这套器械的焦点竞争力在哪或者它的优势在哪?或者也有人会问,这和像现在业内的 qiankun 比起来,或者说适才我们提到 Omi 这些,它的优势在哪呢?

我总结了一下 magic 的焦点能力,我们更多是把业内上许多优异设计都融合起来,或者说通过这些设计给到我们的一些思绪,来产出了一套让开发以及让我们以为更恬静的解决方案:

  1. 我们做 Web Components plus,就像我们适才说到 Web Components 它不能支持引用类型数据,我们把这个痛点给它解决了。

  2. 可以看到 magic 解决方案,它就是一个很纯粹的运行时函数。人人也知道函数是一等公民,以是你想要对这个函数做怎样的上层封装,完全都是自界说的或者是很有想象力的,以是你可以把 magic 封装成任何相符你预期的解决方案,我们公司内部也是在做这样的一套更上层的能力。

  3. 这样一个方案借鉴了 Single-spa 的设计,它能够平滑地承接原有的逻辑。得益于与 Single-spa 一样使用了生命周期的设计,以是你的逻辑只需要 export 几个特定的 Function,就可以被带到其他地方去复用了,以是这也起到了抹平框架的能力。Magic 方案给到微前端的粒度是 一切 *** Module 皆可“微”。我们也不会说只能是路由,或者说只能是一些组件,一切只要是 export 了相符 magic 生命周期的 *** Module,都可以被封装成一个微应用。

  4. 我们是完全基于浏览器的 Web Components 的原生能力。我们也是完全遵照了浏览器规范,我们没在这个历程中封装一些多余的事情,我们更多的都是把原生能力去做一个人人平时写这种 API 挪用这些重复历程做个封装。以是我们明白这样一套方案,更贴合前端生长的未来和趋势的。就像之前 jQuery,当 HTML5 出来之后,那 jQuery 不是就黯然失色了?

以是许多时刻,作为前端开发者,我们本质上是在浏览器上开发,浏览器一定就是王道。由于 Web Components 是浏览器推了良久的计划,虽然一直被诟病,或者一直有人去吐槽,然则浏览器一直坚持推进这套规范,说明一定是希望它能够做出一些事情或者能够希望它在未来能有一定的价值和作用。

而且最主要的是,若是你使用 single-spa,从上手到最终使用,你实在是需要领会 single-spa 的整套系统,包罗生命周期、注册实现、模板占位以及服务挂载,稀奇是搭建 Master 的历程中的事情,实践过的同砚一定会有感想;若是你选择使用 Web Components,你需要领会 Web Components 原生 API、领会 Web Components的各项特征、领会传参增强、领会数据更新;而若是你使用 magic,你只需要领会生命周期和 Magic 函数需要的传参,你一更先可能并不需要知道 Plugin、shadow 这些特征你就能把 Magic 的能力用起来,这是一个渐进增强的历程,当你需要使用的高阶功效和玩法越多,你可能才需要领会地越多。

到这里我们内容基本上已经讲完了,接下来我们做个简朴的总结

我们期待的未来的前端开发模式

5G 时代的来临以及 *** 传输效率的快速生长,加上 HTTP2 的多路复用能力,用户可能越来越不再需要关注资源的加载效率,这些科技基建支持起了互联网开发的新一轮“基建”,是现时代互联网开发的“经济基础”。而细化到前端模块化偏向,不仅仅是浏览器对 E *** 的支持能力在不停完善,亦或是 Deno 加载远端模块的设计,所有人都可以看到,远端包就是未来的模块化趋势,而这些实验、这些规范,正是浏览器所代表的“官方系统”。没有“经济基础”,也不会有新型的“上层建筑”,那么组件这类天真插拔的高效可复用单元,必将在这些手艺支持上,快速生长。

当我们去开发页面的时刻,我们就去物料市场内里找哪些组件已有了,就直接拿过来用了。以是 未来的前端开发,或许就只是一个“搭积木”的历程了

而且,我们也不是说想做出下一个 Shoelace 或者 Qiankun 等等另一套微前端框架或者解决方案,我们一定是希望能够让每一位前端工程师在 Magic 的能力支持下,都能够快速缔造出像 Shoelace 或者是属于自己的微前端系统。

书籍推荐,也是早早聊的一个环节。这边我就推荐两本书叫做《领域驱动设计》和《实践领域驱动设计》这两本书,但我感受实在也没太必要把这两本书看太深了,虽然这两本书讲了 DDD 的一些焦点观点,但我以为我们更多时刻是需要站在解决问题的角度去看一些方式或者说设计模式,好比我们平时会在开发中使用一些设计模式,它本质上就是为了去解决某些特定的问题。我们发现了问题之后,找到问题的解决思绪,我以为就足够了。

Allbet Gaming声明:该文看法仅代表作者自己,与www.allbetgame.us无关。转载请注明:usdt充值(www.caibao.it):若何面向未来和浏览器规范设计 DDD 框架
发布评论

分享到:

朔州网:黛玉离世宝钗隐退 宝玉转幕后凤姐最红 梦回87版红楼他们的现况出乎意料
1 条回复
  1. 卡利开户
    卡利开户
    (2021-01-17 00:04:22) 1#

    Usdt收款平台菜宝钱包(caibao.it)是使用TRC-20协议的Usdt第三方支付平台,Usdt收款平台、Usdt自动充提平台。免费提供入金通道、Usdt钱包支付接口、Usdt自动充值接口、Usdt无需实名寄售回收。菜宝Usdt钱包一键生成Usdt钱包、一键调用API接口、一键无实名出售Usdt。看上瘾了

发表评论

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。