# MQAdmin_next **Repository Path**: my_game_collection/mqadmin_next ## Basic Information - **Project Name**: MQAdmin_next - **Description**: MQAdmin(vue3 版本) - **Primary Language**: Unknown - **License**: MIT - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 1 - **Created**: 2021-05-09 - **Last Updated**: 2025-05-11 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # MQAdmin(Must Quickly Admin) - 飞速管理系统【Vue3实现】 ## 使用前必须执行的指令 ```shell // 几乎所有 packages/ 目录下的项目都依赖于 mq-components 组件仓库打包输出的 lib 目录 // 所以必须先对 mq-components 组件仓库打包生成 lib 文件夹其他项目才可正常运行 yarn workspace mq-components build ``` ## 技术重点 * 架构技术：几年的开发经验告诉我，对于任何程序架构都及其重要，是保障程序寿命的重要基础 * 设计模式：好的架构一定要结合适当(设计模式不可无章法胡乱使用)的设计模式，才能让架构更加坚固，这是本项目的首要技术， 也是我要主要学习的技术，几年开发下来，意识到设计模式的重要性； * 我对面向对象的理解：简单的面向对象，主要是把函数封装成class，而高级的面向对象是在架构的基础上，根据场景使用 合适的设计模式将函数封装成模块化的对象； * 我对架构和设计模式的理解：架构和设计模式主要是以面向对象为中心思想，在尽可能地保障程序性能的情况下，对代码合理管理的方案，让代码也拥有 低耦合，高复用，高内聚，易扩展，易维护的特性 * 架构和设计模式的重点思想：架构和设计模式要活学活用，不要生搬硬套。想要游刃有余地使用，需要打下牢固的程序设计语言基础、夯实自己的编程思想、积累大量的时间经验、提高开发能力。目的都是让程序在尽可能地保障程序性能的情况下实现低耦合，高复用，高内聚，易扩展，易维护 * 对于 $ref 的想法：在该项目的架构中不适用 $ref 因为其中包含不需要的内容太多了，我会用 interface 面向接口的方案来实现父对子组件函数的调用 （我会尽可能得不使用父对子组件中函数的调用，因为父调用子组件内的函数，若层级深了会偏离架构中心思想，除非无可奈何也仅限一层） ## 该项目以 Vue3.0 版本的研究重点 * 经研究 vue3.0 不适合使用 .tsx 语法开发，原因是：以目前市场技术来结合 react 的 .tsx 模式去实现 vue3.0 开发， 会导致没办法获得 vue3.0 编译阶段的优化（比如 Vue 3.0通过对模板的分析，可以做一些前期优化，而JSX语法是难以做到的） * 所以我的计划是将结合 vue3.0 的特点，从 .vue 模版中抽离出功能逻辑部分，将功能逻辑以 class 形式进行管理(这适合实现面向对象思想)， (这份工作主要需要用到 reflect-metadata[一个第三方反射方案库] 和 装饰器模式 来实现) * 在完成抽离研究后，我便可以实现重点管理方案了：零件组件 + 基类母版 作为基层，然后业务层app均基于基层进行业务逻辑的开发 * 【对于以上想法的说明： * * （1）对于 vue2 我通过 vue-tsx-support 和 vue-property-decorator 实现了 .tsx 开发 vue，并实现了我想要的组合和母版管理方案，但是那是因为 vue2 本身性能缺陷就比较多，.tsx 开发模式对 vue2 带来的缺陷几乎可以忽略，在这种情况下，我们完全可以为了更好 的实现代码管理而去牺牲 .tsx 带来的那点小缺憾，毕竟对于程序而言低耦合，高复用，高内聚，易扩展，易维护才是重点，.tsx 可以更好的搭建架构和应用设计模式来实现这个目的； * * （2）对于 vue3 而言，如果抛弃 vue3 的大部分性能优化，强行使用 .tsx，那么虽然能实现低耦合，高复用，高内聚，易扩展，易维护， 但是失去的代价太大，这已违背了架构和设计模式的中心思想(并没有去保障程序的性能)】 ## 项目宣言 * 经历了多年管理系统开发工作，有了自己的想法，需要通过个人的努力，并尽量避免外界杂质的干扰才能达成； * 飞速管理系统，目的是让开发人员集中精力在组件技术和业务逻辑技术上（将组件开发和业务开发分离）， 最终目标是将原来繁琐的组件拼接成业务需求的页面的代码编写，转为可视化的 UI 拼接， 若当前组件无法满足业务需求，则以增加合适的组件为解决方案，并非临时开发业务页面； 在最终目标实现之前，先通过 TypeScript 和 class 书写 vue 碎片组件和模板组件的方式，让前端也能 利用到面向对象的特点（封装、继承、多态）来减轻以往前端开发代码复用性和可维护性低的情况， 待此方案实现较为稳定之后，随之再逐步设计并开发可视化页面，直到实现最终目标 ## 产品简述 * 这个产品的想法根本不算什么创新，凡是经历过曾经 VB、C++、WinForm、Java等老项目开发 的朋友都早已见过，那些开发都是有可视化组件的，我们可以通过拖拽那些组件，然后配置相应属性， 再在相应脚本位置中填写相应的逻辑代码，就能做些东西了 * 而我要做的就是让Web前端，也能拥有一次类似的功能，当然我并不在意这功能是否真的有用， 我只是有这个想法，就想着称自己年轻，能够试着努力去尝试实现一下，难度多高，我大致清楚， 能不能真正实现我的想法，也不确定，也不想定什么几年内实现的目标，对我来说，这种时间紧迫 感没有任何意义，我就是想慢工出细活，就算做个N年，也无所谓，这是我自己的东西，做不成， 就享受这个过程，就当作是锻炼自己的实力也就足够了 ## 终极目标 * 将产品开发和产品用户体验高度解耦：【一个中间层】【一个基层】【一个逻辑层】，“中间层”高度严格规范开发，会调用“基层”和“逻辑层”一系列的参数并按照设定好的规范(性能优化、渲染优化、安全机制等一些列优化机制)生产一份实体网站文件，也就是说，只要这个中间层保证规范，那么“基层”和“逻辑层”无论写得代码怎样(只能按照中间层的接口规则开发，会被限制开发方式)，都会生成一个高性能的网站，那么用户体验就能得到优质的保证了 * 开发者只会分成2块：【中间层的高级开发】【基层和逻辑层的普通开发】，无论哪一层的开发，都能得到良好的代码锻炼和开发经验 ## 涉及的第三方辅助工具依赖包（目前正在开发中，以下只是准备，不一定都会用到） * git * git-cz : 代码规范提交工具 * npm * npm 平台: 组件库版本管理 * yarn: 包管理工具 * lerna: monorepo(多包管理) * webpack: 项目打包 * Glub: 比 webpack 灵活的打包工具（Glub是脚本方式打包，脚本中支持异步请求等牛掰操作），灵活当然就需要用的人懂更多细节 * rollup: 类库(组件库)打包 * jest：自动化单元测试工具 (Jest 测试脚本我选用 js，由于 Jest 脚本存在诸多无需声明的全局变量，ts 实在不合适， 至于 ts 组件的属性变量类型也可以用 js 去用一些方式去检测，不用 ts 也无所谓，毕竟 组件测试最重要的还是 Dom 的测试，其次才是相关变量的类型) * tar-fs: 文件包管理工具，我目前对此库了解太少，只是因为 puppeteer 安装提示必须先安装 tar-fs * puppeteer: jest + puppeteer 调用浏览器实现界面自动化测试 * jest-allure: 前提是电脑需要先安装 allure 环境， jest-allure 可以辅助生成美观的测试报告 * storybook: 组件 Demo API 可视化辅助工具 * TypeScript: 主要开发语言 * JavaScript: 一些配置脚本开发语言 * vue: 此产品主要使用的Web前端开发模板语言 * vue-cli: vue 项目开发脚手架 * vue-src-rollup: vue 组件库 rollup 打包脚手架 * Element-ui: 此产品主要使用的第三方基础组件库 * Element-Admin: 此产品项目包开发时，主要参考的第三方开源项目之一 * litemall: 此产品项目包开发时，主要参考的第三方开源项目之一 gitee code: https://gitee.com/linlinjava/litemall?utm_source=alading&utm_campaign=repo * mock: 模拟数据构建辅助工具 * DAG-diagram: 此产品中封装 DAG 有向无环图 组件来源 git code: https://github.com/murongqimiao/DAG-diagram * immjs: 不可变数据结构实现仓库，适合使用场景：在“纯函数”中优化对象的深度拷贝代码，让深度拷贝更简洁 * Normalize.css: 是一种CSS reset的替代方案。它在默认的HTML元素样式上提供了跨浏览器的高度一致性。相比于传统的CSS reset，Normalize.css是一种现代的、为HTML5准备的优质替代方案（https://necolas.github.io/normalize.css/7.0.0/normalize.css） 资料链接：https://www.jianshu.com/p/9d7ff89757fd * js-cookie: 是一个简单的，轻量级的处理cookies的js API * lodash: 一个丰富强大的功能函数库，比如其中的"节流"和"去抖"等 * echarts: 快速开发可视化图形 * D3js: https://d3js.org/ —— 主要用于开发更丰富灵活的数据可视化等复杂的图形 * * 注：ts 中使用需要再引入 @types/d3 依赖，d3 的 ts 声明包 * * 国外产品，一款非常灵活的数据可视化引擎库，相比配置型的 echarts 而言，其优势在于其提供了丰富的函数让开发者用良好的开发方式去实现丰富的数据可视化功能；echarts 是配置型的，仅适合快速开发，而在实现自定义图形功能上实在不优雅；D3js是开发型的，仅适合优雅地开发各种自定义的图形功能，效率上自然会低很多 * G6: http://antv-2018.alipay.com/zh-cn/g6/3.x/index.html —— 主要用于开发更丰富灵活的数据可视化等复杂的图形 * * 国内产品，蚂蚁金服开发，相比D3JS文档丰富，且带有针对移动端的F2产品，针对地理的L7产品，唯一欠缺的，就是物理动画效果比D3JS差太多，外国人的物理动画效果做得确实好，国人确实仍需加油，只要不注重动画效果的，选用G6确实最好了，毕竟文档丰富确实容易学习 * vue-xss: 防XSS注入攻击 * Nuxt.js: 朋友推荐的专用于VUE的服务端渲染(SSR)框架，后续计划开一个业务层包模块试试 ## 有关自动化测试 * 前端自动化测试方案：python + selame，另起一份项目，专做前端自动化测试的项目，与前端开发分离 【python + selame 优势：除了可以与前端开发分离的好处，最关键是有现成的快速开发仓库，可以高效得写出良好的前端自动化测试脚本】 【jest 做自动化测试，与前端的耦合太重了，而且开发太繁重，所以项目中的jest部分，我可能会弃用，顶多写一些简单的功能函数测试】 ## 整体目录结构 ``` -- root |__-- packages |__-- mq-home |__-- mq-admin |__-- packages-lib |__-- mq-components |__-- mq-request ``` * 目录说明 ``` -- root |__-- packages （业务项目包）（除了 <首页项目> 其他业务模块均基于 packages-lib 中的组件库进行开发，便于统一管理和维护） |__-- mq-home （首页项目模块：网站首页项目，让用户对整个项目所有模块一目了然[便捷查询和导向]，点击链接进入相应的业务模块系统） |__-- mq-admin （业务模块之：权限管理系统） |__-- packages-lib （组件仓库包） |__-- mq-components （初代 【包含所有业务模块公用的碎片组件和模板组件】） |_----— __test__ （函数和组件的单元测试脚本 Jest） |_----— dev （开发目录，可直接在组件库中运行开发调试） |_----— src （工程目录） |__-- mq-request （初代 <异步请求-组件库> 封装所有业务模块公用的请求拦截等相关操作） ``` ## 重点 * 组件库 通过tsx 方式实现 vue 碎片组件和模板组件基类开发，并配置 Jest + babel 实现对 tsx 组件的单元测试 * 业务层高度解耦，引入组件库，并不受组件库的特殊形式(tsx)的影响，仍然使用常用的.vue开发方式即可，并且继承模板组件基类后，仅需通过参数配置，无需任何html代码，即可集中精力于业务代码的开发 * 组件库中禁止使用 vuex，仅使用 props 和 组件间接口(每个组件都写一个interface，仅开放需要的函数给父级组件调用)：为了让组件库中的组件可读性更高，更好维护，搬运代码更加方便，尽可能得降低耦合 * 业务层模块中尽量少用 vuex，且我需要想尽可能低耦合的方式去使用 vuex 存储数据，这是为了尽可能的让一些公共逻辑也可复用，让逻辑代码可读性更高更好维护 * axiso之取消接口请求操作，参考资料：https://www.jianshu.com/p/c0d874ab6454 为了避免恶意操作在前端页面来回刷新，导致N此重复请求，给后台服务带来压力，我们需要在页面离开或者类似情况下，主动去断开请求 * 解决 history stack 堆叠问题：酌情使用 history.go 和 history.push 跳转路由, 严格控制路由跳转历史问题，尽力实现原生android 的活动处理方案 ## 目标 * tsx 编写 vue 组件【已实现】 * main.ts 入口脚本的主要功能统一在组件库中，业务层继承即可【已实现】 * 【计划废弃此方案】~~Jest + babel 实现对 tsx 的 vue 组件进行单元测试【已实现】~~ * python + selame 实现以独立项目的自动化测试项目，其中可包含多个项目的自动化测试 * 搭建第一个碎片组件和模板组件基类，并在业务层app中引入组件库，并成功应用【已实现】 * 搭建第一个管理系统的外层布局模板基类(左侧菜单+公司图标+顶部操作栏+空的主体区域)【进行中...】 * 单元测试：<1>组件和模板基类的各属性测试; <2>业务层页面的通用业务逻辑测试;【学习中...】 * 性能优化【未开始】 * 渲染优化【未开始】 * Glub 打包优化【未开始】 * 自动化生成组件的Jest单元测试脚本：这是此项目衍生出来的一个子项目【尝试并探索中...】 * * 初版会以NodeJs脚本形式集成在这个项目中 * * 最终版会抽离出来并制作成独立的开源库存在，前端安装此库后，可以如同使用Jest库一样，通过简便的指令来操作 * * feature-flags 方案：通过 feature-flags + 装饰器（代码需要严格拆分各个功能函数）实现对版本或项目按需打包发布（仅打包发布对应版本需要的功能） ## 一些特殊功能的文件说明 * 1、这里的根目录下的 tsconfig.json 处理统一处理所有项目的 ts 配置之外，还提供给 Vetur（VSCode 插件） 这个插件 格式化时识别使用的 ## 项目命名规则说明 * 1、类、枚举、组件命名：大驼峰命名，即首字母大写的驼峰命名（若组件在目录下仅存在自身组件文件，那么文件夹以大驼峰进行命名，组件文件一律命名为index） * 2、枚举也都以大驼峰命名的单独文件存在 * 3、样式文件命名：均小写，单词之间用 - 横杠隔开 * 4、剩余文件命名：小驼峰命名，即首字母小写的驼峰命名 ## 致谢 * litemall: 此产品项目包开发时，主要参考的第三方开源项目之一 gitee code: https://gitee.com/linlinjava/litemall?utm_source=alading&utm_campaign=repo * DAG-diagram: 此产品中封装 DAG 有向无环图 组件来源 git code: https://github.com/murongqimiao/DAG-diagram ## 本项目非常重要的两个参考网站 * vue-tsx-support 【怎么写 tsx 的 vue 组件都在这份官方资料中了】 https://github.com/wonderful-panda/vue-tsx-support#readme * vue-property-decorator 【tsx 的 vue 组件中要用到的装饰器都需要从这份官方参考资料中查询】 https://www.npmjs.com/package/vue-property-decorator ## 本项目开发时的其他参考资料 * 【自己实现AJAX（为了更好的理解和使用异步请求）】：https://www.jianshu.com/p/6d567182a429