Implementera optimistiska uppdateringar manuellt

Manuella optimistiska uppdateringar börjar med lokalt komponenttillstånd som initieras med data från servern: const [items, setItems] = useState(serverItems). Det är detta lokala tillstånd som renderas och ändras optimistiskt. Du ska INTE ändra data som hämtats från servern direkt – behåll en lokal kopia som du kontrollerar.

När användaren utlöser en mutation (genom att klicka på "Add", "Like" eller "Delete") ska tillståndet uppdateras omedelbart innan API:et anropas: setItems(prev => [...prev, newItem]). UI:t återspeglar ändringen direkt. Först efter denna uppdatering skickar du det faktiska nätverksanropet.

Innan den optimistiska uppdateringen görs ska det aktuella tillståndet sparas: const previousItems = items. Denna ögonblicksbild är målet för rollback. Om API-anropet misslyckas återställer du detta värde. Lagra det i en variabel, inte i komponenttillståndet, eftersom det bara behövs så länge mutationen väntar på svar.

Efter den optimistiska uppdateringen gör du API-anropet asynkront. Omslut det med try/catch. Vid framgång kan du välja att hämta data igen för att synkronisera med serverns tillstånd, eller lita på det optimistiska tillståndet om servern skulle returnera samma data. Vid fel använder du det sparade tidigare tillståndet för rollback.

I mutationens catch-block: setItems(previousItems). Detta återställer tillståndet till det som gällde före den optimistiska uppdateringen. Följ rollback med en felnotis. Användarna förstår att sällsynta fel inträffar – det de inte accepterar är en tyst inkonsekvens.

Efter återställningen visas ett felmeddelande: "Kunde inte spara ändringarna. Försök igen." tillsammans med en knapp för Försök igen som utlöser samma mutation på nytt. Detta ger användarna kontroll. Kombinationen av rollback, felnotis och nytt försök hanterar fallet på ett smidigt sätt utan att blockera hela UI:t.

När ett nytt objekt läggs till optimistiskt har servern ännu inte tilldelat det ett riktigt ID. Skapa ett tillfälligt ID för det optimistiska objektet: const tempId = crypto.randomUUID(). Använd detta som objektets key i listan. När API:et har svarat framgångsrikt ersätter du det tillfälliga ID:t med det riktiga ID:t som servern tilldelade.

Efter en lyckad skapandemutation svarar servern med det riktiga ID:t. Uppdatera tillståndet genom att ersätta det tillfälliga objektet: setItems(prev => prev.map(item => item.id === tempId ? { ...item, id: serverResponse.id } : item)). Denna synkronisering säkerställer att efterföljande åtgärder använder rätt server-ID.

Om användaren utlöser två mutationer snabbt efter varandra kan svaren komma i fel ordning. Den andra mutationens svar kan komma före den första mutationens svar, och rollback för den första kan skriva över det korrekta tillståndet från den andra. Detta är en race condition som är unik för optimistiskt UI.

En lösning på race conditions är att serialisera mutationer med hjälp av en kö. Medan en mutation pågår inaktiverar du utlösarknappen genom att sätta state-värdet isSubmitting till true. Tillåt nästa mutation först när den föregående är klar. Det ger något sämre responsivitet, men garanterar korrekt ordningsföljd för state-uppdateringarna.

För borttagningsoperationer sparar du först de tidigare objekten, filtrerar bort det raderade objektet från state, anropar delete-API:t och gör en rollback vid fel. Borttagning är enklare än skapande (ingen ID-avstämning behövs), men samma principer gäller. Överväg att lägga in en kort fördröjning före borttagningen, så att du kan visa ett alternativ för att ångra innan API-anropet görs.

Det manuella mönstret är följande: spara previousItems, anropa setItems med det nya state-värdet, gör API-anropet, gör en rollback vid fel med setItems(previousItems) och visa ett felmeddelande. Använd crypto.randomUUID() som tillfälligt ID vid tillägg och ersätt det med serverns ID när anropet lyckas. Förhindra race conditions genom att inaktivera utlösaren medan mutationer pågår. Rollback + toast + nytt försök är standardlösningen för felhantering i användargränssnittet.