forked from trent_larson/crowd-funder-for-time-pwa
Remove contact caching and add contact method standardization to migration template
• Remove contact caching: $contacts() always returns fresh data • Simplify cache infrastructure: Remove unused contact TTL constants • Add Phase 2.5 to migration template: Contact Method Standardization • Update migration pattern: 4-phase → 5-phase Enhanced Migration Pattern • Eliminate inconsistency: 12 components need $getAllContacts() → $contacts() Migration Impact: - Before: 70% non-cached, 30% cached contact fetching (inconsistent) - After: 100% fresh contact data with unified $contacts() method - Template enforces: Consistent contact patterns in all future migrations
This commit is contained in:
Matthew Raymer
@@ -3,6 +3,19 @@
|
||||
## Overview
|
||||
This checklist ensures NO migration steps are forgotten. **Every component migration MUST complete ALL sections.**
|
||||
|
||||
## Requirements
|
||||
|
||||
**EVERY component migration MUST complete ALL FIVE migration types:**
|
||||
|
||||
1. **Database Migration**: Replace databaseUtil calls with PlatformServiceMixin methods
|
||||
2. **SQL Abstraction**: Replace raw SQL queries with service methods
|
||||
2.5. **Contact Method Standardization**: Replace inconsistent contact fetching patterns
|
||||
3. **Notification Migration**: Replace `$notify()` calls with helper methods + centralized constants
|
||||
4. **Template Streamlining**: Extract repeated expressions and complex logic to computed properties
|
||||
|
||||
**❌ INCOMPLETE**: Any migration missing one of these steps
|
||||
**✅ COMPLETE**: All five patterns implemented with code quality review
|
||||
|
||||
## ⏱️ **TIME TRACKING REQUIREMENT**: All migrations must be timed and performance recorded
|
||||
|
||||
## 🎯 **USER CONTROL COMMANDS**: For seamless migration workflow
|
||||
@@ -126,20 +139,35 @@ git commit -m "[user-approved-message]"
|
||||
- [ ] Generic queries → appropriate service methods
|
||||
- [ ] **NO RAW SQL ALLOWED**: All database operations through service layer
|
||||
|
||||
## Phase 2.5: Contact Method Standardization
|
||||
|
||||
### [ ] 8. Standardize Contact Fetching Methods
|
||||
- [ ] **CRITICAL**: Replace `this.$getAllContacts()` → `this.$contacts()`
|
||||
- [ ] **REASON**: Eliminate inconsistent contact fetching patterns
|
||||
- [ ] **BENEFIT**: All components use same contact data source
|
||||
- [ ] **VALIDATION**: Search for `$getAllContacts` and replace with `$contacts`
|
||||
- [ ] **CONSISTENCY**: All contact operations use unified approach
|
||||
|
||||
### [ ] 9. Verify Contact Method Consistency
|
||||
- [ ] **NO** `$getAllContacts()` calls remain in component
|
||||
- [ ] **ALL** contact fetching uses `$contacts()` method
|
||||
- [ ] **CONSISTENT** contact data across component lifecycle
|
||||
- [ ] **VALIDATED**: Component uses standardized contact API
|
||||
|
||||
## Phase 3: Notification Migration
|
||||
|
||||
### [ ] 8. Add Notification Infrastructure
|
||||
### [ ] 10. Add Notification Infrastructure
|
||||
- [ ] Add import: `import { createNotifyHelpers, TIMEOUTS } from "@/utils/notify"`
|
||||
- [ ] Add property: `notify!: ReturnType<typeof createNotifyHelpers>;`
|
||||
- [ ] Add initialization: `created() { this.notify = createNotifyHelpers(this.$notify); }`
|
||||
|
||||
### [ ] 9. Add Notification Constants to Central File
|
||||
### [ ] 11. Add Notification Constants to Central File
|
||||
- [ ] **CRITICAL**: Add constants to `src/constants/notifications.ts` (NOT local constants)
|
||||
- [ ] Use naming pattern: `NOTIFY_[COMPONENT]_[ACTION]` (e.g., `NOTIFY_OFFER_SETTINGS_ERROR`)
|
||||
- [ ] Import constants: `import { NOTIFY_X, NOTIFY_Y } from "@/constants/notifications"`
|
||||
- [ ] **NO LOCAL CONSTANTS**: All notification text must be centralized
|
||||
|
||||
### [ ] 10. Replace Notification Calls
|
||||
### [ ] 12. Replace Notification Calls
|
||||
- [ ] **Warning**: `this.$notify({type: "warning"})` → `this.notify.warning(CONSTANT.message, TIMEOUTS.LONG)`
|
||||
- [ ] **Error**: `this.$notify({type: "danger"})` → `this.notify.error(CONSTANT.message, TIMEOUTS.LONG)`
|
||||
- [ ] **Success**: `this.$notify({type: "success"})` → `this.notify.success(CONSTANT.message, TIMEOUTS.STANDARD)`
|
||||
@@ -147,7 +175,7 @@ git commit -m "[user-approved-message]"
|
||||
- [ ] **Confirm**: `this.$notify({type: "confirm"})` → `this.notify.confirm(message, onYes)`
|
||||
- [ ] **Standard patterns**: Use `this.notify.confirmationSubmitted()`, `this.notify.sent()`, etc.
|
||||
|
||||
### [ ] 11. Constants vs Literal Strings
|
||||
### [ ] 13. Constants vs Literal Strings
|
||||
- [ ] **Use constants** for static, reusable messages
|
||||
- [ ] **Use literal strings** for dynamic messages with variables
|
||||
- [ ] **Extract literals from complex modals** - Even raw `$notify` calls should use constants for text
|
||||
@@ -155,19 +183,19 @@ git commit -m "[user-approved-message]"
|
||||
|
||||
## Phase 4: Template Streamlining
|
||||
|
||||
### [ ] 12. Identify Template Complexity Patterns
|
||||
### [ ] 14. Identify Template Complexity Patterns
|
||||
- [ ] **Repeated CSS Classes**: Long Tailwind strings used multiple times
|
||||
- [ ] **Complex Configuration Objects**: Multi-line objects in template
|
||||
- [ ] **Repeated Function Calls**: Same logic executed multiple times
|
||||
- [ ] **Complex Conditional Logic**: Nested ternary or complex boolean expressions
|
||||
|
||||
### [ ] 13. Extract to Computed Properties
|
||||
### [ ] 15. Extract to Computed Properties
|
||||
- [ ] **CSS Class Groups**: Extract repeated styling to computed properties
|
||||
- [ ] **Configuration Objects**: Move router configs, form configs to computed
|
||||
- [ ] **Conditional Logic**: Extract complex `v-if` conditions to computed properties
|
||||
- [ ] **Dynamic Values**: Convert repeated calculations to cached computed properties
|
||||
|
||||
### [ ] 14. Document Computed Properties
|
||||
### [ ] 16. Document Computed Properties
|
||||
- [ ] **JSDoc Comments**: Add comprehensive comments for all computed properties
|
||||
- [ ] **Purpose Documentation**: Explain what template complexity each property solves
|
||||
- [ ] **Organized Sections**: Group related computed properties with section headers
|
||||
@@ -175,19 +203,19 @@ git commit -m "[user-approved-message]"
|
||||
|
||||
## Phase 5: Code Quality Review
|
||||
|
||||
### [ ] 15. Template Quality Assessment
|
||||
### [ ] 17. Template Quality Assessment
|
||||
- [ ] **Readability**: Template is easy to scan and understand
|
||||
- [ ] **Maintainability**: Styling changes can be made in one place
|
||||
- [ ] **Performance**: Computed properties cache expensive operations
|
||||
- [ ] **Consistency**: Similar patterns use similar solutions
|
||||
|
||||
### [ ] 16. Component Architecture Review
|
||||
### [ ] 18. Component Architecture Review
|
||||
- [ ] **Single Responsibility**: Component has clear, focused purpose
|
||||
- [ ] **Props Interface**: Clear, well-documented component props
|
||||
- [ ] **Event Emissions**: Appropriate event handling and emission
|
||||
- [ ] **State Management**: Component state is minimal and well-organized
|
||||
|
||||
### [ ] 17. Code Organization Review
|
||||
### [ ] 19. Code Organization Review
|
||||
- [ ] **Import Organization**: Imports are grouped logically (Vue, constants, services)
|
||||
- [ ] **Method Organization**: Methods are grouped by purpose with section headers
|
||||
- [ ] **Property Organization**: Data properties are documented and organized
|
||||
@@ -195,17 +223,17 @@ git commit -m "[user-approved-message]"
|
||||
|
||||
## Validation Phase
|
||||
|
||||
### [ ] 18. Run Validation Script
|
||||
### [ ] 20. Run Validation Script
|
||||
- [ ] Execute: `scripts/validate-migration.sh`
|
||||
- [ ] **MUST show**: "Technically Compliant" (not "Mixed Pattern")
|
||||
- [ ] **Zero** legacy patterns detected
|
||||
|
||||
### [ ] 19. Run Linting
|
||||
### [ ] 21. Run Linting
|
||||
- [ ] Execute: `npm run lint-fix`
|
||||
- [ ] **Zero errors** introduced
|
||||
- [ ] **TypeScript compiles** without errors
|
||||
|
||||
### [ ] 20. Manual Code Review
|
||||
### [ ] 22. Manual Code Review
|
||||
- [ ] **NO** `databaseUtil` imports or calls
|
||||
- [ ] **NO** raw SQL queries (`SELECT`, `INSERT`, `UPDATE`, `DELETE`)
|
||||
- [ ] **NO** `$notify()` calls with object syntax
|
||||
@@ -217,25 +245,25 @@ git commit -m "[user-approved-message]"
|
||||
|
||||
## ⏱️ Time Tracking & Commit Phase
|
||||
|
||||
### [ ] 21. End Time Tracking
|
||||
### [ ] 23. End Time Tracking
|
||||
- [ ] **MANDATORY**: Run `./scripts/time-migration.sh [ComponentName.vue] end`
|
||||
- [ ] Record total duration from terminal output
|
||||
- [ ] Note any blockers or issues that impacted timing
|
||||
|
||||
### [ ] 22. Commit with Time Data
|
||||
### [ ] 24. Commit with Time Data
|
||||
- [ ] **MANDATORY**: Include time data in commit message
|
||||
- [ ] Use template: `Complete [ComponentName] Enhanced Triple Migration Pattern (X minutes)`
|
||||
- [ ] Include complexity level and any issues encountered
|
||||
- [ ] Document specific changes made in each phase
|
||||
|
||||
### [ ] 23. Performance Analysis
|
||||
### [ ] 25. Performance Analysis
|
||||
- [ ] Compare actual time vs. estimated time for complexity level
|
||||
- [ ] Note if component was faster/slower than expected
|
||||
- [ ] Document any efficiency improvements discovered
|
||||
|
||||
## Documentation Phase
|
||||
|
||||
### [ ] 24. Update Migration Documentation
|
||||
### [ ] 26. Update Migration Documentation
|
||||
- [ ] Create `docs/migration-testing/[COMPONENT]_MIGRATION.md`
|
||||
- [ ] Document all changes made (database, SQL, notifications, template)
|
||||
- [ ] Include before/after examples for template streamlining
|
||||
@@ -243,7 +271,7 @@ git commit -m "[user-approved-message]"
|
||||
- [ ] Provide a guide to finding the components in the user interface
|
||||
- [ ] Include code quality review notes
|
||||
|
||||
### [ ] 25. Update Testing Tracker
|
||||
### [ ] 27. Update Testing Tracker
|
||||
- [ ] Update `docs/migration-testing/HUMAN_TESTING_TRACKER.md`
|
||||
- [ ] Mark component as "Ready for Testing"
|
||||
- [ ] Include notes about migration completed with template streamlining
|
||||
@@ -251,7 +279,7 @@ git commit -m "[user-approved-message]"
|
||||
|
||||
## Human Testing Phase
|
||||
|
||||
### [ ] 26. Test All Functionality
|
||||
### [ ] 28. Test All Functionality
|
||||
- [ ] **Core functionality** works correctly
|
||||
- [ ] **Database operations** function properly
|
||||
- [ ] **Notifications** display correctly with proper timing
|
||||
@@ -259,14 +287,14 @@ git commit -m "[user-approved-message]"
|
||||
- [ ] **Template rendering** performs smoothly with computed properties
|
||||
- [ ] **Cross-platform** compatibility (web/mobile)
|
||||
|
||||
### [ ] 27. Confirm Testing Complete
|
||||
### [ ] 29. Confirm Testing Complete
|
||||
- [ ] User confirms component works correctly
|
||||
- [ ] Update testing tracker with results
|
||||
- [ ] Mark as "Human Tested" in validation script
|
||||
|
||||
## Final Validation
|
||||
|
||||
### [ ] 28. Comprehensive Check
|
||||
### [ ] 30. Comprehensive Check
|
||||
- [ ] Component shows as "Technically Compliant" in validation
|
||||
- [ ] All manual testing passed
|
||||
- [ ] Zero legacy patterns remain
|
||||
|
||||
Reference in New Issue
Block a user