Waarom statebeheer een van de moeilijkste frontend-problemen is

Wat “state” echt betekent in een frontend-app

Een plain-language definitie

In een frontend-app is state gewoon de data waarop je UI afhankelijk is en die in de loop van de tijd kan veranderen.

Als state verandert, zou het scherm moeten bijwerken om overeen te komen. Als het scherm niet bijwerkt, inconsistent bijwerkt of een mix van oude en nieuwe waarden toont, merk je meteen “state-problemen”—knoppen die uitgeschakeld blijven, totalen die niet kloppen, of een weergave die niet reflecteert wat de gebruiker zojuist deed.

Veelvoorkomende voorbeelden die je elke dag ziet

State verschijnt in zowel kleine als grote interacties, zoals:

• Formuliervelden: wat de gebruiker heeft getypt, of een checkbox is aangevinkt, welke fouten getoond moeten worden
• Navigatiekeuzes: geselecteerd tabblad, huidige stap in een wizard, uitgeklapte/ingeklapte secties
• Winkelwagen/checkout data: items, aantallen, toegepaste coupons, berekende totalen
• Gebruikerssessie: ingelogde gebruiker info, permissies, feature flags, “remember me”-voorkeuren

Sommige hiervan zijn “tijdelijk” (zoals een geselecteerd tabblad), terwijl andere “belangrijk” aanvoelen (zoals een winkelwagen). Het zijn allemaal state omdat ze bepalen wat de UI nu rendert.

Waarom state meer is dan “variabelen in een component”

Een gewone variabele doet er alleen toe waar hij leeft. State is anders omdat het regels heeft:

• Eigenaarschap: welk deel van de app mag het veranderen
• Update-flow: wanneer en hoe veranderingen re-renders triggeren
• Consistentie: ervoor zorgen dat meerdere UI-delen niet uit sync raken

Het echte doel van statebeheer is niet data opslaan—het is updates voorspelbaar maken zodat de UI consistent blijft. Als je kunt beantwoorden “wat veranderde, wanneer en waarom,” wordt state beheersbaar. Als dat niet lukt, veranderen zelfs simpele features in verrassingen.

Waarom state eerst makkelijk lijkt (en dan ineens niet meer)

Aan het begin van een frontend-project voelt state bijna saai—in de goede zin. Je hebt één component, één input en één duidelijke update. Een gebruiker typt in een veld, je slaat die waarde op en de UI rendert opnieuw. Alles is zichtbaar, direct en afgebakend.

Het simpele geval: één component, één update

Stel je een enkel tekstveld voor dat een preview toont van wat je typte:

• De state leeft in dezelfde component die het veld rendert.
• De update gebeurt als directe reactie op een gebruikersactie.
• Er is geen discussie over “wie bezit” de data.

In die opzet is state in feite: een variabele die in de loop van de tijd verandert. Je kunt aanwijzen waar het staat en waar het wordt bijgewerkt, en klaar.

Waarom lokale componentstate logisch voelt

Lokale state werkt omdat het mentale model overeenkomt met de code-structuur:

• Scope is klein (één component, misschien een paar kinderen).
• Updates voelen synchroon vanuit het perspectief van de gebruiker.
• Datastroom is duidelijk: input → update → render.

Zelfs als je een framework als React gebruikt, hoef je niet diep over architectuur na te denken. De defaults zijn vaak genoeg.

Wat verandert naarmate de app groeit

Zodra de app stopt met “een pagina met een widget” te zijn en een product wordt, woont state niet meer op één plek.

Dezelfde data kan nu nodig zijn in:

• meerdere schermen (navigatie)
• verafgelegen componenten (gedeelde UI)
• herlaadacties en restarts (persistentie)
• meerdere gebruikers/apparaten (server-synchronisatie)

Een profielnaam kan in een header worden getoond, bewerkt op een instellingenpagina, gecachet voor sneller laden en gebruikt worden om een welkomstbericht te personaliseren. Plots is de vraag niet “hoe sla ik deze waarde op?” maar “waar moet deze waarde leven zodat hij overal correct blijft?”

Complexiteit stijgt niet lineair

State-complexiteit groeit niet geleidelijk met features—het maakt sprongen.

Het toevoegen van een tweede plek die dezelfde data leest is niet “twee keer zo moeilijk.” Het introduceert coördinatieproblemen: views consistent houden, voorkomen dat waarden verouderen, beslissen wat wat bijwerkt en omgaan met timing. Zodra je een paar gedeelde state-stukken plus async werk hebt, kun je gedrag krijgen dat moeilijk te doorgronden is—ook al lijkt elke individuele feature op zichzelf simpel.

Te veel bronnen van waarheid

State wordt pijnlijk wanneer hetzelfde “feit” op meer dan één plek wordt opgeslagen. Elke kopie kan afwijken, en nu raakt je UI met zichzelf in discussie.

De gebruikelijke verdachten

De meeste apps eindigen met meerdere plaatsen die “waarheid” kunnen bevatten:

• Serverdata (je API/database): het canonieke record
• Clientcache (bijv. cache van een data-fetching library): een lokale spiegel die ververst moet worden
• Lokale UI-state (componentstate): wat de gebruiker nu aan het doen is
• URL (pad, queryparams, hash): state die je kunt bookmarken, delen en herstellen

Al deze plekken kunnen geldig eigenaar zijn voor sommige state. Het probleem begint wanneer ze allemaal proberen dezelfde state te bezitten.

Hoe duplicatie gebeurt

Een veelvoorkomend patroon: haal serverdata op en kopieer het dan naar lokale state “zodat we het kunnen bewerken.” Bijvoorbeeld: je laadt een gebruikersprofiel en zet formState = userFromApi. Later wordt de server opnieuw opgehaald (of een andere tab wijzigt het record), en nu heb je twee versies: de cache zegt het ene, je form zegt het andere.

Duplicatie sluipt ook binnen via “behulpzame” transformaties: zowel items als itemsCount opslaan, of zowel selectedId en selectedItem bewaren.

Symptomen die je herkent

Wanneer er meerdere bronnen van waarheid zijn, klinken bugs vaak zo:

• “Het werkt alleen op dit scherm.”
• De UI is inconsistent na navigatie of refresh.
• Data ziet er correct uit in het ene component maar verouderd in het andere.
• Opslaan lukt, maar de lijstweergave update niet (of twee keer).

Vuistregel

Voor elk stukje state: kies één eigenaar—de plek waar updates gemaakt worden—en behandel alles anders als een projectie (alleen-lezen, afgeleid, of eenrichtings-gesynchroniseerd). Als je de eigenaar niet kunt aanwijzen, sla je waarschijnlijk dezelfde waarheid twee keer op.

Async werk en bijwerkingen maken state lastig

Veel frontend-state voelt simpel omdat het synchroon is: een gebruiker klikt, je zet een waarde, de UI update. Bijwerkingen breken dat nette stap-voor-stap verhaal.

Wat telt als een bijwerking?

Bijwerkingen zijn acties die buiten het pure “render op basis van data” model van je component reiken:

• Netwerkcalls (fetchen, opslaan, retry)
• Timers en debouncing (setTimeout, intervals)
• Subscripties (web sockets, event listeners)
• Browseropslag (localStorage/sessionStorage)

Elk van deze kan later afgaan, onverwacht falen of meer dan eens draaien.

Waarom async-state moeilijker is dan sync-state

Async-updates introduceren tijd als variabele. Je denkt niet langer “wat gebeurde,” maar “wat kan er nog steeds gebeuren.” Twee requests kunnen overlappen. Een trage respons kan arriveren na een nieuwere. Een component kan unmounten terwijl een async callback nog probeert state te updaten.

Daarom zien bugs er vaak uit als:

• Loading-flags die voor altijd vastzitten (error-pad heeft ze niet gereset of request is geannuleerd)
• UI die oude data flikkert (verouderde cachewaarde getoond als “definitief”)
• Verouderde responses die nieuwere overschrijven (request A voltooit na request B)

Een eenvoudige strategie: model de request expliciet

In plaats van booleans als isLoading door de UI te strooien, behandel async-werk als een kleine toestandsmachine:

• idle (niets gestart)
• loading (in uitvoering)
• success (data beschikbaar)
• error (fout vastgelegd)

Houd zowel de data als de status bij en bewaar een identifier (zoals een request id of query key) zodat je late responses kunt negeren. Dit maakt “wat moet de UI nu tonen?” een eenvoudige beslissing, geen gok.

UI-state vs serverstate (ze lijken op elkaar, maar zijn dat niet)

Veel state-hoofdpijn begint met een simpele verwarring: “wat de gebruiker nu doet” en “wat de backend zegt dat waar is” hetzelfde behandelen. Beiden kunnen in de loop van de tijd veranderen, maar ze volgen verschillende regels.

UI-state: wat de interface doet

UI-state is tijdelijk en interactsie-gedreven. Het bestaat om het scherm te renderen zoals de gebruiker het in dit moment verwacht.

Voorbeelden: modals open/dicht, actieve filters, een conceptzoekveld, hover/focus, welk tabblad geselecteerd is en paginatie-UI (huidige pagina, pagina-grootte, scrollpositie).

Deze state is meestal lokaal voor een pagina of componenttree. Het is prima als het reset wanneer je weg navigeert.

Serverstate: wat je hebt opgehaald (en wat ergens anders kan veranderen)

Serverstate is data van een API: gebruikersprofielen, productlijsten, permissies, notificaties, opgeslagen instellingen. Het is “remote truth” dat kan veranderen zonder dat jouw UI iets doet (iemand anders bewerkt het, de server herberekent het, een background job werkt het bij).

Omdat het remote is, heeft het ook metadata nodig: loading/error-states, cachetijden, retries en invalidatie.

Waarom ze mixen verwarring geeft

Als je UI-drafts in serverdata opslaat, kan een refetch lokale bewerkingen overschrijven. Als je serverresponses in UI-state bewaart zonder cachingregels, vecht je tegen verouderde data, dubbele fetches en inconsistente schermen.

Een veelvoorkomend faalpatroon: de gebruiker bewerkt een formulier terwijl een background refetch voltooit, en de binnenkomende response overschrijft de draft.

Een praktische richtlijn

Beheer serverstate met cachingpatronen (fetch, cache, invalidate, refetch on focus) en behandel het als gedeeld en asynchroon.

Beheer UI-state met UI-tools (lokale componentstate, context voor echt gedeelde UI-zaken) en houd drafts gescheiden totdat je ze bewust “opslaat” terug naar de server.

Afgeleide state en de regel “sla niet op wat je kunt berekenen”

Afgeleide state is elke waarde die je kunt berekenen uit andere state: een winkelwagen-totaal uit line items, een gefilterde lijst uit de originele lijst + zoekquery, of een canSubmit-vlag uit veldwaarden en validatieregels.

Het is verleidelijk om deze waarden op te slaan omdat het handig lijkt (“ik sla total ook wel op in state”). Maar zodra de inputs op meer dan één plek veranderen, loop je drift-risico: de opgeslagen total komt niet meer overeen met de items, de gefilterde lijst reflecteert de huidige query niet, of de submitknop blijft uitgeschakeld na het oplossen van een fout. Deze bugs zijn vervelend omdat niets op zichzelf “fout” lijkt—elke statevariabele is geldig, maar inconsistent met de rest.

Geef de voorkeur aan selectors / berekende waarden

Een veiliger patroon: bewaar de minimale bron van waarheid en bereken alles anders tijdens het lezen. In React kan dit een simpele functie zijn, of een gememoiseerde berekening.

const items = useCartItems();
const total = items.reduce((sum, item) => sum + item.price * item.qty, 0);

const filtered = products.filter(p => p.name.includes(query));

In grotere apps formaliseren “selectors” (of computed getters) dit idee: op één plek definieer je hoe total, filteredProducts, visibleTodos worden afgeleid, en iedere component gebruikt dezelfde logica.

Wanneer het oké is afgeleide waarden te cachen

Op elke render berekenen is meestal prima. Cache wanneer je een echte kostenpost hebt gemeten: dure transformaties, enorme lijsten of afgeleiden die door veel componenten gedeeld worden. Gebruik memoization (useMemo, selector-memoization) zodat de cachekeys de echte inputs zijn—anders heb je weer drift, maar dan met een prestatie-excuus.

Globaal vs lokaal: kies de juiste eigenaar

State wordt pijnlijk wanneer onduidelijk is wie het beheert.

Wat “eigenaarschap” betekent

De eigenaar van een stuk state is de plek in je app die het recht heeft om het bij te werken. Andere delen van de UI mogen het lezen (via props, context, selectors, enz.), maar mogen het niet direct veranderen.

Duidelijk eigenaarschap beantwoordt twee vragen:

• Wie mag deze waarde updaten? (de eigenaar)
• Wie mag deze waarde lezen? (consumenten)

Wanneer die grenzen vervagen, krijg je conflicterende updates, “waarom veranderde dit?”-momenten en moeilijk herbruikbare componenten.

Globale state: handig, maar koppeling glipt er in

State in een globale store (of toplevel context) plaatsen voelt schoon: alles kan het bereiken en je voorkomt prop-drilling. De trade-off is ongewenste koppeling—ineens hangen niet-gerelateerde schermen aan dezelfde waarden en voeren kleine wijzigingen door naar veel plaatsen in de app.

Globale state past goed bij zaken die écht cross-cutting zijn, zoals de huidige gebruikerssessie, app-brede feature flags of een gedeelde notificatie-queue.

Lift state omhoog—alleen zover als nodig

Een veelgebruikt patroon is lokaal beginnen en state “optillen” naar de dichtstbijzijnde gemeenschappelijke ouder als twee sibling-delen moeten coördineren.

Als slechts één component de state nodig heeft, houd het daar. Als meerdere componenten het nodig hebben, lift het naar de kleinste gedeelde eigenaar. Als veel verspreide delen het nodig hebben, overweeg dan pas global.

Een eenvoudige heuristiek

Houd state dicht bij waar het gebruikt wordt tenzij delen moeten delen.

Dit houdt componenten begrijpelijker, vermindert onbedoelde afhankelijkheden en maakt toekomstige refactors minder eng omdat minder delen van de app dezelfde data mogen muteren.

Concurrency, races en uit-orde updates

Frontend-apps voelen “single-threaded,” maar gebruikersinput, timers, animaties en netwerkrequests lopen onafhankelijk. Dat betekent dat meerdere updates tegelijk onderweg kunnen zijn—en ze hoeven niet in de volgorde te finishen waarin je ze startte.

Wanneer updates botsen

Een veelvoorkomende botsing: twee delen van de UI updaten dezelfde state.

• Een zoekveld werkt query bij bij elke toetsaanslag.
• Een filterdropdown werkt query (of dezelfde resultatenlijst) bij wanneer deze verandert.

Op zichzelf zijn beide updates correct. Samen kunnen ze elkaar overschrijven afhankelijk van timing. Nog erger: je kunt resultaten van een vorige query tonen terwijl de UI de nieuwe filters laat zien.

Racecondities: snelle gebruikers, trage netwerken

Racecondities ontstaan wanneer je request A stuurt en snel daarna request B—maar request A komt als laatste terug.

Voorbeeld: de gebruiker typt “c”, “ca”, “cat”. Als de “c” request traag is en de “cat” request snel, kan de UI kort “cat”-resultaten tonen en daarna overschreven worden door verouderde “c”-resultaten wanneer die oudere response uiteindelijk arriveert.

De bug is subtiel omdat alles “werkte”—alleen in de verkeerde volgorde.

Technieken om uit-orde bugs te verminderen

Je wilt gewoonlijk één van deze strategieën:

1. Annuleer het vorige request wanneer een nieuw request het vervangt (bijv. met AbortController).
2. Negeer verouderde responses door te checken of de response nog overeenkomt met de laatste inputs.
3. Gebruik request IDs / sequence numbers en accepteer alleen de nieuwste.

Een eenvoudige request-ID aanpak:

let latestRequestId = 0;

async function fetchResults(query) {
  const requestId = ++latestRequestId;
  const res = await fetch(`/api/search?q=${encodeURIComponent(query)}`);
  const data = await res.json();

  if (requestId !== latestRequestId) return; // stale response
  setResults(data);
}

Optimistische updates (en hoe ze fout gaan)

Optimistische updates laten de UI direct reageren: je werkt het scherm bij voordat de server bevestigt. Maar concurrency kan veronderstellingen breken:

• De gebruiker klikt snel twee keer op “Like” (like → unlike), maar de requests lossen in een andere volgorde op.
• Je verlaagt optimistisch de voorraad, daarna faalt een latere request en moet je terugdraaien—terwijl de gebruiker al weg navigeerde of meer wijzigingen maakte.

Om optimisme veilig te houden, heb je meestal een duidelijk reconciliatieregelsysteem nodig: track de pending actie, pas serverresponses toe in volgorde en, als je moet terugdraaien, rol terug naar een bekende checkpoint (niet “wat de UI nu toevallig laat zien”).

Prestaties: wanneer state-updates te duur zijn

State-updates zijn niet “gratis.” Wanneer state verandert, moet de app bepalen welke delen van het scherm beïnvloed kunnen worden en dan het werk doen om de nieuwe realiteit te tonen: waarden opnieuw berekenen, UI opnieuw renderen, logica opnieuw uitvoeren en soms opnieuw fetchen of valideren. Als die kettingreactie groter is dan nodig, voelt de gebruiker het als vertraging, haperingen of knoppen die lijken te “nadenken” voordat ze reageren.

Waarom een kleine verandering groot kan voelen

Een enkele toggle kan per ongeluk veel extra werk triggeren:

• Grote delen van de UI re-renderen terwijl maar één klein stukje verandering nodig had.
• Lijsten worden opnieuw getekend en gemeten, waardoor scrollen haperingen vertoont.
• Objecten en arrays worden bij elke update opnieuw aangemaakt (“deep churn”), waardoor de app niet makkelijk kan zien wat echt anders is.

Het resultaat is niet alleen technisch—het is ervaringsgericht: typen voelt vertraagd, animaties haperen en de interface verliest die “snappy” kwaliteit die mensen associëren met gepolijste producten.

Veelvoorkomende prestatievalkuilen

Een van de meest voorkomende oorzaken is state die te breed is: een “grote emmer” object die veel niet-gerelateerde informatie bevat. Het bijwerken van één veld laat de hele emmer nieuw lijken, dus meer van de UI wordt wakker dan nodig.

Een andere valkuil is het opslaan van berekende waarden in state en die handmatig bijwerken. Dat veroorzaakt vaak extra updates (en dus extra UI-werk) om alles synchroon te houden.

Tactieken om de UI snel te houden

Splits state in kleinere slices. Houd niet-gerelateerde concerns apart zodat het bijwerken van een zoekinput niet een hele pagina aan resultaten ververst.

Normaliseer data. Sla een item één keer op en verwijs ernaar in plaats van het op meerdere plekken te dupliceren. Dit vermindert herhaalde updates en voorkomt “change storms” waarbij één wijziging veel kopieën moet herschrijven.

Memoize afgeleide waarden. Als een waarde kan worden berekend uit andere state (zoals gefilterde resultaten), cache die berekening zodat hij alleen opnieuw wordt gemaakt wanneer de inputs echt veranderen.

Het doel: minder stalls, minder verrassingen

Goed prestatiebewust statebeheer draait vooral om containment: updates zouden het kleinste mogelijke gebied moeten beïnvloeden en duur werk moet alleen gebeuren wanneer het echt nodig is. Als dat klopt, merken gebruikers het framework niet meer en gaan ze de interface vertrouwen.

State debuggen en testen zonder giswerk

State-bugs voelen vaak persoonlijk: de UI is “fout,” maar je kunt de simpelste vraag niet beantwoorden—wie veranderde deze waarde en wanneer? Als een getal flippt, een banner verdwijnt of een knop zichzelf uitschakelt, heb je een tijdlijn nodig, geen vermoeden.

Maak veranderingen traceerbaar (niet mysterieus)

De snelste weg naar helderheid is een voorspelbare update-flow. Of je nu reducers, events of een store gebruikt, streef naar een patroon waarbij:

• Veranderingen gebeuren via een kleine set goed-benamede acties (geen willekeurige mutaties)
• Elke actie een duidelijke payload heeft (setShippingMethod('express'), niet updateStuff)
• Je acties en resulterende state-transities consistent kunt loggen

Duidelijke action-logging verandert debuggen van “staar naar het scherm” naar “volg het ontvangstbewijs.” Zelfs simpele console logs (actie-naam + kernvelden) zijn beter dan proberen te reconstrueren wat er gebeurde uit symptomen.

Test de logica waar die stabiel is

Probeer niet elke re-render te testen. Test in plaats daarvan de delen die zich als pure logica zouden moeten gedragen:

• Unit-test reducers / state-updaters: gegeven vorige state + actie, controleer de volgende state
• Unit-test selectors / afgeleide berekeningen: gegeven state, controleer de berekende output
• Integratietest belangrijke gebruikersstromen: inloggen → data laden → bewerken → opslaan → bevestiging zien

Deze mix vangt zowel “rekensom-bugs” als echte wiring-problemen op.

Voeg lichte instrumentatie toe voor async-bugs

Async-problemen verstoppen zich in gaten. Voeg minimale metadata toe die tijdlijnen zichtbaar maakt:

• timestaps op belangrijke updates
• request IDs (koppel de ID aan acties en responses)

Dan kun je onmiddellijk bewijzen dat een late response een nieuwere overschreef—and je het met vertrouwen repareren.

Een state-beheerbenadering kiezen (zonder tool-oorlogen)

Een state-tool kiezen is makkelijker als je het ziet als resultaat van ontwerpbeslissingen, niet als startpunt. Voordat je libraries vergelijkt, kaart je state-grenzen: wat is puur lokaal voor een component, wat moet gedeeld worden en wat is eigenlijk “serverdata” die je ophaalt en synchroniseert.

Selectiecriteria die ertoe doen

Een praktische manier om te beslissen is kijken naar een paar constraints:

• App-grootte en levensduur: een klein intern hulpmiddel kan simpel blijven; een langlevend product profiteert van sterkere conventies.
• Teamgewoonten: kies iets dat je team consequent kan gebruiken (en betrouwbaar kan reviewen).
• Async-behoeften: veel fetches, caching, paginatie en mutaties veranderen de vergelijking.
• State-complexiteit: cross-page workflows, undo/redo en multi-step formulieren vragen vaak meer structuur.

Een hoog-niveau vergelijking (zonder ideologie)

• Context + hooks: prima voor dependency injection en laagfrequente gedeelde waarden (theme, auth-info). Het kan werken voor state, maar frequente updates kunnen rommelig worden zonder extra patronen.
• Redux-achtige stores: sterke conventies, voorspelbare updates en uitstekende tooling. Het is het beste wanneer je een duidelijk auditspoor of complexe coördinatie tussen features nodig hebt.
• Atom-stores (fijnkorrelige state): ergonomisch voor gedeelde state zonder veel reducer-wiring. Vaak makkelijker incrementeel te schalen.
• Query-caches (server-state tools): gespecialiseerd in fetchen, cachen, deduplicatie, background refetching en mutaties. Ze nemen veel van de async-lijmcode weg.

Vermijd tool-first denken

Als je begint met “we gebruiken X overal,” sla je waarschijnlijk de verkeerde dingen op op de verkeerde plek. Begin met eigenaarschap: wie update deze waarde, wie leest het en wat moet er gebeuren als het verandert.

Tools combineren is vaak de beste optie

Veel apps doen het goed met een server-state library voor API-data plus een kleine UI-state-oplossing voor client-only zorgen zoals modals, filters of draft form-waarden. Het doel is duidelijkheid: elk type state leeft waar het het makkelijkst te begrijpen is.

Waar Koder.ai past

Als je experimenteert met state-grenzen en async-flows, kan Koder.ai het “probeer het, observeer het, verfijn het” proces versnellen. Omdat het React-frontends (en Go + PostgreSQL backends) genereert vanuit chat met een agent-based workflow, kun je snel alternatieve eigenaarschapsmodellen prototype (lokaal vs globaal, servercache vs UI-drafts) en daarna de versie houden die voorspelbaar blijft.

Twee praktische features helpen bij experimenteren met state: Planning Mode (om het statemodel uit te lijnen vóór bouwen) en snapshots + rollback (om veilig refactors te testen zoals “verwijder afgeleide state” of “introduceer request IDs” zonder een werkende basislijn te verliezen).

Een praktische checklist om state minder pijnlijk te maken

State wordt makkelijker wanneer je het als een ontwerpprobleem behandelt: beslis wie het bezit, wat het voorstelt en hoe het verandert. Gebruik deze checklist wanneer een component mysterieus begint te voelen.

1) Maak eigenaarschap en de single source of truth helder

Vraag: Welk deel van de app is verantwoordelijk voor deze data? Zet state zo dicht mogelijk bij waar het gebruikt wordt en lift het alleen op als meerdere delen het echt nodig hebben.

• Eén eigenaar per stuk state.
• Geef data door; stuur wijzigingen omhoog via callbacks/events.
• Als twee plekken dezelfde waarde kunnen updaten, heb je geen bron van waarheid—je hebt een conflict in de dop.

2) Vermijd duplicatie en modelleer afgeleide waarden

Als je iets kunt berekenen uit andere state, sla het dan niet op.

• Bewaar de minimale inputs (bijv. items, filterText).
• Bereken outputs (bijv. visibleItems) tijdens render of via memoization.

3) Maak async-states expliciet (niet impliciet)

Async-werk is duidelijker wanneer je het direct modelleert:

• Geef de voorkeur aan een klein “request state”-vorm: status: 'idle' | 'loading' | 'success' | 'error', plus data en error.
• Behandel “loading” en “error” als first-class UI-states, niet als verspreide booleans.

4) Let op veelvoorkomende antipatronen

• Props naar state kopiëren “voor het geval” (creëert drift).
• Alles globaliseren (maakt niet-gerelateerde schermen gekoppeld).
• Boolean-soep (isLoading, isFetching, isSaving, hasLoaded, …) in plaats van één status.

5) Refactor met kleine, veilige stappen

• Splits gemengde state: scheid UI-zaken (open/dicht, inputtekst) van serverdata.
• Verwijder opgeslagen afgeleide waarden en bereken ze vanuit de echte bron.
• Centraliseer bijwerkingen (fetchen, subscriptions) op één plek per feature.

Praktische doelen

Streef naar minder “hoe is het in deze staat gekomen?”-bugs, veranderingen die niet vijf bestanden hoeven aan te passen en een mentaal model waarbij je naar één plek kunt wijzen en zeggen: hier woont de waarheid.