Notifications

Relevant source files

The following files were used as context for generating this wiki page:

• components/NotificationToast.tsx
• contexts/NotificationContext.tsx
• services/supabaseService.ts
• scripts/test-all-modules.js
• REPORTE-EJECUCION-PRUEBAS.md
• utils/logger.ts

The notification system in ElmecV2 is a multi-faceted feature designed to provide users with timely updates through various channels. It supports in-app "toast" notifications, native mobile push notifications via Expo, and standard web notifications. The system is managed globally through a React Context, allowing any component to trigger notifications. Backend persistence is handled by Supabase, enabling a history of notifications for each user.

The core architecture revolves around the NotificationContext, which centralizes state and logic. For the user interface, the NotificationManager is responsible for rendering active in-app notifications, using the NotificationToast component for the visual representation of each message.

Architecture Overview

The notification system is composed of a context provider that wraps the application, a manager component that renders notifications, and a service layer that communicates with the backend.

This diagram illustrates the relationship between the main components of the notification system.

Data Models

In-App Notification Interface

The InAppNotification interface defines the structure for notifications managed within the application's state.

export interface InAppNotification {
  id: string;
  title: string;
  body: string;
  type: 'info' | 'success' | 'warning' | 'error';
  timestamp: string;
  data?: any;
  read: boolean;
}

Sources: contexts/NotificationContext.tsx:23-32

Supabase notifications Table

Notifications are persisted in the notifications table in the Supabase database. The SupabaseService class provides methods to interact with this table.

Column	Type	Description	Constraints
id	uuid	Primary key for the notification.	PK
user_id	uuid	Foreign key to the users table.	FK to users.id
title	text	The title of the notification.
body	text	The main content of the notification.
type	text	The type of notification.	CHECK (request_update, new_message, assignment, reminder, system)
priority	text	The priority level.	medium is used in tests.
data	jsonb	Arbitrary data associated with the notification.
read	boolean	Flag indicating if the user has read the notification.	DEFAULT false
read_at	timestamp	Timestamp when the notification was marked as read.
created_at	timestamp	Timestamp of creation.
updated_at	timestamp	Timestamp of last update.

Sources: services/supabaseService.ts:771-782, REPORTE-EJECUCION-PRUEBAS.md, scripts/test-all-modules.js:553-565

Core Components

NotificationProvider

This is the main context provider that encapsulates the entire notification logic. It should wrap the root of the application.

Responsibilities:

• Manages the state of inAppNotifications.
• Registers and handles listeners for native push notifications (addNotificationReceivedListener).
• Requests permissions for web and native push notifications.
• Exposes functions to send, read, and clear notifications.

Sources: contexts/NotificationContext.tsx:90-269

NotificationManager

A React component that renders the visible in-app toast notifications. It should be placed at the top level of the application's UI tree.

Logic:

1. Subscribes to inAppNotifications from NotificationContext.
2. Filters for unread notifications (!n.read).
3. Takes the last 3 unread notifications to display.
4. Renders a NotificationToast for each visible notification, positioned absolutely at the top of the screen.
5. Handles dismissing notifications, which calls markNotificationAsRead in the context.

// components/NotificationToast.tsx:185-195
useEffect(() => {
    // Show only the last 3 unread notifications
    const unreadNotifications = inAppNotifications
      .filter(n => !n.read)
      .slice(0, 3);

    setVisibleNotifications(unreadNotifications);
}, [inAppNotifications]);

Sources: components/NotificationToast.tsx:182-215

NotificationToast

This component is the visual representation of a single in-app notification toast.

Features:

• Animations: Slides in from the left and fades in on mount. Slides out and fades out on dismiss.
• Auto-Dismiss: Automatically dismisses itself after 5 seconds.
• Styling: The icon, background color, and border color change based on the notification type (success, warning, error, info).
• Manual Dismiss: Users can click an 'X' button to dismiss it immediately.

This diagram shows the styling logic based on the notification type.

Data Flow

Sending a Notification

The following sequence diagram shows the process of sending an in-app notification from a component.

Dismissing a Notification

When a notification is dismissed, either automatically or by the user, it is marked as read.

Backend Services (SupabaseService)

The SupabaseService class provides an abstraction layer for all database interactions related to notifications.

Key Methods

Method	Description	Parameters	Returns
createNotification	Inserts a new notification record into the notifications table.	notificationData: Omit<Notification, 'id' | 'created_at'>	Promise<void>
getNotifications	Fetches all notifications for a specific user, ordered by creation date.	userId: string	Promise<Notification[]>
markNotificationAsRead	Updates a notification's read status to true and sets read_at.	notificationId: string	Promise<void>

Sources: services/supabaseService.ts:771-820

Testing

The notification module is validated through automated backend tests.

• Test Suite: scripts/test-all-modules.js
• Test Report: REPORTE-EJECUCION-PRUEBAS.md

Test Cases

The automated script covers the core backend functionalities:

• TC-NOTIF-001: Successfully creates a test notification of type system.
• TC-NOTIF-002: Verifies that the list of notifications for a user can be retrieved.
• TC-NOTIF-005: Successfully marks a notification as read by updating the read flag.

The test script revealed and led to the correction of several database schema mismatches, such as an invalid notification type ('test' was used instead of 'system') and an attempt to update a non-existent read_at column, which was later corrected in the service.

Sources: scripts/test-all-modules.js:542-602, REPORTE-EJECUCION-PRUEBAS.md