Optimistische Aktualisierungen manuell implementieren

Manuelle optimistische Aktualisierungen beginnen mit einem lokalen Komponentenstatus, der mit Serverdaten initialisiert wird: const [items, setItems] = useState(serverItems). Diesen lokalen Status rendern Sie und ändern ihn optimistisch. Sie sollten NICHT direkt an vom Server abgerufenen Daten arbeiten – behalten Sie stattdessen eine lokale Kopie, die Sie kontrollieren.

Wenn der Benutzer eine Mutation auslöst (durch Klicken auf „Hinzufügen“, „Gefällt mir“ oder „Löschen“), aktualisieren Sie den Status sofort, bevor Sie die API aufrufen: setItems(prev => [...prev, newItem]). Die Benutzeroberfläche spiegelt die Änderung sofort wider. Erst danach senden Sie die eigentliche Netzwerkanfrage.

Erfassen Sie vor der optimistischen Aktualisierung den aktuellen Status: const previousItems = items. Dieser Snapshot ist Ihr Rollback-Ziel. Wenn der API-Aufruf fehlschlägt, stellen Sie diesen Wert wieder her. Speichern Sie ihn in einer Variablen und nicht im Status, da Sie ihn nur für die Dauer der ausstehenden Mutation benötigen.

Führen Sie nach der optimistischen Aktualisierung den API-Aufruf asynchron aus. Umschließen Sie ihn mit try/catch. Bei Erfolg können Sie optional die Daten erneut abrufen, um sie mit dem Serverstatus abzugleichen, oder dem optimistischen Status vertrauen, wenn der Server dieselben Daten zurückgeben würde. Bei einem Fehler verwenden Sie den erfassten vorherigen Status für den Rollback.

Rufen Sie im catch-Block Ihrer Mutation Folgendes auf: setItems(previousItems). Dadurch wird der Status auf den Zustand vor der optimistischen Aktualisierung zurückgesetzt. Zeigen Sie anschließend eine Fehlermeldung an. Benutzer verstehen, dass seltene Fehler vorkommen – was sie nicht akzeptieren können, ist eine unbemerkte Inkonsistenz.

Zeigen Sie nach dem Rollback eine Fehlermeldung an: „Die Änderungen konnten nicht gespeichert werden. Bitte versuchen Sie es erneut.“ Fügen Sie eine Schaltfläche „Erneut versuchen“ hinzu, die dieselbe Mutation erneut ausführt. Dadurch behalten die Benutzer die Kontrolle. Die Kombination aus Rollback, Fehler-Toast und erneuter Ausführung behandelt den Fehlerfall angemessen, ohne die gesamte Benutzeroberfläche zu blockieren.

Beim optimistischen Hinzufügen eines neuen Elements hat der Server noch keine echte ID vergeben. Erstellen Sie für das optimistische Element eine temporäre ID: const tempId = crypto.randomUUID(). Verwenden Sie diese als Schlüssel des Elements in der Liste. Nach einer erfolgreichen Antwort der API ersetzen Sie die temporäre ID durch die vom Server vergebene echte ID.

Nach einer erfolgreichen Mutation zum Erstellen eines Elements antwortet der Server mit der echten ID. Aktualisieren Sie Ihren Status, um das temporäre Element zu ersetzen: setItems(prev => prev.map(item => item.id === tempId ? { ...item, id: serverResponse.id } : item)). Dieser Abgleich stellt sicher, dass nachfolgende Vorgänge die korrekte Server-ID verwenden.

Wenn der Benutzer zwei Mutationen in kurzer Folge auslöst, können die Antworten in einer anderen Reihenfolge eintreffen. Die Antwort der zweiten Mutation kann vor der ersten eintreffen, und der Rollback der ersten Mutation könnte den korrekten Status der zweiten Mutation überschreiben. Dies ist eine Race Condition, die speziell bei Optimistic UI auftreten kann.

Eine Lösung für Race Conditions: Serialisieren Sie Mutationen mithilfe einer Warteschlange. Deaktivieren Sie die Auslöseschaltfläche, solange eine Mutation läuft (indem Sie den Zustand isSubmitting auf true setzen). Lassen Sie die nächste Mutation erst zu, wenn die vorherige abgeschlossen ist. Dadurch wird die Reaktionsfähigkeit etwas eingeschränkt, aber die korrekte Reihenfolge der Zustandsänderungen garantiert.

Für Löschvorgänge: Speichern Sie die vorherigen Elemente, entfernen Sie das gelöschte Element aus dem Zustand, rufen Sie die Delete-API auf und stellen Sie den vorherigen Zustand bei einem Fehler wieder her. Das Löschen ist einfacher als das Erstellen (es ist keine ID-Zuordnung erforderlich), aber dieselben Prinzipien gelten. Erwägen Sie, vor dem API-Aufruf eine kurze Verzögerung einzubauen und dabei eine Option zum "Rückgängig machen" anzuzeigen.

Warum benötigen optimistisch hinzugefügte Elemente eine temporäre ID?

Das manuelle Muster: Erfassen Sie previousItems, setzen Sie mit setItems den neuen Zustand, führen Sie den API-Aufruf aus, stellen Sie bei einem Fehler mit setItems(previousItems) den vorherigen Zustand wieder her und zeigen Sie einen Fehler an. Verwenden Sie für neue Elemente crypto.randomUUID() als temporäre ID und gleichen Sie sie bei Erfolg mit der Server-ID ab. Verhindern Sie Race Conditions, indem Sie die Auslöseaktion während laufender Mutationen deaktivieren. Rollback + Toast + Wiederholen ist das Standardverhalten der Benutzeroberfläche bei Fehlern.