Refactor documentation standards and structure; consolidate clean code principles and service documentation requirements

This commit is contained in:
glenn schrooyen
2025-09-11 23:51:00 +02:00
parent b9206de1a0
commit 83fb444196
6 changed files with 177 additions and 530 deletions

View File

@@ -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