Browse Source

docs: add explicit requirement for components to hide on unsupported platforms

- Add CRITICAL REQUIREMENT in Platform Detection Strategy section
- Add Component Visibility Requirements listing all components
- Add Component Visibility Requirements section in Implementation Notes
- Include required pattern with code examples for component hiding
- Add verification checklist for component hiding
- Update Phase 2 tasks to require platform support checks
- Update Phase 3 tasks to require hiding for all notification views
- Add Risk 6 for components visible on unsupported platforms
- Update acceptance criteria to verify component hiding
- Update success criteria to verify hiding on Web/Electron platforms
pull/214/head
Matthew Raymer 1 week ago
parent
commit
7ae3b241dd
  1. 90
      doc/daily-notification-plugin-integration-plan.md

90
doc/daily-notification-plugin-integration-plan.md

@ -107,6 +107,8 @@ This plan outlines the integration of `@timesafari/daily-notification-plugin` in
**Pattern**: PlatformService interface - all platforms implement methods
**CRITICAL REQUIREMENT**: All notification scheduling components MUST hide themselves if the current device does not support scheduling.
Components check PlatformService capabilities by calling methods and checking for `null` returns:
```typescript
@ -127,6 +129,12 @@ if (status === null) {
- Unsupported platforms return `null` or throw clear errors
- Components handle capability detection via method results, not environment variables
**Component Visibility Requirements**:
- **ScheduleView**: Must check platform support and hide/render placeholder if unsupported
- **AccountViewView notification section**: Must use `v-if="notificationsSupported"` to hide section
- **NotificationSettingsView**: Must check platform support before rendering
- **Any component providing scheduling UI**: Must verify `getDailyNotificationStatus() !== null` before showing scheduling controls
### Web/Electron Implementation Strategy
#### Web Platform
@ -709,6 +717,8 @@ interface Settings {
3. **Schedule View**
- Create `ScheduleView.vue` (provided code as reference)
- **REQUIRED**: Check platform support on mount - hide component if `getDailyNotificationStatus()` returns `null`
- **REQUIRED**: Render placeholder/unsupported message if device doesn't support scheduling
- Integrate with PlatformService via PlatformServiceFactory
- Add error handling
- Replace `console.*` with project logger
@ -732,7 +742,9 @@ interface Settings {
- [ ] ActionCard and StatusCard components created
- [ ] Home view shows notification diagnostics
- [ ] Schedule view allows notification scheduling
- [ ] **ScheduleView hides itself on unsupported platforms** (returns null check)
- [ ] AccountViewView has separate "Daily Notifications" section
- [ ] **AccountViewView notification section hidden on unsupported platforms** (`v-if="notificationsSupported"`)
- [ ] Notification section checks PlatformService capabilities before showing
- [ ] Toggle and time input functional in AccountViewView
- [ ] Settings persist across app restarts
@ -752,8 +764,11 @@ interface Settings {
#### Tasks
1. **Supporting Views**
- Create `NotificationsView.vue` (list scheduled notifications)
- **REQUIRED**: Hide component if `getDailyNotificationStatus()` returns `null`
- Create `NotificationHistoryView.vue` (notification history)
- **REQUIRED**: Hide component if `getDailyNotificationStatus()` returns `null`
- Create `NotificationSettingsView.vue` (settings/preferences)
- **REQUIRED**: Hide component if `getDailyNotificationStatus()` returns `null`
2. **Native Fetcher Configuration**
- Integrate `configureNativeFetcher()` in HomeView
@ -769,6 +784,7 @@ interface Settings {
#### Acceptance Criteria
- [ ] All supporting views created and functional
- [ ] **All notification views hide themselves on unsupported platforms**
- [ ] Native fetcher configuration working
- [ ] Permission requests handled properly
- [ ] Status updates after permission changes
@ -911,6 +927,70 @@ interface Settings {
## Implementation Notes
### Component Visibility Requirements
**CRITICAL**: All components that provide notification scheduling UI MUST hide themselves if the current device does not support scheduling.
#### Required Pattern for All Scheduling Components
```typescript
// In component mounted/created lifecycle
async mounted() {
const platformService = PlatformServiceFactory.getInstance();
const status = await platformService.getDailyNotificationStatus();
if (status === null) {
// Device does not support scheduling - hide component
this.notificationsSupported = false;
return;
}
// Device supports scheduling - proceed with initialization
this.notificationsSupported = true;
// ... rest of initialization
}
```
#### Template Pattern
```vue
<!-- Option 1: Conditional rendering with v-if -->
<section v-if="notificationsSupported">
<!-- Scheduling UI -->
</section>
<!-- Option 2: Early return in component logic -->
<template>
<div v-if="notificationsSupported">
<!-- Scheduling UI -->
</div>
<div v-else>
<!-- Optional: Show unsupported message -->
<p>Notifications are not supported on this platform.</p>
</div>
</template>
```
#### Components That Must Implement This Pattern
1. **ScheduleView.vue**: Check support on mount, hide if unsupported
2. **AccountViewView.vue**: Daily Notifications section uses `v-if="notificationsSupported"`
3. **NotificationSettingsView.vue**: Check support, hide if unsupported
4. **NotificationsView.vue**: Check support, hide if unsupported
5. **NotificationHistoryView.vue**: Check support, hide if unsupported
6. **Any other component providing scheduling UI**: Must check and hide if unsupported
#### Verification Checklist
- [ ] ScheduleView checks platform support and hides on unsupported platforms
- [ ] AccountViewView notification section hidden via `v-if` on unsupported platforms
- [ ] NotificationSettingsView checks and hides on unsupported platforms
- [ ] NotificationsView checks and hides on unsupported platforms
- [ ] NotificationHistoryView checks and hides on unsupported platforms
- [ ] All components tested on Web/Electron to verify hiding works
- [ ] No console errors when components are hidden
- [ ] Routes remain accessible but components show unsupported message (for ScheduleView)
### Code Quality Standards
- **Logging**: Use `logger` from `@/utils/logger`, not `console.*`
- **File Documentation**: Add file-level documentation headers
@ -995,6 +1075,14 @@ await platformService.scheduleDailyNotification({
- Follow existing UI patterns for consistency
- Add comprehensive error handling
### Risk 6: Components Visible on Unsupported Platforms
**Mitigation**:
- **REQUIRED**: All scheduling components must check `getDailyNotificationStatus()` and hide if `null`
- Use `v-if="notificationsSupported"` pattern consistently
- Add explicit verification in acceptance criteria
- Test on Web/Electron builds to verify hiding works
- Document required pattern in Implementation Notes section
---
## Success Criteria Summary
@ -1003,12 +1091,14 @@ await platformService.scheduleDailyNotification({
- [ ] Feature works on Capacitor (Android/iOS)
- [ ] Feature hidden/graceful on Web/Electron
- [ ] All components created and functional
- [ ] **All scheduling components hide themselves on unsupported platforms**
- [ ] AccountViewView integration complete and functional
- [ ] Store manages notification state
- [ ] Router routes accessible
- [ ] Logging standardized (no console.*)
- [ ] Error handling robust
- [ ] Cross-platform testing complete
- [ ] **Verified component hiding on Web/Electron platforms**
- [ ] Documentation updated
- [ ] No build regressions

Loading…
Cancel
Save