# Communications Frontend Integration

## Purpose

Parent communication, internal alerts, and dashboard upcoming events follow the frontend three-layer architecture.

```text
View -> Business Logic -> API/Data Access -> Backend
```

## Files

View layer:

- `frontend/src/components/parent-communication/ParentCommunicationModule.tsx`
- `frontend/src/components/internal-alerts/InternalAlertsModule.tsx`
- `frontend/src/components/safety-protocols/SafetyProtocolsModule.tsx`
- `frontend/src/components/frameworks/MoreModules.tsx` as a module export hub
- `frontend/src/components/frameworks/Dashboard.tsx`
- `frontend/src/components/dashboard/DashboardUpcomingEvents.tsx`

Business logic layer:

- `frontend/src/business/communications/hooks.ts`
- `frontend/src/business/communications/selectors.ts`
- `frontend/src/business/dashboard/hooks.ts`

API/data access layer:

- `frontend/src/shared/api/communications.ts`
- `frontend/src/shared/types/communications.ts`
- `frontend/src/shared/constants/communications.ts`

## Behavior

- Parent message logs load from `GET /api/communications/parent-messages`.
- Parent messages save through `POST /api/communications/parent-messages`.
- Internal alerts load from `GET /api/communications/events`.
- Director/superintendent users create alerts through `POST /api/communications/events`.
- Dashboard upcoming events read the same backend event data as the internal alerts module through `useDashboardPage`.
- Safety protocols are loaded through the content catalog backend contract and rendered in a focused view module.
- Approved parent templates and event display constants live in shared constants.
- Parent communication, internal alerts, and safety protocols use shared UI primitives for buttons, form controls, and status panels.

## Remaining Related Work

Alert acknowledgments are still local UI state. Add a backend acknowledgment table when acknowledgments must survive reloads or feed compliance reporting.