diff --git a/README-context.md b/README-context.md index a22e2600..f4ebf0e8 100644 --- a/README-context.md +++ b/README-context.md @@ -111,24 +111,161 @@ When developing new features, be mindful of these constraints: ## Core Development Principles -- DRY development -- SOLID principles -- Law of Demeter -- Composition over Inheritence -- Interface Segregation -- Fail Fast -- Principle of Least Astonishment -- Information Hiding -- Single Source of Truth -- Principle of Least Privilege -- Continuous Integration/Continuous Deployment (CI/CD) +### DRY development +- **Code Reuse** + - Extract common functionality into utility functions + - Create reusable components for UI patterns + - Implement service classes for shared business logic + - Use mixins for cross-cutting concerns + - Leverage TypeScript interfaces for shared type definitions + +- **Component Patterns** + - Create base components for common UI elements + - Implement higher-order components for shared behavior + - Use slot patterns for flexible component composition + - Create composable services for business logic + - Implement factory patterns for component creation + +- **State Management** + - Centralize state in Pinia stores + - Use computed properties for derived state + - Implement shared state selectors + - Create reusable state mutations + - Use action creators for common operations + +- **Error Handling** + - Implement centralized error handling + - Create reusable error components + - Use error boundary components + - Implement consistent error logging + - Create error type definitions + +- **Type Definitions** + - Create shared interfaces for common data structures + - Use type aliases for complex types + - Implement generic types for reusable components + - Create utility types for common patterns + - Use discriminated unions for state management + +- **API Integration** + - Create reusable API client classes + - Implement request/response interceptors + - Use consistent error handling patterns + - Create type-safe API endpoints + - Implement caching strategies + +- **Platform Services** + - Abstract platform-specific code behind interfaces + - Create platform-agnostic service layers + - Implement feature detection + - Use dependency injection for services + - Create service factories + +- **Testing** + - Create reusable test utilities + - Implement test factories + - Use shared test configurations + - Create reusable test helpers + - Implement consistent test patterns + +### SOLID Principles +- **Single Responsibility**: Each class/component should have only one reason to change + - Components should focus on one specific feature (e.g., QR scanning, DID management) + - Services should handle one type of functionality (e.g., platform services, crypto services) + - Utilities should provide focused helper functions + +- **Open/Closed**: Software entities should be open for extension but closed for modification + - Use interfaces for service definitions + - Implement plugin architecture for platform-specific features + - Allow component behavior extension through props and events + +- **Liskov Substitution**: Objects should be replaceable with their subtypes + - Platform services should work consistently across web/mobile + - Authentication providers should be interchangeable + - Storage implementations should be swappable + +- **Interface Segregation**: Clients shouldn't depend on interfaces they don't use + - Break down large service interfaces into smaller, focused ones + - Component props should be minimal and purposeful + - Event emissions should be specific and targeted + +- **Dependency Inversion**: High-level modules shouldn't depend on low-level modules + - Use dependency injection for services + - Abstract platform-specific code behind interfaces + - Implement factory patterns for component creation + +### Law of Demeter +- Components should only communicate with immediate dependencies +- Avoid chaining method calls (e.g., `this.service.getUser().getProfile().getName()`) +- Use mediator patterns for complex component interactions +- Implement facade patterns for subsystem access +- Keep component communication through defined events and props + +### Composition over Inheritance +- Prefer building components through composition +- Use mixins for shared functionality +- Implement feature toggles through props +- Create higher-order components for common patterns +- Use service composition for complex features + +### Interface Segregation +- Define clear interfaces for services +- Keep component APIs minimal and focused +- Split large interfaces into smaller, specific ones +- Use TypeScript interfaces for type definitions +- Implement role-based interfaces for different use cases + +### Fail Fast +- Validate inputs early in the process +- Use TypeScript strict mode +- Implement comprehensive error handling +- Add runtime checks for critical operations +- Use assertions for development-time validation + +### Principle of Least Astonishment +- Follow Vue.js conventions consistently +- Use familiar naming patterns +- Implement predictable component behaviors +- Maintain consistent error handling +- Keep UI interactions intuitive + +### Information Hiding +- Encapsulate implementation details +- Use private class members +- Implement proper access modifiers +- Hide complex logic behind simple interfaces +- Use TypeScript's access modifiers effectively + +### Single Source of Truth +- Use Pinia for state management +- Maintain one source for user data +- Centralize configuration management +- Use computed properties for derived state +- Implement proper state synchronization + +### Principle of Least Privilege +- Implement proper access control +- Use minimal required permissions +- Follow privacy-by-design principles +- Restrict component access to necessary data +- Implement proper authentication/authorization + +### Continuous Integration/Continuous Deployment (CI/CD) +- Automated testing on every commit +- Consistent build process across platforms +- Automated deployment pipelines +- Quality gates for code merging +- Environment-specific configurations + +This expanded documentation provides: +1. Clear principles for development +2. Practical implementation guidelines +3. Real-world examples +4. TypeScript integration +5. Best practices for Time Safari + +Would you like me to provide more specific examples for any of these principles? - Ensure all components support accessibility first design -- Implement privacy-preserving features by default -- Support progressive enhancement across devices -- Enable voluntary collaboration features -- Build trust-enabling interactions -- Optimize for low resource requirements -- Support offline-first functionality where possible - Use class-based syntax with decorators from vue-facing-decorators. - Should attempt to maximize Lighthouse Score as close to 100 as possible. - Use Lighthouse for performance scoring