前端概览
项目简介
Dante Cloud UI 是 Dante Cloud 后台管理界面。是前后端分离的、独立运行的前端应用。基于 Vue 3、Vite4、Pinia2、Quasar2、Vue-router4、Hooks 和 Typescript 5 构建，是组件库式的、模块化的、基于 pnpm 的 monorepo 模式的前端工程。
该版本特点：
- 未使用任何流行开源模版，使用全新技术栈，完全纯"手写"全新前端工程。
- 借鉴参考流行开源版本的使用和设计，新版前端界面风格和操作习惯尽量与当前流行方式统一。
- 充份使用 Typescript 语言特性，解决大量类型校验问题，尽可能规避 "any" 式的 Typescript 编程语言使用方式。
- 充份使用 Composition Api 和 Hooks 等 Vue3 框架新版特性进行代码编写。
- 充份利用 Component、Hooks 以及 Typescript 面向对象等特性，抽取通用组件和代码，尽可能降低工程重复代码。
- 对较多 Quasar 基础组件和应用功能组件进行封装，以方便代码的统一修改维护和开发使用。
- 对生产模式下，对基于 Vite3 的工程打包进行深度性能优化。
- 提供以 docker-compose 方式，对工程生产代码进行容器化打包和部署。
- 该版本基于 pnpm，采用 monorepo 模式对前端工程进行重构。构建 monorepo 版本前端，是为扩展更多功能、增加应用级功能做铺垫
- 抽取 utils、components、apis、bpmn-designer 等相关代码，形成共享模块。
- 共享模块已进行优化配置，可编译成独立的组件，单独以组件形式进行发布。
- 代码以共享模块的方式进行单独维护开发，降低现有工程代码复杂度，便于后续功能的扩展和代码的复用。
微前端架构说明
开发 monorepo 版本之前，已经对微前端架构进行了一定研究，相关技术已经走通，但是并未在 monorepo 版本中直接实现。
这主要考虑到，结合目前对微前端的研究和理解，个人觉得微前端更适合在大型前端应用拆解、多前端项目整合的情况使用。想要构建一套完善的微前端应用，不仅研发投入大、潜在问题多、使用复杂度高，而且并不一定适合本项目目前大多数用户的实际使用需求，徒增复杂度而已。相反确实有类似的需求，早期采用一些性价比更高的替代方案，比如说 以 Nginx 部署的多应用方式似乎更可取高效。
因此，目前推出 monorepo 版前端，作为基础或过渡版本。在此版本基础之上，构建"微前端"应用，特别是基于 Micro-App 的微前端会非常容易。后期会适时并结合用户需求，再考虑是否转换为微前端架构前端应用。
技术介绍
Quasar
Quasar 是一个基于 Vue.js 开发的 web ui 框架，性能顶级，能够用于快速开发 web 桌面产品或 App 项目，编写一次代码，同时发布为网站、移动应用或 Electron 桌面应用。
框架特点
- 开箱即用，上手简单，UI 风格遵循 Material 指南
- 官方提供的 CLI 对多种开发模式（SPA、SSR、PWA、移动应用程序、桌面应用程序和浏览器扩展）提供了一流的支持，开发体验很好
- 内置主题定制工具以及对 Sass / SCSS / Stylus 变量的支持，快速定制适合项目特性的风格
- 性能顶级，在不同平台体验流畅，自动树摇模式，极大地减少包大小
- 国际化和本地化，有超过 40 种 Quasar 语言包可用。 如果缺少所需的语言包，则只需 5 分钟即可添加。
- 花费大量精力编撰的开发文档，以及很棒的中文社区
- 频繁的更新迭代和确定的发布周期
为什么选择 Quasar ？
在前端工程准备升级至 Vue3 之前，开展过前端组件库的选型。对 ElementUI，Antd，NaiveUI，Vuetify、Quasar 等组件库进行了详细的对比分析和试用，也对国内流行的前端管理模版系统代码进行过仔细的学习。最终选择 Quasar 而没有选择国内所谓“受众”广的组件库，主要是因为：
- ElementUI，Antd，NaiveUI 等流行组件库中的很多组件，对比 Vuetify、Quasar 等组件库封装度不高，比如：很多组件库的 Table 组件还是需要写
<table>、<tr>等标签 - 使用流行的组件库，基本没有工具样式，还是要自己大量编写 CSS 。如果不想写，最便捷的就是使用现成的模版，但这又导致学习成本比较高。
- 原本使用的是 Vuetify，但是支持 Vue3 的 Vuetify3 频频跳水，实在无法再等待下去。
所以最终选择的是 Quasar 组件库。Quasar 使用下来的总体感受：对后端开发人员来写前端非常友好
- 组件的封装度非常高，自定义和扩展也非常方便灵活
- 文档和示例非常丰富、简单和详实
- 提供多了非常多的工具样式，无须借助 windcss tailwindcss，更不需要编写大量 CSS，就可以快速的写出不说漂亮至少是看得过去的界面。
毕竟项目还是自己写，还是要选个趁手的工具。再说前后端分离相对传统的 JQuery 页面已经非常简单了，不同的组件库也就是熟悉与不熟悉、用法参数略有不同的问题。
Typescript
什么是 TypeScript
TypeScript 是 JavaScript 的一个超集，主要提供了类型系统和对 ES6 的支持，它由 Microsoft 开发，代码开源于 GitHub 上。
TypeScript 是 JavaScript 的类型的超集，它可以编译成纯 JavaScript。编译出来的 JavaScript 可以运行在任何浏览器上。TypeScript 编译工具可以运行在任何服务器和任何系统上。TypeScript 是开源的。
为什么选择 TypeScript
TypeScript增加了代码的可读性和可维护性- 类型系统实际上是最好的文档，大部分的函数看看类型的定义就可以知道如何使用了
- 可以在编译阶段就发现大部分错误，这总比在运行时候出错好
- 增强了编辑器和 IDE 的功能，包括代码补全,接口提示,跳转到定义,重构等
TypeScript非常包容- TypeScript 是 JavaScript 的超集，.js 文件可以直接重命名为 .ts 即可
- 即使不显式的定义类型，也能够自动做出类型推论
- 可以定义从简单到复杂的几乎一切类型
- 即使 TypeScript 编译报错，也可以生成 JavaScript 文件
- 兼容第三方库，即使第三方库不是用 TypeScript 写的，也可以编写单独的类型文件供 TypeScript 读取
TypeScript拥有活跃的社区- 大部分第三方库都有提供给
TypeScript的类型定义文件 Google开发的Angular2就是使用TypeScript编写的TypeScript拥抱了ES6规范，也支持部分ESNext草案的规范
- 大部分第三方库都有提供给
TypeScript 的缺点
任何事物都是有两面性的，我认为 TypeScript 的弊端在于：
- 有一定的学习成本，需要理解接口（Interfaces）,泛型（Generics）,类（Classes）,枚举类型（Enums）等前端工程师可能不是很熟悉的概念
- 短期可能会增加一些开发成本，毕竟要多写一些类型的定义，不过对于一个需要长期维护的项目，TypeScript 能够减少其维护成本
- 集成到构建流程需要一些工作量
- 可能和一些库结合的不是很完美