规则文件
This commit is contained in:
63
.trae/rules/mock-data.md
Normal file
63
.trae/rules/mock-data.md
Normal file
@@ -0,0 +1,63 @@
|
|||||||
|
---
|
||||||
|
alwaysApply: false
|
||||||
|
description: 当新增包含业务逻辑的组件、页面或 API 请求时,必须同步创建符合真实性标准、类型规范及包含边缘情况的 Mock 数据。
|
||||||
|
---
|
||||||
|
# Mock Data Rules for Funtime Design System
|
||||||
|
|
||||||
|
These rules define the standards for creating, managing, and using mock data within the project. The goal is to ensure the development environment closely mirrors the production experience.
|
||||||
|
|
||||||
|
## 1. General Principles
|
||||||
|
|
||||||
|
- **Realism First**: NEVER use meaningless placeholders like "test1", "demo", "asdf", or "123". Data must look and feel like real production data.
|
||||||
|
- **Context Relevance**: Data must be relevant to the "Funtime Design" domain (e.g., design projects, assets, team members, creative workflows).
|
||||||
|
- **Consistency**: Ensure relationships between data entities make logical sense (e.g., a "published" project shouldn't have a creation date in the future).
|
||||||
|
- **Completeness**: Mock APIs should simulate latency (e.g., 300-800ms) to test loading states.
|
||||||
|
|
||||||
|
## 2. Data Content Standards
|
||||||
|
|
||||||
|
### Text Data
|
||||||
|
- **Names**: Use realistic full names (e.g., "Sarah Jenkins", "Michael Chen") or creative project names (e.g., "Summer 2024 Campaign", "Mobile App Redesign").
|
||||||
|
- **Descriptions**: Use complete sentences or paragraphs. Use Lorem Ipsum sparingly; prefer domain-specific generated text if possible, or meaningful placeholder text.
|
||||||
|
- **IDs**: Use UUIDs or realistic database IDs (e.g., `1001`, `9482`) rather than sequential single digits (`1`, `2`, `3`) unless specifically testing ordering.
|
||||||
|
|
||||||
|
### Visual Assets
|
||||||
|
- **Images**: Use consistent, high-quality placeholder image services or local assets.
|
||||||
|
- Avatars: `https://i.pravatar.cc/150?u={id}`
|
||||||
|
- Thumbnails: `https://picsum.photos/seed/{seed}/400/300`
|
||||||
|
- **Colors**: Use hex codes that align with the design system palette or realistic user-generated choices.
|
||||||
|
|
||||||
|
### Dates & Numbers
|
||||||
|
- **Dates**: Use ISO 8601 format (`2023-10-27T10:00:00Z`) or standard display formats. Distribute dates to show a timeline (past, recent, future).
|
||||||
|
- **Metrics**: Use realistic ranges (e.g., views: 100-50000, not 999999999).
|
||||||
|
|
||||||
|
## 3. Technical Implementation
|
||||||
|
|
||||||
|
### Structure
|
||||||
|
- **Response Wrapper**: All API responses must follow the standard response envelope:
|
||||||
|
```typescript
|
||||||
|
interface ApiResponse<T> {
|
||||||
|
code: number; // 0 or 200 for success
|
||||||
|
message: string; // "success" or error message
|
||||||
|
data: T; // The actual payload
|
||||||
|
}
|
||||||
|
```
|
||||||
|
- **Pagination**: List interfaces must support and mock pagination metadata:
|
||||||
|
```typescript
|
||||||
|
interface PageResult<T> {
|
||||||
|
items: T[];
|
||||||
|
total: number;
|
||||||
|
page: number;
|
||||||
|
pageSize: number;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Tooling
|
||||||
|
- **Library**: Use `vite-plugin-mock` for API interception.
|
||||||
|
- **Location**: Store mock definitions in `mock/` directory at the project root.
|
||||||
|
- **Typing**: All mock data generators must be typed against the project's TypeScript interfaces.
|
||||||
|
|
||||||
|
## 4. Edge Cases Coverage
|
||||||
|
|
||||||
|
- **Empty States**: Ensure there are scenarios or toggles to test empty lists/tables.
|
||||||
|
- **Long Content**: Include items with unusually long titles or descriptions to test text truncation and layout stability.
|
||||||
|
- **Status Variations**: Include all possible enum values (e.g., 'Draft', 'Pending', 'Published', 'Archived') to verify UI badge variations.
|
||||||
40
.trae/rules/project-rules.md
Normal file
40
.trae/rules/project-rules.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
# Project Rules for Funtime Design System
|
||||||
|
|
||||||
|
## 1. Tech Stack Constraints
|
||||||
|
- **Framework**: Vue 3 (Composition API, `<script setup lang="ts">`)
|
||||||
|
- **Language**: TypeScript (Strict Mode)
|
||||||
|
- **UI Library**: Element Plus
|
||||||
|
- **State Management**: Pinia
|
||||||
|
- **Build Tool**: Vite
|
||||||
|
- **CSS Preprocessor**: SCSS (scoped)
|
||||||
|
- **Icons**: `@element-plus/icons-vue`
|
||||||
|
|
||||||
|
## 2. Coding Standards
|
||||||
|
|
||||||
|
### Components
|
||||||
|
- **Syntax**: Must use `<script setup lang="ts">`. **NO** Options API allowed.
|
||||||
|
- **UI Components**: Prioritize **Element Plus** components.
|
||||||
|
- **Props**: Define props using TypeScript interfaces/types.
|
||||||
|
- **Styling**: Use scoped SCSS. Ensure responsive design.
|
||||||
|
|
||||||
|
### State Management (Pinia)
|
||||||
|
- **Syntax**: Use Setup Store syntax: `defineStore('id', () => { ... })`.
|
||||||
|
- **Reactivity**: Use `ref` or `reactive` for state.
|
||||||
|
- **Usage**: Export composable hooks (e.g., `useDesignStore`).
|
||||||
|
|
||||||
|
### Mock Data
|
||||||
|
- **Format**: JSON or TypeScript array.
|
||||||
|
- **Structure**: Follow `vite-plugin-mock` structure.
|
||||||
|
- **Content**: Use realistic data relevant to a product design context.
|
||||||
|
|
||||||
|
## 3. Design Guidelines
|
||||||
|
- **Layout**: Use `src/layout/index.vue` as the main layout structure (Sidebar + Header).
|
||||||
|
- **Colors**:
|
||||||
|
- Primary: `#409eff` (Element Plus Default)
|
||||||
|
- Background: `#f5f7fa`
|
||||||
|
- **Typography**: Helvetica Neue, Arial, sans-serif.
|
||||||
|
|
||||||
|
## 4. Interaction & UX Rules
|
||||||
|
- **User Feedback**: MUST use `ElMessage.success` or `ElMessage.error` for add/delete/update operations.
|
||||||
|
- **Loading States**: Display loading indicators during asynchronous operations.
|
||||||
|
- **Form Validation**: All input forms MUST include basic validation (at least non-empty checks).
|
||||||
Reference in New Issue
Block a user