Frontend-Komponenten & Benutzeroberfläche

Wenn eine neue Komponente gebaut wird, sollte sie Stammdaten (Kategorien, Eskalationsstufen, Gebiete) immer über den Hook const { categories } = useData() beziehen und nicht selbst von der API laden. Auch Mutationen (Erstellen, Bearbeiten, Löschen) sollten bevorzugt über die im Context bereitgestellten Funktionen (z.B. createMessageInState) ausgeführt werden. Diese Funktionen rufen die API (client-api.ts) auf, aktualisieren bei Erfolg sofort den lokalen React-State (verhindert Flimmern/Neuladen der Seite), aktualisieren die Zähler-Statistiken im Hintergrund und feuern eine Toast-Benachrichtigung.

Die Listen sind hierarchisch aufgebaut. Eine Haupt-Lage (Parent) enthält ihre direkten Meldungen und aufklappbar ihre Einsatzschwerpunkte (Children), welche wiederum eigene Meldungen haben. Über die dynamischen Filterleisten (Header.tsx) kann die Ansicht nach Status, Typ oder Gebiet eingegrenzt werden. * Die Komponenten laden ihre spezifischen Daten über loadData() und berechnen den Hierarchie-Baum im Frontend (groupedItems mit useMemo). Die Hilfsfunktion hydrateTree() sorgt dafür, dass, wenn das Backend z. B. nur eine gefilterte Meldung zurückgibt, das Frontend automatisch die fehlenden Parent-Situationen nachlädt, damit der visuelle Baum im UI nicht zerbricht.

Auf der großen Karte können Lagen und Feedbacks visuell erfasst werden. Durch Klick auf einen Marker öffnet sich in der rechten Bildschirmhälfte ein Detail-Panel (MapDetails.tsx) mit allen Informationen und direktem Bearbeitungszugriff. Lagen-Marker zeigen farblich die Eskalationsstufe und das Kategorie-Icon. * Die Basiskarte (BaseMap.tsx) nutzt entweder einen konfigurierten WMS-Tile-Server (NEXT_PUBLIC_TILE_SERVER_URL) oder fällt auf Standard-OpenStreetMap zurück. Marker werden in mapUtils.ts dynamisch als HTML (DivIcon) gerendert. Das erlaubt aufwendige CSS-Animationen (Pulsieren bei Selektion) und die Einbettung externer SVGs über die Proxy-Routen. Die Geometrien der Gebiete (Areas) werden als GeoJSON aus der Datenbank gelesen und direkt als Polygon-Layer auf die Karte gelegt.

Bestimmte kritische Aktionen (Freigeben, Archivieren, Löschen) erfordern eine Bestätigung. Es öffnet sich das PIN-Modal (PinModal.tsx). Erst nach Eingabe der korrekten 4 Ziffern wird die Aktion ausgeführt.

Das CardActionsMenu kapselt diese Logik vollständig. Es entscheidet anhand des aktuellen view-Prop (pending, active, archive), welche Buttons gerendert werden. Wird eine kritische Aktion geklickt, wird der actionState gesetzt, das PinModal öffnet sich, und beim Callback handlePinConfirm wird der API-Aufruf mit dem PIN abgesetzt.

Bürger-Rückmeldungen landen in einem Kanban-Board. Spalten repräsentieren den Bearbeitungsstatus (z. B. "Neu", "In Bearbeitung"). Feedbacks können per Drag & Drop von einer Spalte in die andere gezogen werden. Mit Klick auf "Antworten" kann ein Dialog mit dem Bürger gestartet werden.

Die Komponente nutzt die native HTML5 Drag & Drop API (draggable, onDragStart, onDrop). Beim Loslassen (handleDrop) wird die Ziel-Spalten-ID ausgelesen und sofort der API-Call handleStatusChange ausgelöst, um das Backend zu aktualisieren.

In dieser Ansicht lässt sich forensisch nachvollziehen, wer wann was geändert hat. Ein Klick auf einen Eintrag öffnet die Details.

Die Komponente AuditLogCard.tsx berechnet visuelle Diffs. Sie vergleicht oldState und newState des Backends. Geänderte Felder werden farblich hervorgehoben (rot für alt, grün für neu). Besonders wichtig: Das Frontend prüft das Flag isCompromised. Ist dies true (Signatur in der Datenbank fehlerhaft), rendert das UI eine prominente rote Sicherheitswarnung, dass dieser Datensatz potenziell manipuliert wurde.