YGG-CLI-2-模板项目初始化

一个文笔一般，想到哪是哪的唯心论前端小白。

🧠 - 简介

模板项目初始化其实是不准备拿来专门起一个章的，另起一章的主要目的是总结一下现在维护的项目中的痛点，从而分析一下模板项目要达到什么程度。

👁️ - 分析

每天都在帮人还历史债务，一部分的问题是开发人员的能力不足导致的代码bug，但是大部分的问题都是因为项目本身就存在一些弊端，然后在后续的迭代过程中被无限放大了！

⏰ 痛点

🎺 样式问题

大家可能都遇到过在一个老项目的基础上增加主题切换或者统一UE的过程吧！大家是怎么实现的呢？

我摆一下我遇到的：

1. 项目本身已经进行了部分的 block 级别的封装，大部分的地方可以通过修改 block 的方式实现，但是主题色就很诡异了，到处都在重写，扩展难度是灾难级。
2. 项目本身没有进行任何封装，并且引入了多个 UI 组件库或者 现有的模板，样式各自隔离。扩展难度直接地狱级。
3. 鉴于上述情况，在后续迭代的过程中，因为个人问题或者其他问题，直接将样式写在行内，或者使用 style 进行动态绑定。
4. 为了支持通用主题，但是又有自定义的样式会有互相干扰，不得不在打包中忽略一些class的预处理，导致config文件中出现了非人类能看懂的代码，改又改不动，删又不敢删。

🎺 通用组件

组件其实还好了，常见的组件封装大部分分为三类：

• JSON流，所有的东西都实现了内置，传入一个JSON实现页面的渲染
• slot流，在基础组件的基础上，处理匿名插槽或者具名插槽，通过插槽的方式实现页面渲染
• component流，将一个大的组件进行拆分，结合JSON中的slotName字段，渲染页面

这其实都还好，三个方案都可以完成日常业务的开发工作。但是问题是：

1. 通用组件没有README，甚至没有任何注释，给新人带来高学习成本的同时，增加维护难度
2. 扩展能力低下，以至于后来人员不得不基于现有的组件进行二次开发，然后这个组件就改的面目全非了
3. 同一个业务逻辑，封装了好几套通用组件，例如：表格+分页
4. 通用组件和业务耦合程度过高，几乎没有可复用性，扩展业务的时候不得不对组件进行重构，然后继续恶性循环
5. src/component 这个目录下糅合了无数个组件，一眼看不到头
6. 你见过超过4000行的一个组件吗？

🎺 打包优化

这个其实还好，基于 webpack 或者 vite 打包的优化方案几乎都是开卷考试。

但是，见过不少自己写的工具，依旧是没有任何注释和说明的一个新的工具，很抽象的一个名字放在那里，一眼看去真的很懵啊。

⏰ 展望

我希望的一个模板项目中不求能根本的解决上述的问题，但是能在极大程度上避免上述中存在的一些坑。

例如：

1. 通用类组件，要完善文档，并明确提出扩展方法和支持边界。
2. 样式中尽量避免行内样式，并且底层业务页面中尽量不出现具体的色值，如果主题色里面没有，建议使用变量进行预置。
3. 整个项目结构尽量保持统一结构： module > page > component，涉及到交叉使用的 component 一律提出到模块里面，干净的项目结构，比更多的注释更容易被人接受，而不是所有的component都提到根目录中，那样只是把垃圾场进行了转移。
4. 各个组件功能高度内聚，能只干一件事的绝对不干第二件事，通用组件除外。

这个要求应该不怎么高，后续遇到具体问题会具体分析。

🫀 - 拆解

项目的初始化包含了以下几个小版块：

1. 技术栈的选型，并以此为基础新建一个项目。（vue3+ts+elementPlus+vite）
2. 简单的项目基建，代码规范中的 pretier+eslint 来约束开发习惯，huscky来规范git提交记录，一份简洁的 READEME 对项目进行介绍的同时说明这些规则。
3. 通用工具类的引入并组简单的预处理，vueuse + pinia + vueRouter + axios 的简单初始化。
4. 一个完整的目录体系：（仅供参考）

src
 |- assets 静态资源 + style
 |- common 公共资源：*.type.ts  *.class.ts  *.block.ts
 |- components 全局公共组件
 |- pages 模块集合
     |- module1 页面集合
         |- router.ts  模块路由
         |- api.ts  模块接口
         |- ?menu.ts  模块菜单(可选)
         |- page1.vue  页面
         |- ?page2.vue
         |- components 模块共用组件
     |- ?module2
 |- router  全局路由配置
 |- store  全局 pinia 配置
 |- utils  全局工具

💪 - 落实

这些内容都很平常了，主要说一下路由体系的设计思路吧！

可以看到每个模块内部都有一个 router.ts，即将项目模块与项目进行了深层次的解耦，在全局路由配置中，使用静态配置或者动态遍历的方式获取到子路由，最终组成项目的完整路由体系，如果需要模块移植，如果模板项目一致，是可以整模块完整移植的。

menu 也是一样的！

多一嘴，有没有人见过，一个项目中有 6套 axios 规则的？即 6个 axios.create()。

🛀 - 总结

本章中一行代码都没有，就是将一些目前能想到的摆出来，并设立一个目标，去一步步的实现它。

仅供参考，感兴趣的也可以评论区交流吖~~~

系列文章:

1. 脚手架开发
2. 模板项目初始化
3. 模板项目开发规范与设计思路
4. layout设计与开发
5. login 设计与开发
6. CURD页面的设计与开发
7. 监控页面的设计与开发
8. 富文本编辑器的使用与页面设开发设计
9. 主题切换的设计与开发并页面
10. 水印切换的设计与开发
11. 全屏与取消全屏
12. 开发提效之一键生成模块(页面)