关于微前端实现原理与ngx-planet(一)

微前端? 简单来说 从使用角度考虑 D应用是由 ABC三个应用/组件组合而成,通常在Angular/Vue/React单项目中很容易实现,但为了复用解耦,D应用现由3个独立部署并带有通信机制的应用/组件组合而成。 从部署角度考虑 A,B,C,D为并行四个打包后的静态文件,当有E应用使用A,B,C,D应用中的组件或者事件时通过类eureka 服务发现注册的方式去复用组件或应用。 当然,这只是众多思路中的一种 当然,这只是众多思路中的一种 当然,这只是众多思路中的一种 好处: 应用自治: 只需要遵循统一的接口规范或者框架,以便于系统集成到一起,相互之间是不存在依赖关系的。 单一职责: 每个前端应用可以只关注于自己所需要完成的功能。 技术栈无关: 你可以使用 Angular 的同时,又可以使用 React 和 Vue。 这就好像使用k8s集群和grpc调用一样 架构模式 基座模式: 通常有一个main/portal应用来充当基座,提供基础服务,剩下的应用可插拔在基座上。好像dashboard和widget的关系 自组织模式: 各个应用平级不存在相互管理 实现思路 基于基座模式的微服务无非是 服务发现,服务注册,服务调用等功能 基座应用: 主要应有注册表,通过各个应用标识存储key:component|application 以应对路由不通渲染哪个应用 工程逻辑/应用管理/加载: 先看成一个黑盒 路由分发: 通过对url规则和分析出渲染哪个应用/组件,经过黑盒渲染到需要渲染的dom上 难点 Load,决定加载哪个应用,并绑定生命周期 bootstrap,获取静态资源 Mount,安装应用,如创建 DOM 节点 Unload,删除应用的生命周期 Unmount,卸载应用,如删除 DOM 节点、取消事件绑定 单个浏览器多个应用还需做到 状态|css 共享/隔离...

December 5, 2021 · 8 min · cui

关于微前端实现原理与ngx-planet(三)

1.为什么要服务端渲染 因为公司后端服务在k8s上,是分布式的微服务,之前端全部打包部署在了物理机器(虚拟机)nginx上,如果通过helm做应用商店的话,nginx前端这部分无法处理,包括灰度部署,CI等,全部都只能做到接口级别的处理,并不能连带静态资源文件一起处理,所以基于分布式的前端整改迫在眉睫。 偶然发现了ngx-planet,整篇文章基于前几篇文章,可以看之前的几篇文章。 2.如何基于ngx-palnet进行服务端渲染 2.0 有路由前缀的情况下服务端渲染ngx-planet如何改进 在 start函数中监听路由阶段,其中的 startWith过滤路由要把 location.pathname修改好,要将前缀去除掉,至于如何动态去除不写死,仁者见仁智者见智。 2.1 首先,准备打包好的静态文件 将 build命令修改,注意 --deploy-url的意思是,打包完成后,静态资源路径是什么 1 2 "build": "ng build --prod --deploy-url=/static/star-universe/ --base-href=/star-universe", 打包后的index.html如图,静态资源路径变成了 /static/star-universe前缀,这里和 base-href不能冲突,否则在渲染时有死循环问题 其次 base-href就是项目访问路径前缀 然后修改 angular.json中的 build放到你的静态资源目录,这样在执行 npm run build后静态资源自动放入后台项目中的静态目录中 2.2 准备Portal后台项目 我的项目基于SpringBoot自动生成,项目结构如下 以下是用到的maven配置文件 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 <?...

December 5, 2021 · 2 min · cui

关于微前端实现原理与ngx-planet(二)

道标 准备好源码,然后跟着文章去看代码,在每个代码块的第一行,我都把 filename 写上了,并且打开了 gitalk。 项目结构 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 - packages/planet |--src |--application |--planet-application-loader.spec.ts |--planet-application-loader.ts # 应用加载器 |--planet-application-ref.spec.ts |--planet-application-ref.ts # 应用的引用 |--planet-application.service.spec.ts |--planet-application.service.ts # 应用逻辑处理Service |--portal-application....

December 5, 2021 · 26 min · cui

关于微前端实现原理与ngx-planet(四)

客制化 由于公司和公司的业务不同,所以在ngx-planet的基础上,需要作出一些针对于业务的拓展 目前分出四个基础项目 @yunzai/stars:封装了用户认证,元素权限,i18n等系统初始化信息的内容,需要发包的,意为繁星. star-universe: portal项目,所有子前端项目的入口,意为宇宙. star-dust:一些可能会通用的components都放到这个项目里,统一管理,意为星尘. star-uranus:模版项目,意为天王星. 开发环境 可以看到桌面共有四个编辑器,开发时需要跑起其中三个项目. star-universe,star-dust,star-uranus @yunzai/stars 因为是基础包,所以扩展了哪些功能点,先做一个介绍,因为发包,所以planet前缀都被我改名成为了star前缀,针对于ngx-planet加载过程请看前一篇link start。 接下来看项目结构 首先基于ngx-planet加入了auth,config,i18n,providers,stomp,token,user这些文件夹 module 针对于Module做出了以下改良 加入了TranslateModule来写i18n 加入了Inject的静态配置类StarConfig 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 /* * @Author: ferried * @Email: harlancui@outlook....

December 5, 2021 · 3 min · cui