前端规范

制定规范可以带来以下几个好处：

• 一致性和可读性：规范有助于确保代码在整个项目中保持一致。这使得其他开发者更容易理解和参与项目，因为他们可以快速地理解代码的组织方式和意图。
• 可维护性：遵循规范可以提高代码的可维护性。当代码结构和命名约定一致时，定位和修复问题会更容易，因为开发者可以快速地找到相关的代码片段。
• 团队协作：在团队项目中，规范是促进协作的关键。所有团队成员遵循相同的规范，可以减少代码冲突，并确保代码的合并和集成过程更加顺畅。
• 代码重用：编写规范的代码可以提高代码的重用性。如果组件、函数和类的命名和设计符合规范，它们可以更容易地被其他项目或团队成员重用。
• 学习曲线：对于新加入团队的开发者，规范是学习曲线的缓冲器。他们可以更快地熟悉团队的编码风格和实践，从而快速地融入团队。
• 代码审查：规范可以帮助代码审查过程更加高效。审查者可以关注于代码的逻辑和功能，而不必在代码风格或格式上花费太多时间。
• 错误预防：遵循规范可以减少一些常见的错误。例如，变量命名规范可以防止命名冲突，注释规范可以确保代码被正确地文档化。

目录结构规范

xh-admin-frontend/                        
├── interface/              # ts类型定义
├── public/                 # 公共资源，打包会直接打进根目录
├── src                     
│   |-- api/                # 请求后端接口都应该放在这
│   |-- assets/             # 此目录放一些静态资源，对比public此目录只有引用后才会被打包
│   |-- components/         # 公共的基础组件都应放在这里
│   |-- directive/          # 全局的指令在这里
│   |-- i18n/               # 国际化配置在这里
│   |-- layout/             # 整体的布局配置组件在这里
│   |-- router/             # 路由配置在这里
│   |-- stores/             # 全局状态管理
│   |-- styles/             # 全局样式配置在这里
│   |-- utils/              # 工具类都放这里
│   └-- views/              # 业务相关组件都放在这里
├── types/                  # ts类型声明
└── package.json

命名规范

• 组件命名规范：
  1. 使用大驼峰命名法：组件名应该使用大驼峰命名法，以提高可读性和一致性。例如，MyComponentName。
  2. 语义化：组件名应该具有描述性，能够清晰地表达其用途和功能。例如，一个用户资料组件可以被命名为UserProfileComponent。
  3. 避免缩写：除非缩写是被广泛接受和理解的，否则应该尽量避免使用缩写。使用完整的单词可以提高组件名的清晰度和可读性。
  4. 使用 Vue 单文件组件（SFC）：如果使用 Vue 的单文件组件架构，文件名应该与组件名一致，并使用.vue 扩展名。例如，MyComponentName.vue。
  5. 避免与 HTML 元素重名：组件名不应该与任何标准 HTML 元素名重名，以避免冲突。例如，不要将组件命名为DivComponent。
  6. 使用复数形式：如果组件代表一组元素或有多个实例，使用复数形式的名称可以更好地传达其含义。例如，PostsComponent、ItemsComponent 等。
• 变量命名规范：
  1. 始终使用 camelCase（驼峰命名法）来命名变量。
  2. 使用有意义的前缀来表示变量的类型或作用域，例如 isLoading、hasError、currentUser 等。
• 方法命名规范：
  1. 同样使用 camelCase 来命名方法。
  2. 对于事件处理方法，可以使用 on 作为前缀，例如 onSubmit、onClick、onChange 等。
  3. 对于获取或设置属性值的方法，可以使用 get 和 set 前缀，例如 getUserName、setUserName。
  4. 对数据进行操作的方法可以使用动词+名词或者名词+动词的形式，比如 loadData、saveUser、updateProfile 等。
  5. 对于一些通用的辅助方法，可以使用 get、set、find、remove 等前缀。

注释规范

• 注释应该添加人员和时间。
• 方法注释应该解释方法的用途，它的参数和返回值。如果方法执行任何特定的逻辑或处理，也应该在注释中说明。这可以帮助其他开发者理解方法的功能，而无需查看实现细节。
• 类注释应该解释类的用途，它的属性和方法。如果类有特定的逻辑或处理，也应该在注释中说明。这可以帮助其他开发者理解类的功能，而无需查看实现细节。
• 在方法的实现过程中，如果逻辑比较复杂，也应该添加部分注释帮助阅读者理解。
• 注释在逻辑调整后需要及时更新注释，避免注释过时。

时间处理规范

所有涉及时间的处理，都应该使用 dayjs 库来处理，这样保证项目整体的时间处理库统一。

数据字典规范

所有下拉类型的数据，都应该维护数据字典，然后使用 Dict 获取数据字典详情 来获取数据字典数据。

文件链接规范

所有通过 Upload 上传 组件上传的文件，都会被 文件管理 菜单管理起来，再访问这些文件时的链接，都应该从工具类 文件请求链接 方法获取。

数据验证规范

不管是表单验证，还是 excel 导入验证，亦或是其他验证，都应该使用 Validate 数据验证 的统一验证逻辑来进行验证。

EChart 图表规范

所有图表，都应该使用 EChart 图表 工具类来进行渲染，切换主题的逻辑，动态变更大小的逻辑，主题变更逻辑 等都已在内部实现，开发者只需实现业务细节即可。

后端请求规范

所有后端请求，都应该使用 Request 请求 工具类来进行请求，这样保证项目整体的请求逻辑的统一，同时一些基础功能如： 防重复提交，请求前确认，loading控制，响应结果提示，请求拦截，消息自动提示 等功能，都可在调用时以选项方式灵活配置，这样开发者只需配置极少的选项即可实现，极大提高开发效率。