Redux state structure, reducers, and state flow diagram for notification management

Redux State

State Structure

The Redux store maintains the complete notification system state through a centralized store:

interface NotificationState {
  // Loading & UI State
  loader: boolean; // Loading indicator for API calls
  pushNotificationData: JsonObject | null; // Current push notification being displayed
  error: string | null; // Error message from last operation

  // Notification Data
  notificationList: JsonObject[]; // All fetched notifications
  notificationTypeMaster: JsonObject[]; // All available notification types
  userNotificationPreferences: JsonObject[]; // User's notification preferences
  orgNotificationList: JsonObject[]; // Organization-level notifications

  // Metadata
  unreadNotificationCount: number; // Total unread notification count
  orgNotificationLimitReached: boolean; // Pagination limit reached
  fcmToken: string | null; // Current FCM token

  // Filters & Pagination
  currentFilters: {
    status: "all" | "read" | "unread";
    dateRange: number | null;
    searchText: string;
  };
  currentPage: number;
  pageSize: number;
}

State Diagram

Reducer Implementation

File: src/store/reducers/notificationReducer.ts

GitHub: View on GitHub

The reducer handles all notification-related state mutations:

Key Features:

Manages loading states (START_LOADING, STOP_LOADING)
Handles notification fetching and updates
Updates unread count tracking
Manages FCM token storage
Handles filter and pagination state
Provides error state management
Supports bulk notification updates

Key Features:

Base state selector
Notification list selectors (read, unread, filtered)
Count selectors (unread, total)
Type selectors (by ID)
FCM token selectors
Loading and error selectors
Filter and pagination selectors
Push notification data selector
Complex filtering logic with date range and search

State Flow Example

Fetching Notifications

Marking as Read

Receiving Push Notification

State Normalization Best Practices

What We're Currently Doing (Denormalized)

// Current approach - simpler but less scalable
notificationList: [
  {
    id: 1,
    notification_type_id: 1,
    message: { title: "...", body: "..." },
    created_at: 1234567890,
    read_on: null,
  },
];

Recommended for Large-Scale (Normalized)

// Normalized approach - better for large datasets
state: {
  notifications: {
    byId: {
      '1': { id: 1, type_id: 1, message_id: 10, created_at: 1234567890, read_on: null },
      '2': { id: 2, type_id: 2, message_id: 11, created_at: 1234567891, read_on: null }
    },
    allIds: ['1', '2']
  },
  messages: {
    byId: {
      '10': { title: '...', body: '...' },
      '11': { title: '...', body: '...' }
    }
  }
}


### Cleanup on Logout

```typescript
case NOTIFICATION_ACTIONS.RESET_NOTIFICATION_STATE:
  return initialState;  // Clear all data

Performance Considerations

Scenario	Impact	Solution
Large notification lists (1000+)	Slow rendering	Use pagination + virtualization
Frequent updates	Re-renders	Use memoized selectors
Deep object comparisons	Slow	Normalize state structure
Missing error states	Poor UX	Add error handling in reducer
Unhandled edge cases	Bugs	Add comprehensive action handlers

Next Steps: Continue to Redux Actions to understand action creators and dispatchers.

Redux State

On this page