64 lines
3.2 KiB
Markdown
64 lines
3.2 KiB
Markdown
---
|
|
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.
|