🏠 Overview › ✅ Implementation Tasks ›✅ epic-pause-status-notifications-ui-task-005

Define PeerMentorConfirmationBanner data model

epic-pause-status-notifications-ui-task-005 — Define the Dart data model for the peer mentor confirmation banner, capturing the event type (pause activated or deactivated), the effective date, and an auto-dismiss duration constant. Ensure the model is immutable and can be easily constructed from a pause-status webhook payload or FCM message.

high priority low complexity frontend pending frontend specialist Tier 0

Acceptance Criteria

PeerMentorConfirmationBanner model is a Dart immutable class (using `const` constructor or `@immutable` annotation) with no mutable fields
Model has a required `eventType` field typed to a sealed class or enum with exactly two values: `pauseActivated` and `pauseDeactivated`
Model has a required `effectiveDate` field of type `DateTime`
Model exposes a static or constant `autoDismissDuration` of type `Duration` (default 4 seconds), overridable for testing
Model provides a factory constructor `PeerMentorConfirmationBannerModel.fromPayload(Map<String, dynamic> payload)` that safely parses FCM/webhook JSON without throwing on missing optional keys
Factory constructor returns null or throws a typed exception (not an unhandled crash) when required fields are absent from the payload
Model implements `==` and `hashCode` for value equality
Model includes a `copyWith` method for test convenience
No business logic or UI dependencies inside the model file

Technical Requirements

frameworks
Flutter
Dart
apis
Supabase Realtime (pause-status event payload)
Firebase Cloud Messaging (FCM) payload
data models
assignment
performance requirements
Model construction is O(1) — no network calls or async operations
security requirements
Model must not store personally identifiable information beyond what is needed for display (event type + date only)
Payload parsing must not log raw FCM data to console in production builds

Execution Context

Execution Tier
Tier 0

Tier 0 - 440 tasks

Implementation Notes

Place the model in the notifications feature layer (e.g., `lib/features/notifications/models/peer_mentor_confirmation_banner_model.dart`), not in a shared models directory, since it is specific to this banner. Use a Dart `enum` for `PauseEventType` rather than raw strings to prevent typo bugs. The `autoDismissDuration` should be a static const on the model class so it is accessible from the widget without coupling the widget to a config service. The `fromPayload` factory should handle both snake_case (FCM) and camelCase (Supabase Realtime) key formats if the project uses both, or document clearly which format is expected.

Testing Requirements

Unit tests: verify that `fromPayload` correctly parses both `pause_activated` and `pause_deactivated` event types; verify that `effectiveDate` is parsed correctly from ISO 8601 strings; verify that missing required keys in the payload produce a typed error and not an unhandled exception; verify equality and `copyWith` behavior. No widget pump needed for this pure data model.

Component
Peer Mentor Confirmation Banner
ui low
Epic Risks (2)
medium impact low prob integration

The existing notification feed component may expect a specific notification model shape that does not map cleanly to the pause notification payload structure, requiring either payload transformation or feed refactoring.

Mitigation & Contingency

Mitigation: Review the notification-list-item and notification-model contracts before building the card. Design the pause-notification-card to extend or wrap the existing list item pattern rather than replacing it.

Contingency: If the feed contract is incompatible, implement a lightweight adapter that maps the pause notification payload to the feed's expected model shape, keeping the adapter isolated from the core card widget.

low impact low prob dependency

The app's existing toast/banner infrastructure may not support the auto-dismiss timeout duration or dismissal animation required for the peer mentor confirmation banner, necessitating a custom implementation that diverges from the design system.

Mitigation & Contingency

Mitigation: Audit the existing banner and toast components (in-app-notification-banner, notification-list-item) for configurable dismiss timeout before starting implementation. Prefer configuration over custom code.

Contingency: If the existing infrastructure cannot be configured, implement the banner as a thin wrapper with a custom auto-dismiss timer while reusing all visual tokens (colours, spacing, typography) from the design system to maintain consistency.

Quick Links
All Tasks Execution Plan