SCI论文（www.lunwensci.com）
摘 要 ：当前许多 Web 系统和网站以及应用客户端为了满足用户个性化需求都提供了一键换肤功能,用户可以根据自 己的喜好将网站、客户端皮肤设置为喜爱的主题色。针对大型前端应用提出了基于 Vue 微前端架构以及针对该架构的无刷 新换肤设计方案,该换肤方案解决了 Web 系统主题色切换、微组件主题色切换、图片切换、第三方绘图插件,如 ECharts、 Hightarts 等主题切换问题,同时支持多套主题。
关键词 ：VUE,微前端,无刷新换肤
Design of a Non-refresh Skinning Scheme
WU Rong1. LIU Bin2
(1.No.30 Institute of CETC, Chengdu Sichuan 610041;
2.China Electronics Technology Cyber Security Co.,Ltd., Chengdu Sichuan 610041)
【Abstract】：Currently, many Web systems, websites, and application clients provide a one-click skin change function to meet the personalized needs of users. Users can set the website and client skin to their favorite theme colors based on their preferences.A design scheme for skin change without refreshing based on the Vue micro front-end architecture and for large front-end applications is proposed. This skin change scheme solves the problem of theme switching for Web system, micro component, image, and third-party drawing plug-ins such as ECharts, Hightarts, etc., and supports multiple themes.
【Key words】：Vue;micro front-end;one-click skin change
引言
微前端这一概念是近几年提出的,它的技术理念源 于后端微服务架构。微服务架构是由许多独立部署的服 务构成,每个服务按照各自的业务能力进行组织并在各 自的生命周期内构建和维护,服务之间是松耦合的关 系,服务内部是高类聚的状态。这种架构的特点就是将 分布式应用程序组成一个服务集合,各个服务分工明确 彼此独立,每个服务可以单独设计、运行、开发、部署 扩展和维护 [1],单个微服务的更新和崩溃不会影响到整 个应用,因此微服务在当前软件开发设计中,特别是中 大型系统设计以及高并发、大容量系统的应用中越来 越受欢迎 [2]。伴随前端技术的日新月异,前端在 Web 系统中发挥的角色也日益重要,从原始的静态页面到 JavaScript 实现人机交互,从传统 Web 页面到前后端分离, 从简单动画到 3D 虚拟现实,从前端浏览器到 Node.js 服务端,从展示数据到 MongoDB 取数据,短 短数十载前端技术已经发生了翻天覆地的变化 , 从界面走 向服务端,能实现的功能越来越多 , 承载的角色也越来越 丰富。借助于微服务架构,前端也提出了微前端的概念, 将不同功能的业务视图组件拆分到不同的微应用中进行 设计开发,这些前端微应用能够独立开发、部署和测 试 , 然后在同一个系统中进行集成,它们可以采用不同 的技术栈 [3], 在外部看来仍然是内聚的单个产品,而且 微前端是一种非常好的实施渐进式重构的手段和策略 [4]。
传统的 Web 管理系统一般用户用的较多的功能是 表格的增、删、改、查等功能,页面设计相对比较简单 且枯燥乏味,随着前端技术的不断发展,许多管理系统 都融入了一些新的元素如图表、动画、3D 模型等,这些元素的融入让管理系统给用户带来一些新的视觉体验 的同时给用户留下了一些深刻的印象,这一点对于互联 网网站获客、引流特别重要。而 Web 系统换肤功能可 以让用户随心设置界面风格来满足不同用户视觉需求, 同时还可以根据不同公司企业文化定制具有某种特殊意 义的皮肤。换肤不仅仅是文字、背景颜色、图片,动画、 图表也需要切换主题,这样换肤的感官才比较完整。
1 微前端架构介绍
自 2015 年兴起前后端分离开发模式后, Web 前端 承担的工作越来越多。界面的动态展示和人机交互逻辑 全部由前端完成,后端人员只需要提供对应的接口数据 即可,这种开发模式有利于让前后端人员更加专注于各 自的开发领域,在一定程度上大大提升了开发效率,同 时生产的代码质量也大大提高了。当前应用较多的前后 端分离技术有 Vue、React、Angular 等, 其中, Vue.js 由软件工程师尤雨溪借鉴 Angular.js 和 React.js 的设 计思想进行开发 [5],在国内各种互联网公司中都得到了 广泛应用。它们都采用组件化开发模式,而组件化开发 模式带来的收益就是提高了代码复用率,将代码结构变 得更加健壮,可维护性更高。一个大型前端应用一般会 涉及许多业务功能,随着业务功能的快速增加,前端逐 渐演变成了一个大型规模应用,这种应用往往被称为巨 石应用,代码库中的代码量逐日攀升,导致生产版本构 建速度越来越慢,而且任何一个细枝末节的改动都会导 致整个应用重新打包,严重影响了生产环境发布效率, 因此亟需一种解决方案来应对这种巨石应用场景,于是 便有了微前端架构。微前端的主要思想是将规模化应用 按照业务功能拆分成独立的应用,各个前端应用能够独 立开发和部署,不同的前端应用之间内部状态是隔离 的,能够通过统一的入口访问不同的应用。
目前, 实现微前端的框架主要有 Single-spa、Qiankun、 Micro-app、Moudle Federation, 它们的发展历程如图 1 所示。
基于 Vue 实现的一种微前端框架,其实现思路与 MicroApp 相似, 借鉴了 WebComponent 的思想, 通 过 vueCustomElement 与 ShadowDom 结合, 将前端 组件封装在一个类 WebComponent 中, 主应用在界面 代码中通过引用微组件标签名称就能渲染出一个前端组 件。其中, vueCustomElement 是在 WebComponent 基础上进行的二次封装的插件。如图 2 所示为基于 Vue 的微前端集成方案架构,图 2 中的组件 A1、A2、B、C 均是通过 vueCustomElement 注册的微组件, 在注册 微组件的时候必须设置微组件名称,微组件的名称需 按照一定的命名规范,如采用“Widget- 应用名 - 组件 名”的方式,这样命名的方式方便开发者能够快速识别 该组件所属的应用以及具体业务功能 [6]。
上述的微前端集成方案采用的是路由级别的微组件 集成,首先需要在主应用中注册所有的前端路由,然 后在路由信息表中设置微组件与路由的映射关系。当 URL 响应时匹配对应的前端路由并加载渲染对应的微 组件,其中微组件在加载过程中会调用静态资源以及 RESTful API,这些资源路径通过 Nginx 转发到对应的 后端应用中。微组件包需要提前打包并且部署在相应的 后端应用中,前端页面中只需要引用对应的微组件标签 以及微组件包即可。微组件渲染完毕后通过浏览器查看 微组件元素,可以看见微组件被解析为 Shadow DOM (影子节点), ShadowDOM 具有隔离特性 , 使得每个微 组件能够在各自的作用域范围内独立运行且互不干扰。 这种架构的优点是将复杂的应用系统拆分成独立的应用 子系统,而应用子系统又支持独立部署、运行、测试, 主应用根据业务需求配置相应的菜单即可,然后通过加 载微组件的方式调用子应用的静态及动态资源。这种集 成方式具有配置灵活、扩展性好、耦合度低的特性。通 过 vueCustomElement 注册的微组件还支持内部嵌套 的微组件调用,如上述架构中的应用 A 与应用 B 之间 的微组件支持相互引用,微组件定义的粒度越细越有利 于微组件复用。
2 无刷新换肤方案介绍
由于微前端在界面呈现上表现为一个内聚的单品, 来自不同应用的微组件在整体风格上应当保持一致,并 从视觉感官上微组件之间应该是无缝衔接融为一体的。 在主应用中执行切换主题操作,主应用的主题被切换时 主应用会获取当前微组件的 Vue 实例对象然后触发微 组件换肤, 一键换肤的流程如图 3 所示。
不同的微组件会产生一些公共的样式如布局样式、 UI 组件样式(如按钮、表单、模态框、表格)等样式。 将这些公共的样式从微组件中剥离开来形成一个公共样 式文件。这样做的优点是微组件打包的时候不需要构建 公共样式, 一般情况下公共样式的占比能达到 70% 左 右,大大减小了打包体积,而且不同的微组件引用的公 共样式来自同一个样式表会使界面风格表现更加一致。 除了公有样式微组件会产生一些私有的个性化样式,这 些样式是组件独有的不应当被其他微组件引用,但是 CSS 样式表文件是全局共享的,假使两个微组件定义 了相同的样式名称就会导致一些潜在的样式冲突,后面 加载的微组件样式会覆盖之前的微组件样式,因此在微 组件内部定义样式需要采用统一的命名规范。如应用 A 下面的微组件 a1 的样式采用统一前缀,命名方式为 “a-a1-xxx”,应用 A 下面的微组件 a2 的样式采用统一 前缀,命名方式为“a-a2-xxx”,遵循的规则为“应用 名称 - 组件名称 - 样式名称”的规范, 这样命名之后每 个微组件打包的样式名称均不一样,可以完美地避开样 式冲突的问题。
要做到无刷新换肤如 UI 控件颜色、图片颜色、统 计图表颜色,需要用到 Less、Sass 等 CSS 预处理语言。 Less 和 Lass 是 CSS 的扩展语言,它们可以使用变量、 函数、嵌套等方式编写样式文件,最后通过构建工具 输出浏览器可以识别的 CSS 样式。控制了颜色换肤工作,基本上就完成了一大半,将所有的颜色相关变量进 行集中定义,涉及换肤相关的样式必须绑定到对应的颜 色变量,同时将所有的颜色变量导出方便在 JavaScript 中调用。不同的主题需要预置不同的颜色变量,如深色 主题和浅色主题需要预置两个样式文件用来定义颜色变 量。构建样式文件时,不同的主题需要提供不同的样式 入口文件,入口文件应当包含整个样式文件的全量,样 式文件的最顶层需要绑定主题变量名称,如深色系打包 的样式名称为 .dark .a-a1-xxx,浅色主题打包的样式名 称为 .light .a-a1-xxx, 通过切换外层主题样式名称来实 现界面换肤。微组件主题样式文件定义以及样式文件引 用关系如图 4 所示。公共主题样式文件的定义方式与微 组件类似,只需要在主应用中构建和引用公共样式。
统计图表一般被渲染为 Canvas 元素, 它的样式不 受 CSS 样式表控制,需要通过 JavaScript 来操控实现。 在样式文件中将颜色变量统一导出然后绑定到 Vue 组 件响应式数据中使用。Dom 元素和 Canvas 元素主题 切换原理如图 5 所示。
(1)组件初次渲染流程 ：首先, 绑定默认主题变量 至 Data,组件开始 Render ;然后, Vue 组件渲染过程 中触发 Data 中的 Getter ;最后, Watcher 收集。
(2)Dom 元素视图更新流程 ：首先,主题颜色切换 触发 Data 中的 Setter 通知 Watcher ;然后, Watcher 收 到通知触发视图更新 ;最后,视图重新渲染。
(3)Canvas 元素更新流程为 ：首先,主题颜色切换 触发 Data 中的 Setter 通知 Watcher ;然后, Watcher 收到通知直接调用 Canvas 绘图方法重新绘图。
3 结语
该微前端无刷新换肤方案通过灵活配置颜色变量 可以轻松构建出多套主题样式表,通过微前端框架实 现主应与微组件之间的消息通信, 再利用 Vue 响应式 更新机制实现微组件无刷新换肤功能。微前端架构将 前端工程分解为以业务为主导子应用,子应用将独立 部署、独立扩展,使得整个微前端应用可维护性和容 错性更好。
参考文献
[1] THONESJ.Microservices[J].IEEE Software,2015.32(1): 116.
[2] 张国生.基于领域驱动设计和C4分层架构模型的微服务软 件建模[J].中国电子科学研究院学报,2021.16(2):119-126.
[3] 刘一田,曹一鸣.微前端化微应用管理控制台[J].计算机系统 应用,2020.29(9):126-130.
[4] 陈宇收,饶宏博,王英明,等.基于JWT设计研究[J].电脑编程 技巧与维护,2019(9):11-12.
[5] 张洁,王燕梅,韩强.微前端技术的发展与应用[J].科技创新与 应用,2022(6):191-193.
[6] 吴良斌,肖祥.微前端视角下的会议系统设计与实现[J].福建 电脑,2022.8(38):58-63.
关注SCI论文创作发表，寻求SCI论文修改润色、SCI论文代发表等服务支撑，请锁定SCI论文网！
文章出自SCI论文网转载请注明出处：https://www.lunwensci.com/jisuanjilunwen/76932.html
