Refactor documentation standards and structure; consolidate clean code principles and service documentation requirements
This commit is contained in:
@@ -6,99 +6,44 @@ alwaysApply: false
|
||||
|
||||
# Frontend Standards
|
||||
|
||||
## Component Design
|
||||
When working with frontend files, follow these standards:
|
||||
|
||||
### React Components
|
||||
- Single responsibility per component
|
||||
- Props validation with PropTypes
|
||||
- Error boundary protection
|
||||
- Reusable and composable design
|
||||
- Maximum 50 lines per component file
|
||||
## Documentation References
|
||||
- **Frontend README**: @frontend/README.md
|
||||
- **Clean Code Guide**: @frontend/CLEAN_CODE.md
|
||||
- **Resilience Features**: @frontend/RESILIENCE.md
|
||||
|
||||
### Component Structure
|
||||
```
|
||||
src/
|
||||
├── components/
|
||||
│ ├── common/ # Reusable UI components
|
||||
│ ├── dashboard/ # Dashboard-specific components
|
||||
│ └── [main components] # Main application components
|
||||
├── hooks/ # Custom React hooks
|
||||
├── services/ # API and external services
|
||||
├── utils/ # Utility functions
|
||||
└── constants/ # Configuration constants
|
||||
```
|
||||
## Component Structure
|
||||
Follow the structure defined in @frontend/README.md:
|
||||
- **Common Components**: @frontend/src/components/common/
|
||||
- **Dashboard Components**: @frontend/src/components/dashboard/
|
||||
- **Custom Hooks**: @frontend/src/hooks/
|
||||
- **API Services**: @frontend/src/services/
|
||||
- **Utilities**: @frontend/src/utils/
|
||||
- **Constants**: @frontend/src/constants/
|
||||
|
||||
## Clean Code Principles
|
||||
Apply the principles detailed in @frontend/CLEAN_CODE.md:
|
||||
- Single Responsibility Principle
|
||||
- Component Composition
|
||||
- Error Handling with Error Boundaries
|
||||
- Performance Optimization
|
||||
|
||||
## Naming Conventions
|
||||
|
||||
### JavaScript/TypeScript
|
||||
- Classes: PascalCase (e.g., `DashboardComponent`)
|
||||
- Functions: camelCase (e.g., `fetchServiceSpec`)
|
||||
- Variables: camelCase (e.g., `serviceStatus`)
|
||||
- Constants: UPPER_SNAKE_CASE (e.g., `API_CONFIG`)
|
||||
|
||||
### File Organization
|
||||
## File Organization
|
||||
- Component files: PascalCase (e.g., `Dashboard.js`)
|
||||
- Hook files: camelCase with 'use' prefix (e.g., `useServiceStatus.js`)
|
||||
- Utility files: camelCase (e.g., `errorHandling.js`)
|
||||
- Constant files: camelCase (e.g., `index.js`)
|
||||
|
||||
## Clean Code Principles
|
||||
|
||||
### Single Responsibility Principle (SRP)
|
||||
- Each component has one clear purpose
|
||||
- `SystemStatsCards` only handles system statistics display
|
||||
- `ServiceStatusList` only manages service status display
|
||||
- `StatusIcon` only renders status icons
|
||||
|
||||
### Don't Repeat Yourself (DRY)
|
||||
- Centralized status icon logic in `StatusIcon` component
|
||||
- Reusable loading component in `LoadingSpinner`
|
||||
- Centralized error handling in `utils/errorHandling.js`
|
||||
- All constants extracted to `constants/index.js`
|
||||
|
||||
### Component Composition
|
||||
- Large components broken into smaller, focused components
|
||||
- Clear prop interfaces with PropTypes validation
|
||||
- Easy to test and maintain
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Error Boundaries
|
||||
- `ErrorBoundary` component for graceful error recovery
|
||||
- Development-friendly error details
|
||||
- User-friendly error messages
|
||||
|
||||
### Offline Mode
|
||||
- Service status monitoring
|
||||
- Fallback data when services unavailable
|
||||
- Automatic retry mechanisms
|
||||
- Clear status indicators
|
||||
|
||||
## Performance
|
||||
|
||||
### Component Optimization
|
||||
- Smaller components = better React optimization
|
||||
- Reduced re-renders through focused components
|
||||
- Memoization opportunities for pure components
|
||||
|
||||
### Code Splitting Ready
|
||||
- Modular structure supports code splitting
|
||||
- Easy to lazy load dashboard components
|
||||
- Clear separation enables tree shaking
|
||||
|
||||
## Testing
|
||||
|
||||
### Testable Components
|
||||
- Pure functions in utils
|
||||
- Isolated component logic
|
||||
- Clear prop interfaces
|
||||
- Mockable dependencies
|
||||
|
||||
### Test Structure
|
||||
```javascript
|
||||
describe('SystemStatsCards', () => {
|
||||
it('renders CPU usage correctly', () => {
|
||||
// Test focused component
|
||||
});
|
||||
});
|
||||
```
|
||||
## Component Design
|
||||
- Single responsibility per component
|
||||
- Maximum 50 lines per component file
|
||||
- Props validation with PropTypes
|
||||
- Error boundary protection
|
||||
- Reusable and composable design
|
||||
Reference in New Issue
Block a user