Manuel implementering af optimistiske opdateringer

Manuelle optimistiske opdateringer begynder med lokal komponenttilstand, der initialiseres fra data fra serveren: const [items, setItems] = useState(serverItems). Det er denne lokale tilstand, du viser, og som du ændrer optimistisk. Du må IKKE ændre data, der er hentet fra serveren, direkte – behold en lokal kopi, som du selv styrer.

Når brugeren udløser en ændring (ved at trykke på "Tilføj", "Synes godt om" eller "Slet"), skal du udføre tilstandsopdateringen med det samme, før du kalder API'et: setItems(prev => [...prev, newItem]). Brugerfladen afspejler ændringen øjeblikkeligt. Først efter denne opdatering sender du den faktiske netværksanmodning.

Før du foretager den optimistiske opdatering, skal du gemme den aktuelle tilstand: const previousItems = items. Dette øjebliksbillede er dit mål for tilbagerulningen. Hvis API-kaldet mislykkes, gendanner du denne værdi. Gem den i en variabel (ikke i tilstanden), fordi du kun har brug for den, mens den afventende ændring behandles.

Efter den optimistiske opdatering skal du foretage API-kaldet asynkront. Pak det ind i try/catch. Hvis det lykkes, kan du valgfrit hente data igen for at synkronisere med serverens tilstand, eller stole på den optimistiske tilstand, hvis serveren ville returnere de samme data. Hvis det mislykkes, skal du bruge den gemte tidligere tilstand til tilbagerulning.

I catch-blokken for din ændring skal du skrive: setItems(previousItems). Det gendanner tilstanden til det, den var, før den optimistiske opdatering blev foretaget. Følg tilbagerulningen op med en fejlmeddelelse. Brugerne forstår, at sjældne fejl forekommer – men de kan ikke acceptere en uopdaget uoverensstemmelse.

Efter tilbagerulningen skal du vise en fejlmeddelelse: "Kunne ikke gemme ændringerne. Prøv igen." med en Prøv igen-knap, der udløser den samme ændring igen. Det giver brugerne mulighed for selv at handle. Kombinationen af tilbagerulning, fejl-toast og mulighed for at prøve igen håndterer fejlsituationen på en god måde uden at blokere hele brugerfladen.

Når du optimistisk tilføjer et nyt element, har serveren endnu ikke tildelt det et rigtigt id. Opret et midlertidigt id til det optimistiske element: const tempId = crypto.randomUUID(). Brug det som elementets nøgle på listen. Når API'et svarer med succes, skal du erstatte det midlertidige id med det rigtige id, som serveren har tildelt.

Efter en vellykket oprettelse svarer serveren med det rigtige id. Opdatér tilstanden, så det midlertidige element erstattes: setItems(prev => prev.map(item => item.id === tempId ? { ...item, id: serverResponse.id } : item)). Denne afstemning sikrer, at efterfølgende handlinger bruger det korrekte id fra serveren.

Hvis brugeren udløser to ændringer hurtigt efter hinanden, kan svarene komme i forkert rækkefølge. Svaret på den anden ændring kan komme før svaret på den første, og tilbagerulningen af den første kan overskrive den korrekte tilstand fra den anden. Dette er et kapløbsproblem, der er særligt for optimistisk UI.

Én løsning på kapløbstilstande er at serialisere mutationer ved hjælp af en kø. Mens en mutation er under behandling, deaktiverer du udløserknappen (ved at sætte tilstanden isSubmitting til true). Tillad kun den næste mutation, når den forrige er færdig. Det gør løsningen mindre responsiv, men garanterer korrekt rækkefølge for tilstandsændringerne.

Ved slettehandlinger: gem de tidligere elementer, filtrer det slettede element fra tilstanden, kald slette-API'et, og gendan tilstanden ved fejl. Sletning er enklere end oprettelse (ingen ID-afstemning), men de samme principper gælder. Overvej at tilføje en kort forsinkelse før sletningen (så der vises en "fortryd"-mulighed), inden API-kaldet foretages.

Det manuelle mønster: Gem previousItems, sæt den nye tilstand med setItems, foretag API-kaldet, rull tilbage ved fejl med setItems(previousItems), og vis en fejlmeddelelse. Ved tilføjelser skal du bruge crypto.randomUUID() som et midlertidigt ID og afstemme det med serverens ID ved succes. Forebyg kapløbstilstande ved at deaktivere udløseren, mens mutationer er under behandling. Tilbageføring, besked og gentagelse er den almindelige brugeroplevelse ved fejl.