疯狂的狮子Li
112 lines
3.4 KiB
Markdown
112 lines
3.4 KiB
Markdown
# 使用案例
|
|
|
|
## 案例 1：新增标准 CRUD 页面
|
|
|
|
### 用户提问示例
|
|
|
|
```text
|
|
使用 $frontend-crud-coding 为 system/client 补一套前端 CRUD 页面。
|
|
后端接口已经有 /system/client/list、/system/client/{id}、POST /system/client、PUT /system/client、DELETE /system/client/{ids}。
|
|
请参考 generator 模板和现有的 system/user、system/config 页面风格实现。
|
|
```
|
|
|
|
### 期望执行方式
|
|
|
|
- 先看 `src/api/system/client/*` 是否已存在。
|
|
- 再看 `src/views/system/client/index.vue` 是否为空或缺失。
|
|
- 参考同目录系统模块页面，确定是否需要搜索卡片、表格卡片、弹窗、导出按钮。
|
|
- 再参考关联后端工程中的 generator 模板，补齐基础骨架。
|
|
|
|
### 期望产物
|
|
|
|
- `src/api/system/client/index.ts`
|
|
- `src/api/system/client/types.ts`
|
|
- `src/views/system/client/index.vue`
|
|
|
|
## 案例 2：把 generator 模板落成当前项目风格
|
|
|
|
### 用户提问示例
|
|
|
|
```text
|
|
使用 $frontend-crud-coding 按 generator 模板为 demo/order 生成一个标准页面，但不要直接复制模板，要改成当前前端项目现有样式壳和工具链写法。
|
|
```
|
|
|
|
### 期望执行方式
|
|
|
|
- 先看 generator 的 `ts/types/index.vue` 模板。
|
|
- 再看 `src/views/demo/demo/index.vue`、`src/views/system/user/index.vue` 的实际风格差异。
|
|
- 生成的页面要使用当前项目里的 `right-toolbar`、`pagination`、`proxy?.$modal`、`proxy?.download` 等。
|
|
|
|
## 案例 3：修改已有列表页
|
|
|
|
### 用户提问示例
|
|
|
|
```text
|
|
使用 $frontend-crud-coding 修改 system/user 页面：
|
|
1. 新增一个创建时间快捷筛选
|
|
2. 导出按钮放到更多菜单中
|
|
3. 保持现有样式和交互不变
|
|
```
|
|
|
|
### 期望执行方式
|
|
|
|
- 优先阅读现有 `src/views/system/user/index.vue`。
|
|
- 判断这是“已有页面增强”，不是“重新生成页面”。
|
|
- 保留树筛选、导入导出、列显隐、角色分配等现有能力。
|
|
- 增量修改，而不是重写整个页面。
|
|
|
|
## 案例 4：补齐复杂业务页面
|
|
|
|
### 用户提问示例
|
|
|
|
```text
|
|
使用 $frontend-crud-coding 为 workflow/category 增加导入、导出和状态切换功能，参考 system/user 的完整页面能力，但保持 workflow 模块自己的风格。
|
|
```
|
|
|
|
### 期望执行方式
|
|
|
|
- 优先看 `src/views/workflow/category/index.vue`。
|
|
- 再看 `src/views/system/user/index.vue` 里复杂列表页的做法。
|
|
- 只迁移需要的能力，不把用户模块专属逻辑照搬到 workflow 页面。
|
|
|
|
## 案例 5：只补 API 和 types
|
|
|
|
### 用户提问示例
|
|
|
|
```text
|
|
使用 $frontend-crud-coding 为 monitor/cache 补全前端 API 和 types，页面先不改。
|
|
```
|
|
|
|
### 期望执行方式
|
|
|
|
- 只维护 `src/api/monitor/cache/index.ts` 和 `src/api/monitor/cache/types.ts`。
|
|
- 仍然要与后端路由、现有 API 风格、返回类型保持一致。
|
|
|
|
## 案例 6：推荐的高质量任务描述
|
|
|
|
下面这种描述最容易得到稳定结果：
|
|
|
|
```text
|
|
使用 $frontend-crud-coding 在当前前端项目中新增一个 `/system/notice` 列表页增强：
|
|
1. 保留现有页面
|
|
2. 新增状态筛选和导出
|
|
3. API 路径沿用后端现有接口
|
|
4. 参考 system/user 的工具栏与导出交互
|
|
5. 参考 generator 模板补齐缺失的 types 定义
|
|
```
|
|
|
|
## 不推荐的任务描述
|
|
|
|
下面这种描述太模糊，容易让产物偏离项目：
|
|
|
|
```text
|
|
帮我写个后台页面
|
|
```
|
|
|
|
更好的写法至少要补充：
|
|
|
|
- 模块名
|
|
- 业务名
|
|
- 后端接口前缀
|
|
- 是新增还是修改
|
|
- 想参考哪个现有页面 |