Optimistische UI‑updates in React kunnen apps direct laten aanvoelen. Leer veilige patronen om met server‑waarheid te reconciliëren, fouten te behandelen en datadrift te voorkomen.
Optimistische UI in React betekent dat je het scherm bijwerkt alsof een wijziging al gelukt is, voordat de server het bevestigt. Iemand klikt op Like, het aantal stijgt meteen en de aanvraag draait op de achtergrond.
Die directe feedback doet een app sneller aanvoelen. Bij een langzaam netwerk is het vaak het verschil tussen “snappy” en “is het gelukt?”
Het nadeel is datadrift: wat de gebruiker ziet kan langzaam ophouden te kloppen met wat de server als waarheid heeft. Drift verschijnt meestal als kleine, frustrerende inconsistenties die afhangen van timing en moeilijk te reproduceren zijn.
Gebruikers merken drift vaak wanneer dingen later “van gedachten veranderen”: een teller springt en klapt terug, een item verschijnt en verdwijnt na refresh, een wijziging lijkt te blijven totdat je de pagina opnieuw bezoekt, of twee tabs tonen verschillende waarden.
Dit gebeurt omdat de UI een gok maakt en de server misschien een andere waarheid terugstuurt. Validatieregels, deduplicatie, permissiechecks, rate limits of een ander apparaat dat hetzelfde record verandert kunnen het eindresultaat bijstellen. Een andere veelvoorkomende oorzaak is overlappende requests: een oudere response arriveert als laatste en overschrijft de nieuwere actie van de gebruiker.
Voorbeeld: je hernoemt een project naar “Q1 Plan” en toont het meteen in de header. De server trimt whitespace, keurt bepaalde tekens af of genereert een slug. Als je de optimistische waarde nooit vervangt door de uiteindelijke serverwaarde, ziet de UI er correct uit totdat je ververst en het zich “mysterieus” verandert.
Optimistische UI is niet altijd de juiste keuze. Wees voorzichtig (of vermijd het) voor geldzaken en facturatie, onomkeerbare acties, rol‑ en permissiewijzigingen, workflows met complexe serverregels of alles met side‑effects die de gebruiker expliciet moet bevestigen.
Goed gebruikt maakt optimistische updates een app direct voelbaar, maar alleen als je rekening houdt met reconciliatie, volgorde en foutenafhandeling.
Optimistische UI werkt het beste wanneer je twee soorten state onderscheidt:
De meeste drift ontstaat wanneer een lokale gok als bevestigd wordt behandeld.
Een eenvoudige regel: als een waarde zakelijke betekenis heeft buiten het huidige scherm, is de server de bron van waarheid. Als het alleen beïnvloedt hoe het scherm zich gedraagt (open of gesloten, gefocuste input, concepttekst), houd het lokaal.
In de praktijk: bewaar server‑waarheid voor zaken als permissies, prijzen, saldi, voorraad, berekende of gevalideerde velden en alles dat elders kan veranderen (een andere tab, een andere gebruiker). Houd lokale UI‑state voor concepten, “is editing” flags, tijdelijke filters, uitgeklapte rijen en animatietoggles.
Sommige acties zijn “veilig om te raden” omdat de server ze bijna altijd accepteert en ze makkelijk om te keren zijn, zoals een item sterren of een eenvoudige voorkeur togglen.
Wanneer een veld niet veilig is om te raden, kun je de app nog steeds snel laten aanvoelen zonder te doen alsof de wijziging definitief is. Bewaar de laatst bevestigde waarde en voeg een duidelijke pending‑indicator toe.
Bijvoorbeeld: op een CRM‑scherm waar je op “Mark as paid” klikt, kan de server dit afwijzen (permissions, validatie, al terugbetaald). In plaats van meteen alle afgeleide getallen te herschrijven, update je de status met een subtiel “Saving…”, laat totals onaangeroerd en update totals pas na bevestiging.
Goede patronen zijn simpel en consistent: een klein “Saving…”‑badge bij het gewijzigde item, de actie tijdelijk uitschakelen (of veranderen in Undo) totdat de request settled is, of de optimistische waarde visueel als tijdelijk markeren (lichtere tekst of een klein spinner‑icoon).
Als de serverrespons veel plekken kan beïnvloeden (totalen, sortering, berekende velden, permissies), is refetchen meestal veiliger dan proberen alles lokaal te patchen. Als het een kleine, geïsoleerde wijziging is (hernoemen van een notitie, togglen van een vlag), is lokaal patchen vaak prima.
Een nuttige regel: patch het ene ding dat de gebruiker veranderde, en refetch daarna data die afgeleid, geaggregeerd of gedeeld wordt over schermen.
Optimistische UI werkt als je datamodel bijhoudt wat bevestigd is versus wat nog een gok is. Als je die kloof expliciet modelleert, worden momenten van “waarom veranderde dit terug?” zeldzaam.
Voor nieuw aangemaakte items, wijs een tijdelijke client‑ID toe (zoals temp_12345 of een UUID), en verwissel die voor de echte server‑ID wanneer de response arriveert. Dat laat lijsten, selectie en bewerkstaat netjes reconciliëren.
Voorbeeld: een gebruiker voegt een taak toe. Je rendert deze meteen met id: "temp_a1". Wanneer de server id: 981 terugstuurt, vervang je de ID op één plek en alles wat op ID keyed is blijft werken.
Een enkele scherm‑loading‑flag is te grof. Track de status op het item (of zelfs het veld) dat verandert. Zo kun je subtiele pending UI tonen, alleen het gefaalde item retryen en voorkomen dat je ongewenst andere acties blokkeert.
Een praktisch item‑shape:
id: echt of tijdelijkstatus: pending | confirmed | failedoptimisticPatch: wat je lokaal veranderde (klein en specifiek)serverValue: laatst bevestigde data (of een confirmedAt timestamp)rollbackSnapshot: de vorige bevestigde waarde die je kunt herstellenOptimistische updates zijn het veiligst wanneer je alleen raakt wat de gebruiker daadwerkelijk veranderde (bijv. togglen van completed) in plaats van het hele object te vervangen met een geraad “nieuw versie”. Het vervangen van het hele object maakt het makkelijk om nieuwere bewerkingen, door de server toegevoegde velden of gelijktijdige veranderingen te overschrijven.
Een goede optimistische update voelt meteen, maar komt uiteindelijk overeen met wat de server zegt. Behandel de optimistische wijziging als tijdelijk en houd genoeg boekhouding bij om deze veilig te bevestigen of ongedaan te maken.
Voorbeeld: een gebruiker bewerkt een taaknaam in een lijst. Je wilt dat de titel direct verandert, maar je moet ook omgaan met validatiefouten en serverzijdige formatting.
Pas de optimistische wijziging direct toe in lokale state. Bewaar een kleine patch (of snapshot) zodat je kunt terugdraaien.
Stuur de request met een request‑ID (een oplopend nummer of een random ID). Daarmee koppel je responses aan de actie die ze veroorzaakte.
Markeer het item als pending. Pending hoeft de UI niet te blokkeren. Het kan een kleine spinner zijn, vervaagde tekst of “Saving…”. Het belangrijkste is dat de gebruiker begrijpt dat het nog niet bevestigd is.
Bij succes, vervang tijdelijke client‑data door de serverversie. Als de server iets aanpaste (whitespace trimpte, casing veranderde, timestamps bijwerkte), werk je de lokale state bij zodat die overeenkomt.
Bij fout, rol alleen terug wat deze specifieke request veranderde en toon een duidelijke lokale fout. Vermijd het terugdraaien van ongerelateerde delen van het scherm.
Hier is een klein shape dat je kunt volgen (library‑agnostisch):
const requestId = crypto.randomUUID();
applyOptimistic({ id, title: nextTitle, pending: requestId });
try {
const serverItem = await api.updateTask({ id, title: nextTitle, requestId });
confirmSuccess({ id, requestId, serverItem });
} catch (err) {
rollback({ id, requestId });
showError("Could not save. Your change was undone.");
}
Twee details voorkomen veel bugs: sla de request‑ID op het item op terwijl het pending is en bevestig of rol alleen terug als de ID’s overeenkomen. Dat voorkomt dat oudere responses nieuwere bewerkingen overschrijven.
Optimistische UI faalt als het netwerk antwoorden in verkeerde volgorde terugstuurt. Een klassiek probleem: de gebruiker bewerkt een titel, bewerkt hem meteen opnieuw en de eerste request komt als laatste terug. Als je die late response toepast, zet de UI terug naar een oudere waarde.
De oplossing is om elke response als “misschien relevant” te behandelen en deze alleen toe te passen als hij overeenkomt met de meest recente intentie van de gebruiker.
Een praktisch patroon is een client request‑ID (een teller) die je aan elke optimistische wijziging koppelt. Sla de laatste ID per record op. Wanneer een response binnenkomt, vergelijk de ID’s. Als de response ouder is dan de laatste, negeer je hem.
Version checks helpen ook. Als je server updatedAt, version of een etag terugstuurt, accepteer dan alleen responses die nieuwer zijn dan wat de UI al toont.
Andere opties die je kunt combineren:
Voorbeeld (request‑ID guard):
let nextId = 1;
const latestByItem = new Map();
async function saveTitle(itemId, title) {
const requestId = nextId++;
latestByItem.set(itemId, requestId);
// optimistic update
setItems(prev => prev.map(i => i.id === itemId ? { ...i, title } : i));
const res = await api.updateItem(itemId, { title, requestId });
// ignore stale response
if (latestByItem.get(itemId) !== requestId) return;
// reconcile with server truth
setItems(prev => prev.map(i => i.id === itemId ? { ...i, ...res.item } : i));
}
Als gebruikers snel typen (notities, titels, zoeken), overweeg dan saves te annuleren of uit te stellen tot ze even pauzeren. Dat vermindert serverbelasting en verkleint de kans dat late responses zichtbare snaps veroorzaken.
Fouten zijn waar optimistische UI vertrouwen kan verliezen. De slechtste ervaring is een plotselinge rollback zonder uitleg.
Een goed uitgangspunt voor bewerkingen is: houd de waarde van de gebruiker op het scherm, markeer deze als niet opgeslagen en toon een inline‑fout precies waar ze bewerkten. Als iemand een project hernoemt van “Alpha” naar “Q1 Launch”, zet je het niet terug naar “Alpha” tenzij het echt moet. Laat “Q1 Launch” staan, voeg “Niet opgeslagen. Naam al in gebruik” toe en laat ze het aanpassen.
Inline feedback blijft gekoppeld aan het exacte veld of de rij die faalde. Het voorkomt het “wat gebeurde er net?”‑moment waarbij er een toast zichtbaar is maar de UI stilletjes terugschakelt.
Betrouwbare signalen zijn “Saving…” tijdens in‑flight, “Niet opgeslagen” bij falen, een subtiele highlight op de getroffen rij en een korte boodschap met wat de gebruiker nu kan doen.
Retry is bijna altijd behulpzaam. Undo is vooral nuttig voor snelle acties die iemand kan betreuren (zoals archiveren), maar kan verwarrend zijn voor bewerkingen waarbij de gebruiker duidelijk de nieuwe waarde wil.
Wanneer een mutatie faalt:
Als je echt moet terugdraaien (bijvoorbeeld vanwege veranderde permissies), leg het uit en herstel de server‑waarheid: “Kon niet opslaan. Je hebt geen toegang meer om dit te bewerken.”
Behandel de serverresponse als het ontvangstbewijs, niet alleen als een succes‑flag. Nadat de request klaar is, reconciliëer: behoud wat de gebruiker bedoelde en accepteer wat de server beter weet.
Een volledige refetch is het veiligst wanneer de server mogelijk meer heeft veranderd dan jouw lokale gok. Het is ook makkelijker om over na te denken.
Refetchen is meestal de betere keuze wanneer de mutatie veel records raakt (items verplaatsen tussen lijsten), wanneer permissies of workflowregels het resultaat kunnen veranderen, wanneer de server gedeeltelijke data teruggeeft of wanneer andere clients vaak dezelfde view updaten.
Als de server het bijgewerkte object (of genoeg velden) terugstuurt, kan mergen een betere ervaring zijn: de UI blijft stabiel terwijl je toch server‑waarheid accepteert.
Drift ontstaat vaak door server‑eigendom velden te overschrijven met een optimistisch object. Denk aan tellers, berekende waarden, timestamps en genormaliseerde formatting.
Voorbeeld: je zet optimistisch likedByMe=true en verhoogt likeCount. De server kan dubbele likes dedupliceren en een andere likeCount teruggeven, plus een vernieuwde updatedAt.
Een eenvoudige merge‑aanpak:
Bepaal van tevoren wat te doen bij een conflict. “Last write wins” is prima voor toggles. Field‑level merge is beter voor formulieren.
Het bijhouden van een per‑veld “dirty since request”‑vlag (of een lokaal versienummer) laat je serverwaarden negeren voor velden die de gebruiker na de mutatie begon aanpaste, terwijl je server‑waarheid voor de rest accepteert.
Als de server de mutatie afwijst, geef dan bij voorkeur specifieke, lichte fouten in plaats van een verrassende rollback. Houd de input van de gebruiker vast, highlight het veld en toon het bericht. Rollbacks voor opslaan zijn voorbehouden aan gevallen waarin de actie echt niet kan blijven (bijv. je verwijderde optimistisch een item dat de server weigerde te verwijderen).
Lijsten zijn het gebied waar optimistische UI geweldig voelt en snel breekt. Eén item dat verandert kan ordering, totalen, filters en meerdere pagina’s raken.
Voor creates: toon het nieuwe item direct maar markeer het als pending met een tijdelijke ID. Houd zijn positie stabiel zodat het niet heen en weer springt.
Voor deletes is een veilig patroon het item meteen verbergen maar een kortstondig “ghost” record in geheugen houden totdat de server bevestigt. Dat ondersteunt undo en maakt fouten makkelijker te behandelen.
Herschikken (reordering) is lastig omdat het veel items raakt. Als je optimistisch herschikt, sla dan de vorige volgorde op zodat je die kunt herstellen als het misgaat.
Met paginatie of infinite scroll: bepaal waar optimistische inserts horen. In feeds gaan nieuwe items meestal bovenaan. In server‑gerankte catalogi kan lokale insertion misleiden omdat de server het item ergens anders plaatst. Een praktisch compromis is in te voegen in de zichtbare lijst met een pending‑badge en klaar te zijn om het te verplaatsen als de server een ander sorteer‑key teruggeeft.
Wanneer een tijdelijke ID een echte ID wordt, dedupe op een stabiele key. Als je alleen op ID matcht, kun je hetzelfde item dubbel tonen (temp en bevestigd). Houd een tempId‑naar‑realId mapping en vervang in‑place zodat scrollpositie en selectie niet resetten.
Counts en filters zijn ook lijststate. Update counts optimistisch alleen wanneer je er zeker van bent dat de server het eens zal zijn. Anders markeer ze als refreshing en reconcile na de response.
De meeste optimistische update‑bugs gaan niet echt over React. Ze komen voort uit het behandelen van een optimistische wijziging als “de nieuwe waarheid” in plaats van een tijdelijke gok.
Optimistisch een heel object of scherm updaten terwijl slechts één veld veranderde vergroot het blast radius. Latere servercorrecties kunnen ongerelateerde bewerkingen overschrijven.
Voorbeeld: een profielformulier vervangt het hele user‑object wanneer je een instelling togglet. Terwijl de request in‑flight is, bewerkt de gebruiker zijn naam. Wanneer de response arriveert, kan je vervanging de oude naam terugzetten.
Houd optimistische patches klein en gefocused.
Een andere bron van drift is vergeten pending‑flags te wissen na succes of fout. De UI blijft half‑laden en latere logica behandelt het misschien nog steeds als optimistisch.
Als je pending state per item trackt, wis het dan met dezelfde sleutel die je gebruikte om het te zetten. Tijdelijke IDs veroorzaken vaak “ghost pending” items wanneer de echte ID niet overal gemapt is.
Rollback‑bugs gebeuren wanneer de snapshot te laat of te breed is opgeslagen.
Als een gebruiker twee snelle bewerkingen doet, kun je per ongeluk bewerking #2 terugdraaien met de snapshot van vóór bewerking #1. De UI springt naar een staat die de gebruiker nooit zag.
Oplossing: snapshot het exacte deel dat je wilt herstellen en scope het naar een specifieke mutatiepoging (vaak met de request‑ID).
Echte saves bestaan vaak uit meerdere stappen. Als stap 2 faalt (bijv. image upload), rol stap 1 dan niet stilletjes terug. Toon wat geslaagd is, wat niet, en wat de gebruiker nu kan doen.
Neem ook niet aan dat de server exact echoot wat je stuurde. Servers normaliseren tekst, passen permissies toe, zetten timestamps, wijzen IDs toe en droppen velden. Reconcile altijd vanuit de response (of refetch) in plaats van blind op de optimistische patch te vertrouwen.
Optimistische UI werkt wanneer het voorspelbaar is. Behandel elke optimistische wijziging als een mini‑transactie: hij heeft een ID, een zichtbare pending‑staat, een duidelijke success‑swap en een foutpad dat mensen niet verrast.
Checklist om te controleren vóór release:
Als je snel prototypeert, hou de eerste versie klein: één scherm, één mutatie, één lijstupdate. Tools zoals Koder.ai (koder.ai) kunnen je helpen de UI en API sneller te schetsen, maar dezelfde regel geldt: model pending vs confirmed state zodat de client nooit uit het oog verliest wat de server daadwerkelijk accepteerde.
Optimistische UI werkt door het scherm direct bij te werken voordat de server de wijziging bevestigt. Het laat de app sneller aanvoelen, maar je moet nog steeds reconciliëren met de serverrespons zodat de UI niet van de werkelijke opgeslagen staat afdrijft.
Datadrift ontstaat wanneer de UI een optimistische gok als bevestigd blijft tonen, terwijl de server iets anders opslaat of de wijziging afwijst. Het verschijnt vaak na een refresh, in een andere tab of wanneer trage netwerken ervoor zorgen dat responses in vreemde volgorde aankomen.
Wees voorzichtig met optimistische updates voor geldzaken, facturatie, onomkeerbare acties, permissiewijzigingen en workflows met strikte serverregels. Voor dit soort dingen is het veiliger een duidelijke pending‑staat te tonen en te wachten op bevestiging voordat je zaken verandert die totalen of toegang beïnvloeden.
Beschouw de backend als bron van waarheid voor alles wat buiten het huidige scherm business‑betekenis heeft, zoals prijzen, permissies, berekende velden en gedeelde tellers. Houd lokale UI‑state voor concepten, focus, “is editing”, filters en andere presentatiedingen.
Toon een klein, consistent teken precies waar de wijziging plaatsvond, zoals “Saving…”, vervaagde tekst of een subtiele spinner. Het doel is duidelijk te maken dat de waarde tijdelijk is zonder de hele pagina te blokkeren.
Gebruik een tijdelijke client‑ID (zoals een UUID of temp_...) bij het aanmaken van het item en vervang die door de echte server‑ID bij succes. Dat houdt keys, selectie en bewerkstaat stabiel zodat het item niet flikkert of dubbel verschijnt.
Gebruik geen globale laadflag; track pending state per item (of per veld) zodat alleen het gewijzigde onderdeel als pending wordt getoond. Sla een kleine optimistische patch en een rollback‑snapshot op zodat je precies die wijziging kunt bevestigen of terugdraaien zonder andere UI te beïnvloeden.
Voorzie elke mutatie van een request‑ID en sla de laatste request‑ID per item op. Wanneer een response binnenkomt, pas deze alleen toe als de ID overeenkomt met de nieuwste request‑ID; negeer oudere responses zodat late antwoorden de UI niet terugzetten naar een eerdere waarde.
Bij de meeste bewerkingen: houd de waarde van de gebruiker zichtbaar, markeer deze als niet opgeslagen en toon een inline‑fout bij het bewerkte veld met een duidelijke Retry‑optie. Draai alleen hard terug als de wijziging echt niet kan blijven (bijv. verloren permissies) en leg uit waarom.
Voer een refetch uit wanneer de wijziging veel plekken kan beïnvloeden (totalen, sortering, permissies, afgeleide velden), omdat lokaal patchen dan snel foutgevoelig wordt. Merge lokaal wanneer het een kleine, geïsoleerde update is en de server het bijgewerkte object terugstuurt; accepteer dan server‑eigenschappen zoals timestamps en berekende waarden.