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