forked from gin/simple-template
refactor: add docs and skills
This commit is contained in:
@@ -0,0 +1,27 @@
|
|||||||
|
---
|
||||||
|
name: agileboot-backend-feature
|
||||||
|
description: 在 AgileBoot/Spring Boot 项目中开发新的后端业务功能,并严格按照当前仓库已有架构组织代码。适用于新增或修改后台管理端模块、CRUD 功能、业务流程、数据库资源、Controller、ApplicationService、领域模型、Command、Query、DTO、MyBatis Plus Entity/Mapper/Service、权限、操作日志和测试;必须先阅读项目后端开发规范并复用既有分层方式,而不是使用通用 Spring 三层写法。
|
||||||
|
---
|
||||||
|
|
||||||
|
# AgileBoot 后端业务功能开发
|
||||||
|
|
||||||
|
本 skill 是 Codex 的执行入口,不是完整规范副本。完整规范以 `docs/backend-feature-development.md` 为准。
|
||||||
|
|
||||||
|
## 必读
|
||||||
|
|
||||||
|
- `docs/backend-feature-development.md`
|
||||||
|
- `AGENTS.md`
|
||||||
|
|
||||||
|
## 执行要求
|
||||||
|
|
||||||
|
1. 先阅读必读文档。
|
||||||
|
2. 再检索并阅读最相似的现有后端模块,优先看 `post`、`user`、`role`、`notice` 和 `admin/controller/system`。
|
||||||
|
3. 按 docs 中的架构、目录、类型边界、权限、日志、异常和测试规则实现。
|
||||||
|
4. 如果 docs 未覆盖某个决策,先参考现有模块;不要自行引入新架构风格。
|
||||||
|
5. 完成后按 docs 的验收清单自检,并运行相关 Maven 测试或说明未运行原因。
|
||||||
|
|
||||||
|
## 不要做
|
||||||
|
|
||||||
|
- 不要把本文当成规范来源来扩写;需要补充规范时更新 `docs/backend-feature-development.md`。
|
||||||
|
- 不要绕过 `Controller -> ApplicationService -> Model -> db Service/Mapper`。
|
||||||
|
- 不要直接返回 Entity 或 DO 给前端。
|
||||||
@@ -0,0 +1,4 @@
|
|||||||
|
interface:
|
||||||
|
display_name: "AgileBoot 后端功能"
|
||||||
|
short_description: "按现有 AgileBoot 架构组织后端业务功能开发流程"
|
||||||
|
default_prompt: "Use $agileboot-backend-feature to develop a new admin backend business feature following this repository's existing architecture."
|
||||||
@@ -0,0 +1,27 @@
|
|||||||
|
---
|
||||||
|
name: agileboot-web-feature
|
||||||
|
description: 在 AgileBoot Vue Web 项目中开发新的 frontend/web 前端业务功能,并严格按照当前仓库已有页面、API、hook、表单、弹窗、页面私有组件和字典使用方式组织代码。适用于新增或修改后台页面、列表页、表单弹窗、API 类型封装、PureTable 表格、Element Plus 交互、页面 components、utils/hook.tsx、权限、路由和菜单相关前端功能;必须先阅读项目 Web 前端开发规范并复用既有模式。
|
||||||
|
---
|
||||||
|
|
||||||
|
# AgileBoot Web 前端业务功能开发
|
||||||
|
|
||||||
|
本 skill 是 Codex 的执行入口,不是完整规范副本。完整规范以 `docs/web-feature-development.md` 为准。
|
||||||
|
|
||||||
|
## 必读
|
||||||
|
|
||||||
|
- `docs/web-feature-development.md`
|
||||||
|
- `AGENTS.md`
|
||||||
|
|
||||||
|
## 执行要求
|
||||||
|
|
||||||
|
1. 先阅读必读文档。
|
||||||
|
2. 再检索并阅读最相似的现有前端模块,优先看 `system/post`、`system/user`、`system/role`、`system/notice`、`login` 和对应 API 文件。
|
||||||
|
3. 按 docs 中的页面结构、API、hook、表单、页面私有组件、字典、路由、权限和验证规则实现。
|
||||||
|
4. 如果 docs 未覆盖某个决策,先参考现有模块;不要自行引入新前端组织方式。
|
||||||
|
5. 完成后按 docs 的验证清单自检,并运行 `pnpm --dir frontend/web typecheck`、`pnpm --dir frontend/web lint` 或说明未运行原因。
|
||||||
|
|
||||||
|
## 不要做
|
||||||
|
|
||||||
|
- 不要把本文当成规范来源来扩写;需要补充规范时更新 `docs/web-feature-development.md`。
|
||||||
|
- 不要绕过 `@/utils/http`。
|
||||||
|
- 不要把复杂列表逻辑堆在 `index.vue`。
|
||||||
@@ -0,0 +1,4 @@
|
|||||||
|
interface:
|
||||||
|
display_name: "AgileBoot Web 前端功能"
|
||||||
|
short_description: "按现有 AgileBoot Web 架构开发前端业务功能"
|
||||||
|
default_prompt: "Use $agileboot-web-feature to develop a frontend web business feature following this repository's existing conventions."
|
||||||
@@ -0,0 +1,14 @@
|
|||||||
|
# Agent Rules
|
||||||
|
|
||||||
|
- 后端新增或修改业务功能前,必须阅读 `docs/backend-feature-development.md`。
|
||||||
|
- 后端代码必须遵循 `Controller -> ApplicationService -> Model -> db Service/Mapper` 的组织方式。
|
||||||
|
- 不要把业务规则写在 Controller。
|
||||||
|
- 不要让 Controller 直接调用 Mapper。
|
||||||
|
- 不要直接把 Entity 或 DO 返回给前端。
|
||||||
|
- 复杂查询结果对象可以使用 `XxxDO`,放在 `db` 包下,并由 ApplicationService 转换为 DTO。
|
||||||
|
- 字典类需求不要默认创建字典管理表;本项目现有字典数据使用 Enum 和缓存。
|
||||||
|
- `frontend/web` 新增或修改业务功能前,必须阅读 `docs/web-feature-development.md`。
|
||||||
|
- Web 前端接口必须通过 `@/utils/http` 封装调用,不要直接使用 Axios。
|
||||||
|
- Web 列表页复杂状态和行为应放在 `utils/hook.tsx`,不要堆在 `index.vue`。
|
||||||
|
- Web 页面私有组件放在当前模块的 `components/`,多模块复用组件提升到 `frontend/web/src/components`。
|
||||||
|
- Web 字典展示优先使用 `useUserStoreHook().dictionaryList` 或 `dictionaryMap`,不要硬编码状态文本和值。
|
||||||
@@ -0,0 +1,155 @@
|
|||||||
|
# 后端业务功能开发规范
|
||||||
|
|
||||||
|
本文是本项目后端新增或修改业务功能时的权威规范。开发后台管理端业务模块时,必须优先遵循本项目现有架构,而不是套用通用 Spring Boot 三层模板。
|
||||||
|
|
||||||
|
## 架构原则
|
||||||
|
|
||||||
|
后端业务代码按 `Controller -> ApplicationService -> Model -> db Service/Mapper` 组织。
|
||||||
|
|
||||||
|
优先参考这些现有模块:
|
||||||
|
|
||||||
|
- `backend/agileboot-domain/src/main/java/com/agileboot/domain/system/post`
|
||||||
|
- `backend/agileboot-domain/src/main/java/com/agileboot/domain/system/user`
|
||||||
|
- `backend/agileboot-domain/src/main/java/com/agileboot/domain/system/role`
|
||||||
|
- `backend/agileboot-domain/src/main/java/com/agileboot/domain/system/notice`
|
||||||
|
- `backend/agileboot-admin/src/main/java/com/agileboot/admin/controller/system`
|
||||||
|
|
||||||
|
不要让 Controller 直接调用 Mapper,不要把业务规则写在 Controller,也不要直接把 Entity 或 DO 返回给前端。
|
||||||
|
|
||||||
|
## 开发准备
|
||||||
|
|
||||||
|
开发新后端业务功能前,应先确认需求所属领域、涉及的数据表、接口范围、权限标识和相似模块。本文是后端业务功能开发的统一规范。
|
||||||
|
|
||||||
|
开始编码前必须先做一次相似模块调研,确认目标功能最接近 `post`、`user`、`role`、`notice` 还是其他模块,再按相似模块的命名、包路径、注解、分页、异常、权限、日志和测试风格实现。
|
||||||
|
|
||||||
|
## 目录结构
|
||||||
|
|
||||||
|
后台管理端入口放在 `agileboot-admin`:
|
||||||
|
|
||||||
|
```text
|
||||||
|
backend/agileboot-admin/src/main/java/com/agileboot/admin/controller/<area>/
|
||||||
|
└── XxxController.java
|
||||||
|
```
|
||||||
|
|
||||||
|
业务代码放在 `agileboot-domain`:
|
||||||
|
|
||||||
|
```text
|
||||||
|
backend/agileboot-domain/src/main/java/com/agileboot/domain/<area>/xxx/
|
||||||
|
├── XxxApplicationService.java
|
||||||
|
├── command/
|
||||||
|
│ ├── AddXxxCommand.java
|
||||||
|
│ └── UpdateXxxCommand.java
|
||||||
|
├── query/
|
||||||
|
│ └── XxxQuery.java
|
||||||
|
├── dto/
|
||||||
|
│ ├── XxxDTO.java
|
||||||
|
│ └── XxxDetailDTO.java
|
||||||
|
├── model/
|
||||||
|
│ ├── XxxModel.java
|
||||||
|
│ └── XxxModelFactory.java
|
||||||
|
└── db/
|
||||||
|
├── XxxEntity.java
|
||||||
|
├── XxxDO.java
|
||||||
|
├── XxxMapper.java
|
||||||
|
├── XxxService.java
|
||||||
|
└── XxxServiceImpl.java
|
||||||
|
```
|
||||||
|
|
||||||
|
`XxxDO` 是可选文件。只有当查询结果包含 join、聚合、报表字段或其他不完全匹配 Entity 的字段时才创建。
|
||||||
|
|
||||||
|
如果业务属于已有领域,例如 `system`,放到现有领域下;如果是独立业务领域,创建新的 `<area>` 包名,例如 `business`。
|
||||||
|
|
||||||
|
## 各层职责
|
||||||
|
|
||||||
|
Controller 只负责 HTTP 层:
|
||||||
|
|
||||||
|
- 声明 `@RestController`、`@RequestMapping`、`@Validated`、Swagger 注解。
|
||||||
|
- 接收 `Command`、`Query`、路径参数和请求参数。
|
||||||
|
- 使用 `@PreAuthorize("@permission.has('xxx:yyy:zzz')")` 做权限控制。
|
||||||
|
- 对新增、修改、删除、导出等操作使用 `@AccessLog`。
|
||||||
|
- 调用 `XxxApplicationService`。
|
||||||
|
- 使用 `ResponseDTO.ok(...)` 返回结果。
|
||||||
|
|
||||||
|
ApplicationService 负责编排业务用例:
|
||||||
|
|
||||||
|
- 分页查询、详情查询、导出查询、新增、修改、删除。
|
||||||
|
- 创建或加载 `XxxModel`。
|
||||||
|
- 调用领域模型完成业务校验和状态变化。
|
||||||
|
- 调用 `db` 包中的 Service 完成查询和持久化。
|
||||||
|
- 将 Entity 或 DO 转换为 DTO。
|
||||||
|
- 分页结果使用 `PageDTO<T>`。
|
||||||
|
|
||||||
|
Model 承载业务规则:
|
||||||
|
|
||||||
|
- 从 `AddXxxCommand`、`UpdateXxxCommand` 加载字段。
|
||||||
|
- 封装唯一性校验、状态校验、是否允许删除、业务状态流转等规则。
|
||||||
|
- 需要数据库判断时,通过构造注入的 `XxxService` 查询。
|
||||||
|
- 业务失败时抛出 `ApiException`,不要返回布尔值让上层解释。
|
||||||
|
|
||||||
|
ModelFactory 负责创建和加载模型:
|
||||||
|
|
||||||
|
- `create()` 返回带有依赖的空模型。
|
||||||
|
- `loadById(id)` 从数据库加载 Entity,并包装为 Model。
|
||||||
|
- 如果未找到必要数据,按项目现有异常风格处理。
|
||||||
|
|
||||||
|
db 包只负责持久化:
|
||||||
|
|
||||||
|
- `XxxEntity` 映射数据库表。
|
||||||
|
- `XxxDO` 承载复杂查询结果,例如关联表字段、统计字段、报表字段。
|
||||||
|
- `XxxMapper` 继承 MyBatis Plus `BaseMapper<XxxEntity>`。
|
||||||
|
- `XxxService` 继承 `IService<XxxEntity>`,声明复用型查询方法。
|
||||||
|
- `XxxServiceImpl` 继承 `ServiceImpl<XxxMapper, XxxEntity>`,实现唯一性检查、关联检查、复杂查询等。
|
||||||
|
- 复杂 SQL 放到 mapper XML,简单条件优先使用 MyBatis Plus wrapper。
|
||||||
|
|
||||||
|
`XxxDO` 属于数据库查询结果对象,不是前端响应对象,也不是请求对象。Mapper 或 Service 可以返回 `XxxDO`,但 ApplicationService 必须转换为 `XxxDTO` 后再交给 Controller 返回。
|
||||||
|
|
||||||
|
Command、Query、DTO 的边界:
|
||||||
|
|
||||||
|
- `Command` 用于新增、修改等写请求,不要直接接收 Entity。
|
||||||
|
- `Query` 用于列表、搜索、分页条件,并提供 `toPage()`、`toQueryWrapper()` 等项目已有风格的方法。
|
||||||
|
- `DTO` 用于响应前端,不要直接暴露 Entity 或 DO。
|
||||||
|
- 批量删除优先使用 `BulkOperationCommand<Long>`。
|
||||||
|
|
||||||
|
## 开发流程
|
||||||
|
|
||||||
|
1. 检索并阅读一个最相似的现有模块,确认命名、包路径、注解、分页、异常、测试风格。
|
||||||
|
2. 确认数据库表结构,保持主键、软删除、审计字段、字段命名与现有表一致。
|
||||||
|
3. 创建 `db` 包:`Entity`、`Mapper`、`Service`、`ServiceImpl`;如查询结果包含关联表字段、统计字段或报表字段,再增加 `XxxDO`。
|
||||||
|
4. 创建 API 契约:`AddXxxCommand`、`UpdateXxxCommand`、`XxxQuery`、`XxxDTO`,需要详情时添加 `XxxDetailDTO`。
|
||||||
|
5. 创建 `XxxModel` 和 `XxxModelFactory`,把业务校验放进 Model。
|
||||||
|
6. 创建 `XxxApplicationService`,编排查询、新增、修改、删除、导出等用例。
|
||||||
|
7. 创建 `XxxController`,加路由、权限、操作日志和统一响应。
|
||||||
|
8. 如功能出现在后台菜单,补充权限标识、菜单 SQL 或清楚说明需要配置的权限码。
|
||||||
|
9. 增加聚焦测试,至少覆盖核心业务校验和主要用例。
|
||||||
|
10. 运行相关 Maven 测试或编译检查;如果不能运行,说明原因。
|
||||||
|
|
||||||
|
开发过程中如果发现本文未覆盖的模式,优先参考现有模块,而不是引入新的架构风格。确实需要新增模式时,应先更新本文,再按新规范实现。
|
||||||
|
|
||||||
|
## 权限、日志和错误
|
||||||
|
|
||||||
|
权限码必须和前端菜单或按钮权限保持一致,格式参考现有系统功能:
|
||||||
|
|
||||||
|
```java
|
||||||
|
@PreAuthorize("@permission.has('system:post:add')")
|
||||||
|
```
|
||||||
|
|
||||||
|
操作日志按业务动作选择类型:
|
||||||
|
|
||||||
|
```java
|
||||||
|
@AccessLog(title = "业务名称", businessType = BusinessTypeEnum.ADD)
|
||||||
|
@AccessLog(title = "业务名称", businessType = BusinessTypeEnum.MODIFY)
|
||||||
|
@AccessLog(title = "业务名称", businessType = BusinessTypeEnum.DELETE)
|
||||||
|
@AccessLog(title = "业务名称", businessType = BusinessTypeEnum.EXPORT)
|
||||||
|
```
|
||||||
|
|
||||||
|
业务错误使用 `ApiException` 和 `ErrorCode.Business`。新增业务错误时,按现有错误码结构补充枚举或常量,不要在 Controller 中拼接错误响应。
|
||||||
|
|
||||||
|
## 验收清单
|
||||||
|
|
||||||
|
- 新代码目录结构与相似模块一致。
|
||||||
|
- Controller 只有 HTTP 编排逻辑。
|
||||||
|
- 业务校验位于 Model 或 ApplicationService,不散落在前端或 Controller。
|
||||||
|
- 查询返回 DTO,分页返回 `PageDTO<T>`。
|
||||||
|
- 写请求使用 Command。
|
||||||
|
- 复杂查询结果对象使用 DO,并在 ApplicationService 转换为 DTO。
|
||||||
|
- 权限、日志、异常、测试和现有项目风格一致。
|
||||||
@@ -0,0 +1,198 @@
|
|||||||
|
# Web 前端业务功能开发规范
|
||||||
|
|
||||||
|
本文是 `frontend/web` 新增或修改前端业务功能时的权威规范。当前 Web 项目基于 Vue 3、Vite、Element Plus、Pure Admin、Pinia、Vue Router 和项目自有 `@/utils/http` 封装。开发时必须优先复用现有目录结构、组件和工具链。
|
||||||
|
|
||||||
|
本文只覆盖 `frontend/web`,不覆盖 `frontend/app`。
|
||||||
|
|
||||||
|
## 架构原则
|
||||||
|
|
||||||
|
前端业务模块按“页面结构 + API 类型封装 + 业务 hook + 表单/弹窗 + 页面私有组件”组织。
|
||||||
|
|
||||||
|
优先参考这些现有模块:
|
||||||
|
|
||||||
|
- `frontend/web/src/views/system/post`
|
||||||
|
- `frontend/web/src/views/system/user`
|
||||||
|
- `frontend/web/src/views/system/role`
|
||||||
|
- `frontend/web/src/views/system/notice`
|
||||||
|
- `frontend/web/src/views/login`
|
||||||
|
- `frontend/web/src/api/system/post.ts`
|
||||||
|
|
||||||
|
不要绕过 `@/utils/http` 直接使用 Axios。不要在 `index.vue` 中堆积复杂列表逻辑。不要硬编码字典状态文本、值或标签样式。
|
||||||
|
|
||||||
|
## 开发准备
|
||||||
|
|
||||||
|
开发 `frontend/web` 业务功能前,应先确认页面所属业务域、后端接口、菜单路由、权限标识、字典依赖和相似页面。本文是 Web 前端业务功能开发的统一规范。
|
||||||
|
|
||||||
|
开始编码前必须先做一次相似模块调研,确认目标功能最接近 `system/post`、`system/user`、`system/role`、`system/notice`、`login` 还是其他模块,再按相似模块的页面结构、API 类型、hook、表单、字典、表格、分页、排序、删除、导出、权限和组件命名风格实现。
|
||||||
|
|
||||||
|
## 目录结构
|
||||||
|
|
||||||
|
业务页面放在 `frontend/web/src/views/<area>/<module>/`:
|
||||||
|
|
||||||
|
```text
|
||||||
|
frontend/web/src/views/<area>/<module>/
|
||||||
|
├── index.vue
|
||||||
|
├── form.vue 或 xxx-form-modal.vue
|
||||||
|
├── components/
|
||||||
|
│ ├── private-panel.vue
|
||||||
|
│ └── private-fragment.vue
|
||||||
|
└── utils/
|
||||||
|
├── hook.tsx
|
||||||
|
├── rule.ts
|
||||||
|
└── types.ts
|
||||||
|
```
|
||||||
|
|
||||||
|
API 放在 `frontend/web/src/api/<area>/<module>.ts`:
|
||||||
|
|
||||||
|
```text
|
||||||
|
frontend/web/src/api/<area>/<module>.ts
|
||||||
|
```
|
||||||
|
|
||||||
|
`components/`、`rule.ts`、`types.ts` 按需创建,不要求每个模块都存在。
|
||||||
|
|
||||||
|
## 页面私有组件
|
||||||
|
|
||||||
|
只被某个页面或模块使用的组件,放在该模块目录下的 `components/`。现有示例是 `frontend/web/src/views/login/components`。
|
||||||
|
|
||||||
|
页面私有组件适合承载:
|
||||||
|
|
||||||
|
- 页面内局部展示组件。
|
||||||
|
- 局部表单片段。
|
||||||
|
- 局部抽屉、局部面板、局部弹窗。
|
||||||
|
- 只服务当前页面流程的交互单元。
|
||||||
|
|
||||||
|
页面私有组件不应承载整个业务模块的主流程。主列表、主表单、主弹窗仍按现有模块风格放在 `index.vue`、`form.vue` 或 `xxx-form-modal.vue`。
|
||||||
|
|
||||||
|
如果组件开始被第二个业务模块复用,应提升到 `frontend/web/src/components`,不要继续放在某个页面私有目录中。只有在明确属于某个业务域且多个同域模块复用时,才考虑创建 `views/<area>/components`;当前项目还没有这个模式,新增前应谨慎。
|
||||||
|
|
||||||
|
页面私有组件的判断标准是“是否只服务当前页面或当前模块”。如果组件包含通用交互、通用展示、通用上传、通用选择器等能力,应优先设计为公共组件,而不是藏在某个业务页面目录下。
|
||||||
|
|
||||||
|
## 各文件职责
|
||||||
|
|
||||||
|
`index.vue` 负责页面结构:
|
||||||
|
|
||||||
|
- 搜索表单。
|
||||||
|
- 表格和表格插槽。
|
||||||
|
- 工具栏按钮。
|
||||||
|
- 弹窗、抽屉、页面私有组件的挂载。
|
||||||
|
- `defineOptions({ name })`,组件 name 应与菜单表中的 `router_name` 保持一致。
|
||||||
|
|
||||||
|
`utils/hook.tsx` 负责列表业务状态和行为:
|
||||||
|
|
||||||
|
- 查询参数、分页、排序、loading。
|
||||||
|
- 表格列定义。
|
||||||
|
- 列表查询、搜索、重置。
|
||||||
|
- 删除、批量删除、导出。
|
||||||
|
- 字典值渲染,例如 `el-tag`。
|
||||||
|
|
||||||
|
`form.vue` 或 `xxx-form-modal.vue` 负责新增/编辑:
|
||||||
|
|
||||||
|
- 接收 `v-model` 控制显示。
|
||||||
|
- 接收 `type`、`row` 等必要 props。
|
||||||
|
- 维护表单数据和校验状态。
|
||||||
|
- 调用新增/修改 API。
|
||||||
|
- 成功后关闭并向父组件发出 `success` 事件。
|
||||||
|
|
||||||
|
`utils/rule.ts` 负责复杂或可复用的表单校验规则。简单模块也可以把规则放在表单组件内,保持与现有代码一致。
|
||||||
|
|
||||||
|
`utils/types.ts` 只放页面私有类型。跨 API 复用的请求/响应类型优先放在对应 `src/api/<area>/<module>.ts`。
|
||||||
|
|
||||||
|
## API 规范
|
||||||
|
|
||||||
|
每个业务模块在 `src/api/<area>/<module>.ts` 中封装后端接口和 TypeScript 类型。
|
||||||
|
|
||||||
|
接口调用使用项目 HTTP 封装:
|
||||||
|
|
||||||
|
```ts
|
||||||
|
http.request<ResponseData<T>>("get", "/path", { params });
|
||||||
|
http.request<ResponseData<void>>("post", "/path", { data });
|
||||||
|
```
|
||||||
|
|
||||||
|
文件下载使用:
|
||||||
|
|
||||||
|
```ts
|
||||||
|
http.download("/path/excel", fileName, { params });
|
||||||
|
```
|
||||||
|
|
||||||
|
类型命名优先遵循现有风格:
|
||||||
|
|
||||||
|
- `XxxListCommand`:列表查询参数。
|
||||||
|
- `XxxPageResponse`:列表响应行。
|
||||||
|
- `AddXxxCommand`:新增请求。
|
||||||
|
- `UpdateXxxCommand`:修改请求。
|
||||||
|
|
||||||
|
删除接口如果后端接收 `ids` 查询参数,按现有写法把数组转成字符串,避免 Axios 序列化为 `ids[0]`、`ids[1]`。
|
||||||
|
|
||||||
|
## 列表、分页和排序
|
||||||
|
|
||||||
|
列表页优先使用 `PureTableBar + pure-table`。
|
||||||
|
|
||||||
|
分页使用 `PaginationProps`,并通过 `CommonUtils.fillPaginationParams()` 填充查询参数。
|
||||||
|
|
||||||
|
排序使用 Element Plus `Sort`,并通过 `CommonUtils.fillSortParams()` 传给后端。
|
||||||
|
|
||||||
|
时间范围查询使用 `beginTime`、`endTime`,优先复用现有 computed 写法处理 `el-date-picker` 的双向绑定。
|
||||||
|
|
||||||
|
批量操作必须维护 `multipleSelection`,并在空选择时给出提示。
|
||||||
|
|
||||||
|
## 字典和状态
|
||||||
|
|
||||||
|
字典来自登录配置并缓存在用户 store 中。
|
||||||
|
|
||||||
|
下拉选项使用:
|
||||||
|
|
||||||
|
```ts
|
||||||
|
useUserStoreHook().dictionaryList["common.status"]
|
||||||
|
```
|
||||||
|
|
||||||
|
表格状态渲染使用:
|
||||||
|
|
||||||
|
```ts
|
||||||
|
useUserStoreHook().dictionaryMap["common.status"]
|
||||||
|
```
|
||||||
|
|
||||||
|
不要在页面中硬编码状态 label、value、`el-tag` 类型。字典不存在或可能为空时,新增代码应避免直接访问导致运行时报错。
|
||||||
|
|
||||||
|
## 交互和组件
|
||||||
|
|
||||||
|
按钮图标优先使用 `useRenderIcon()` 和现有 iconify 图标。
|
||||||
|
|
||||||
|
新增/编辑弹窗优先复用 `VDialog` 或相似模块的弹窗写法。
|
||||||
|
|
||||||
|
单条删除使用 `el-popconfirm` 或模块现有风格。批量删除使用 `ElMessageBox.confirm` 时,必须处理取消分支并清理选择状态。
|
||||||
|
|
||||||
|
操作成功后刷新列表。弹窗通过 `v-model` 和 `success` 事件与父组件通信。
|
||||||
|
|
||||||
|
跨业务通用能力优先放在 `src/components` 或 `src/utils`;页面私有能力保持在页面目录内。
|
||||||
|
|
||||||
|
## 权限、路由和菜单
|
||||||
|
|
||||||
|
后台业务菜单主要依赖后端菜单和动态路由。新页面的组件 name 必须与菜单表中的 `router_name` 保持一致。
|
||||||
|
|
||||||
|
不要随意新增静态路由。只有登录页、重定向、个人中心等固定页面才参考 `src/router/modules` 中的静态路由模式。
|
||||||
|
|
||||||
|
如需要按钮权限,优先复用项目已有的 `ReAuth` 或 auth directive 模式,不要自行实现一套权限判断。
|
||||||
|
|
||||||
|
## 验证清单
|
||||||
|
|
||||||
|
前端改动后优先运行:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
pnpm --dir frontend/web typecheck
|
||||||
|
pnpm --dir frontend/web lint
|
||||||
|
```
|
||||||
|
|
||||||
|
如果依赖未安装或环境不允许运行,说明原因。
|
||||||
|
|
||||||
|
如果只修改文档,不需要运行前端 typecheck 或 lint;如果修改了 TypeScript、Vue、样式或路由/API 文件,应优先运行上述检查。
|
||||||
|
|
||||||
|
业务页面至少检查:
|
||||||
|
|
||||||
|
- 列表加载。
|
||||||
|
- 搜索和重置。
|
||||||
|
- 分页和排序。
|
||||||
|
- 新增和编辑。
|
||||||
|
- 单条删除和批量删除。
|
||||||
|
- 导出。
|
||||||
|
- 字典下拉和表格状态展示。
|
||||||
|
- 弹窗关闭、成功回调和列表刷新。
|
||||||
Reference in New Issue
Block a user