refactor: standardize notification usage and document best practices

Move all user-facing notification messages to src/constants/notifications.ts
Use TIMEOUTS constants from src/utils/notify.ts for all notification durations
Refactor ActivityListItem.vue:
Use notification message and duration constants
Initialize notify helper in created() with createNotifyHelpers(this.$notify)
Add $notify property for Vue runtime injection to satisfy type checker
Use type guards or 'as any' for unknown notification payloads
Wrap notifyWhyCannotConfirm calls to match expected function signature
Fix type import for GiveRecordWithContactInfo
Add 'Notification Best Practices and Nuances' section to migration-progress-tracker.md:
Document message/duration constants, notify helper pattern, type safety, and wrapper function usage
Remove all hardcoded notification strings and durations from components
This commit is contained in:
Matthew Raymer
2025-07-06 12:19:31 +00:00
parent 8d5e4ddbfb
commit dd22e1b884
6 changed files with 45 additions and 26 deletions

View File

@@ -381,5 +381,19 @@ find src -name "*.vue" -o -name "*.ts" | xargs grep -l "import.*databaseUtil" |
---
## 🎯 **Notification Best Practices and Nuances**
- **All user-facing notification messages must be defined as constants** in `src/constants/notifications.ts`. Do not hardcode notification strings in components.
- **All notification durations/timeouts must use the `TIMEOUTS` constants** from `src/utils/notify.ts`. Do not hardcode durations.
- **Notification helpers (`this.notify`) must be initialized as a property in `created()`** using `createNotifyHelpers(this.$notify)`.
- **Never hardcode notification strings or durations in components.**
- **When using `notifyWhyCannotConfirm` or similar utilities, pass a wrapper function** if the signature expects a raw notify function (e.g., `(msg, timeout) => this.notify.info(msg.text ?? '', timeout)`).
- **Declare `$notify` as a property on the class** to satisfy the type checker, since Vue injects it at runtime.
- **Use type guards or `as any` for unknown notification payloads** when necessary, but prefer type safety where possible.
These practices ensure maintainability, consistency, and type safety for all notification-related code during and after migration.
---
**Last Updated**: $(date)
**Next Review**: After each phase completion