Mercure in React: ein EventSource-Hook
Mercure in React: ein EventSource-Hook
~16 Min. Lesezeit Zuletzt aktualisiert am 8. August 2026
Kapitel 69 testete Mercure-Abonnements MANUELL im Browser – dieses Kapitel kapselt DAS in einen wiederverwendbaren React-Hook, der TanStack Query GEZIELT über Änderungen INFORMIERT.
Den useMercure-Hook schreiben
import { useEffect } from 'react';
import { useQueryClient } from '@tanstack/react-query';
const MERCURE_URL = 'https://localhost/.well-known/mercure';
export function useMercure(topic: string, queryKey: unknown[]) {
const queryClient = useQueryClient();
useEffect(() => {
const url = new URL(MERCURE_URL);
url.searchParams.append('topic', topic);
const eventSource = new EventSource(url, { withCredentials: true });
eventSource.onmessage = () => {
queryClient.invalidateQueries({ queryKey });
};
return () => {
eventSource.close();
};
}, [topic, queryClient, queryKey]);
}STATT die Update-Nachricht SELBST zu parsen und in den Cache zu SCHREIBEN, nutzt DIESER Hook invalidateQueries() aus Kapitel 78 – EINFACHER und WENIGER fehleranfällig, da der ANSCHLIESSENDE Refetch IMMER den GARANTIERT aktuellen, autorisierten Zustand vom Server holt.
Achtung: withCredentials: true ist NOTWENDIG, damit EventSource das mercureAuthorization-Cookie aus Kapitel 70 MITSCHICKT – OHNE diese Option würde der Browser das Cookie bei einer Cross-Origin-Anfrage NICHT automatisch anhängen.
Die Cleanup-Funktion verstehen
return () => { eventSource.close(); } ist ENTSCHEIDEND: OHNE diese Cleanup-Funktion würde JEDE Neu-Montage der Komponente (z. B. beim Navigieren weg und wieder zurück) eine ZUSÄTZLICHE, NIE geschlossene Verbindung öffnen – EIN klassisches React-Speicherleck, das useEffects Cleanup-Mechanismus GENAU für DIESEN Fall vorsieht.
Den Hook in der Projektliste nutzen
// ProjectListPage.tsx - Ergänzung
import { useMercure } from '../hooks/useMercure';
function ProjectListPage() {
useMercure('https://localhost/api/projects/{id}', ['projects']);
const { data, isPending, isError, error } = useProjects();
// ...
}Das WILDCARD-Topic aus Kapitel 69 ({id} statt einer konkreten ID) sorgt dafür, dass ÄNDERUNGEN an JEDEM Projekt den ['projects']-Cache-Eintrag INVALIDIEREN – ändert ein ANDERER Nutzer EIN Projekt, aktualisiert sich die Liste BEI UNS AUTOMATISCH, OHNE Neuladen der Seite.
Das vollständige Verhalten testen
- Die Projektliste in ZWEI Browser-Tabs (oder zwei verschiedenen Nutzern) öffnen.
- In Tab 1 ein Projekt bearbeiten (
PATCH, GENAU wie in Kapitel 53). - Tab 2 aktualisiert sich SOFORT, OHNE dass DORT irgendetwas geklickt wurde.
Tipp: DIESER Hook ist das FRONTEND-Gegenstück zu ALLEM, was seit Kapitel 67 im Backend aufgebaut wurde – EIN GUTER Moment, um die Kette VON mercure: true (Kapitel 68) BIS zu diesem useEffect NOCHMALS GEDANKLICH nachzuvollziehen, BEVOR es mit der VOLLSTÄNDIGEN CRUD-UI in Block 10 weitergeht.