Varför tillståndshantering är ett av de svåraste frontend-problemen

Vad “tillstånd” egentligen betyder i en frontend-app

En vardaglig definition

I en frontend-app är tillstånd helt enkelt de data som ditt UI är beroende av och som kan ändras över tid.

När tillstånd ändras ska skärmen uppdateras för att matcha. Om skärmen inte uppdateras, uppdateras inkonsekvent eller visar en blandning av gamla och nya värden, känner du av “tillståndsproblem” direkt—knappar som förblir inaktiva, totalsummor som inte stämmer, eller en vy som inte speglar vad användaren just gjorde.

Vanliga exempel du ser varje dag

Tillstånd dyker upp i både små och stora interaktioner, såsom:

• Formulärfält: vad användaren skrev, om en kryssruta är markerad, vilka fel som ska visas
• Navigationsval: vald flik, aktuellt steg i en guide, expanderade/komprimerade sektioner
• Shopping-/kundvagnsdata: artiklar, kvantiteter, använda kuponger, beräknade totalsummor
• Användarsession: inloggad användarinformation, behörigheter, feature-flaggor, preferenser som “kom ihåg mig”

Vissa av dessa är “tillfälliga” (som en vald flik), medan andra känns “viktiga” (som en kundvagn). De är alla tillstånd eftersom de påverkar vad UI:t renderar just nu.

Varför tillstånd är mer än “variabler i en komponent”

En vanlig variabel spelar bara roll där den bor. Tillstånd är annorlunda eftersom det har regler:

• Ägande: vilken del av appen som får ändra det
• Uppdateringsflöde: när och hur ändringar triggar omrenderingar
• Konsistens: att säkerställa att flera delar av UI:t inte glider isär

Det verkliga målet med tillståndshantering är inte att lagra data—det är att göra uppdateringar förutsägbara så att UI:t förblir konsekvent. När du kan svara på “vad ändrades, när och varför”, blir tillstånd hanterbart. När du inte kan det, förvandlas även enkla funktioner till överraskningar.

Varför tillstånd känns lätt först (och sedan plötsligt inte)

I början av ett frontend-projekt känns tillstånd nästan tråkigt—på ett bra sätt. Du har en komponent, ett fält och en tydlig uppdatering. En användare skriver i ett fält, du sparar värdet och UI:t renderas om. Allt är synligt, omedelbart och avgränsat.

Det enkla fallet: en komponent, en uppdatering

Föreställ dig ett enda textfält som förhandsvisar vad du skrev:

• Tillståndet ligger i samma komponent som renderar fältet.
• Uppdateringen sker direkt i respons till en användaråtgärd.
• Det finns ingen debatt om “vem äger” datan.

I den här uppsättningen är tillstånd i princip: en variabel som ändras över tid. Du kan peka på var det lagras och var det uppdateras, och du är klar.

Varför lokalt komponenttillstånd känns enkelt

Lokalt tillstånd fungerar eftersom den mentala modellen matchar kodstrukturen:

• Omfånget är litet (en komponent, kanske några barn).
• Uppdateringarna upplevs som synkrona från användarens synpunkt.
• Dataflödet är uppenbart: input → uppdatering → render.

Även om du använder ett ramverk som React behöver du inte tänka djupt på arkitektur. Standardlösningarna räcker ofta.

Vad som förändras när appen växer

Så fort appen slutar vara “en sida med en widget” och blir “en produkt”, slutar tillståndet att leva på ett ställe.

Plötsligt kan samma bit data behövas över:

• flera skärmar (navigering)
• avlägsna komponenter (delat UI)
• omladdningar och omstarter (persistens)
• flera användare/enheter (serversynkronisering)

Ett profilnamn kan visas i en header, redigeras på en inställningssida, cache:as för snabbare laddning och också användas för att personanpassa ett välkomstmeddelande. Plötsligt handlar frågan inte om “hur lagrar jag detta värde?” utan “var bör detta värde bo så att det förblir korrekt överallt?”

Komplexiteten ökar icke-linjärt

Tillståndskomplexitet växer inte gradvis med funktionerna—den hoppar.

Att lägga till en andra plats som läser samma data är inte “två gånger så svårt.” Det introducerar koordineringsproblem: hålla vyer konsekventa, förhindra gamla värden, bestämma vad som uppdaterar vad och hantera timing. När du har några delade tillstånd plus asynkront arbete, kan du få beteenden som är svåra att resonera om—även om varje individuell funktion fortfarande ser enkel ut.

För många sanningskällor

Tillstånd blir smärtsamt när samma “fakta” lagras på mer än ett ställe. Varje kopia kan glida isär, och nu börjar ditt UI bråka med sig självt.

De vanliga misstänkta

De flesta appar slutar med flera platser som kan hålla “sanningen”:

• Serverdata (API/databas): den kanoniska posten
• Klientcache (t.ex. data fetching-biblioteks-cache): en lokal spegel som ska uppdateras
• Lokalt UI-tillstånd (komponenttillstånd): vad användaren gör just nu
• URL (path, query params, hash): tillstånd som du kan bokmärka, dela och återställa

Alla dessa är giltiga ägare för viss typ av tillstånd. Problemen börjar när de alla försöker äga samma tillstånd.

Hur duplication händer

Ett vanligt mönster: hämta serverdata och kopiera den sedan till lokalt tillstånd “så att vi kan redigera”. Till exempel: du laddar en användarprofil och sätter formState = userFromApi. Senare refetchar servern (eller en annan flik uppdaterar posten), och nu har du två versioner: cachen säger en sak, ditt formulär säger en annan.

Duplication smyger sig också in genom “hjälpsamma” transformationer: att lagra både items och itemsCount, eller att lagra selectedId och selectedItem.

Symptom du känner igen

När det finns flera sanningskällor tenderar buggar att låta som:

• “Det fungerar bara på den här skärmen.”
• UI:t är inkonsekvent efter navigering eller uppdatering.
• Data ser korrekt ut i en komponent men föråldrad i en annan.
• Spara lyckas, men listvyn uppdateras inte (eller uppdateras två gånger).

Tumregel

För varje bit tillstånd, välj en ägare—platsen där uppdateringar görs—och behandla allt annat som en projektion (skrivskyddad, avledd eller synkroniserad i en riktning). Om du inte kan peka ut ägaren, lagrar du förmodligen samma sanning flera gånger.

Asynkront arbete och sidoeffekter gör tillstånd knepigt

Mycket frontend-tillstånd känns enkelt eftersom det är synkront: en användare klickar, du sätter ett värde, UI:t uppdateras. Sidoeffekter bryter den där prydliga steg-för-steg-berättelsen.

Vad räknas som en sidoeffekt?

Sidoeffekter är alla handlingar som når utanför din komponents rena “rendera baserat på data”-modell:

• Nätverksanrop (hämta, spara, göra omförsök)
• Timer och debouncing (setTimeout, intervall)
• Prenumerationer (web sockets, event listeners)
• Browserlagring (localStorage/sessionStorage)

Var och en kan skjuta iväg senare, misslyckas oväntat eller köras fler gånger.

Varför asynkront tillstånd är svårare än synkront

Asynkrona uppdateringar introducerar tid som en variabel. Du resonerar inte längre om “vad hände”, utan om “vad kan fortfarande hända”. Två förfrågningar kan överlappa. Ett långsamt svar kan komma efter ett nyare. En komponent kan unmountas medan ett asynkront callback fortfarande försöker uppdatera tillstånd.

Därför ser buggar ofta ut så här:

• Loading-flaggor fastnar för alltid (felvägen rensade inte dem, eller förfrågan avbröts)
• UI blinkar gammal data (stale cached value visas som “slutgiltig”)
• Föråldrade svar skriver över nya (förfrågan A slutförs efter förfrågan B)

En enkel strategi: modellera förfrågan explicit

Istället för att strö ut booleaner som isLoading över UI:t, behandla asynkront arbete som en liten tillståndsmaskin:

• idle (inget startat)
• loading (pågår)
• success (data tillgänglig)
• error (fel fångat)

Spåra både data och status tillsammans, och behåll en identifierare (som en request id eller query key) så att du kan ignorera sena svar. Detta gör “vad ska UI:t visa just nu?” till ett enkelt beslut, inte en gissning.

UI-tillstånd vs server-tillstånd (de ser lika ut, men är det inte)

Många tillståndsproblem börjar med en enkel förväxling: att behandla “vad användaren gör just nu” som samma sak som “vad backend säger är sant”. Båda kan ändras över tid, men de följer olika regler.

UI-tillstånd: vad gränssnittet gör

UI-tillstånd är temporärt och interaktionsdrivet. Det finns för att rendera skärmen som användaren förväntar sig i detta ögonblick.

Exempel inkluderar modaler som är öppna/stängda, aktiva filter, ett sökfält-utkast, hover/fokus, vilken flik som är vald och paginerings-UI (aktuell sida, sidstorlek, scrollposition).

Detta tillstånd är vanligtvis lokalt för en sida eller komponentträd. Det är okej om det återställs när du navigerar bort.

Server-tillstånd: vad du hämtade (och vad kan ändras någon annanstans)

Server-tillstånd är data från ett API: användarprofiler, produktlistor, behörigheter, notiser, sparade inställningar. Det är “fjärrsanningen” som kan ändras utan att ditt UI gör något (någon annan redigerar den, servern beräknar om den, ett bakgrundsjobb uppdaterar den).

Eftersom det är fjärrbaserat behöver det också metadata: loading/error-tillstånd, cache-tidsstämplar, omförsök och invalidation.

Varför blandning orsakar förvirring

Om du lagrar UI-utkast inuti serverdata kan en refetch torka bort lokala redigeringar. Om du lagrar serverresponse i UI-tillstånd utan caching-regler kommer du kämpa mot föråldrade data, dubblettförfrågningar och inkonsekventa skärmar.

Ett vanligt felläge: användaren redigerar ett formulär medan en bakgrundsrefetch slutförs, och det inkommande svaret skriver över utkastet.

En praktisk riktlinje

Hantera server-tillstånd med cachemönster (hämta, cache:a, invalidation, refetcha vid fokus) och betrakta det som delat och asynkront.

Hantera UI-tillstånd med UI-verktyg (lokalt komponenttillstånd, context för verkligt delade UI-angelägenheter) och håll utkast separata tills du avsiktligt “sparar” dem tillbaka till servern.

Avlett tillstånd och regeln “spara inte det du kan räkna ut”

Avlett tillstånd är vilket värde som helst du kan räkna ut från annat tillstånd: en kundvagnssumma från radartiklar, en filtrerad lista från ursprungslistan + en sökfråga, eller ett canSubmit-flagga från fältvärden och valideringsregler.

Det frestar att lagra dessa värden eftersom det känns bekvämt (“jag sparar total i state också”). Men så fort inputen ändras på mer än ett ställe, riskerar du drift: det sparade total matchar inte längre artiklarna, den filtrerade listan speglar inte den aktuella frågan, eller submit-knappen förblir inaktiverad efter att ett fel rättats. Dessa buggar är irriterande eftersom inget ser “fel” ut isolerat—varje tillståndsvariabel är giltig i sig, bara inkonsekvent med resten.

Föredra selectors / beräknade värden

Ett säkrare mönster är: spara minimal källan till sanningen, och beräkna allt annat vid lästid. I React kan detta vara en enkel funktion eller en memoiserad beräkning.

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

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

I större appar formaliserar “selectors” (eller beräknade getters) den här idén: en plats definierar hur man härleder total, filteredProducts, visibleTodos, och varje komponent använder samma logik.

När det är OK att cache:a avledda värden

Att beräkna vid varje render är vanligtvis fint. Cache:a när du mätt en verklig kostnad: dyra transformationer, enorma listor eller avledda värden delade över många komponenter. Använd memoization (useMemo, selector-memoization) så att cache-nycklarna är de verkliga inputarna—annars är du tillbaka i drift, fast under en prestanda-fasad.

Globalt vs lokalt: välja rätt ägare

Tillstånd blir jobbigt när det är oklart vem äger det.

Vad “ägande” betyder

Ägaren av en bit tillstånd är platsen i din app som har rätt att uppdatera det. Andra delar av UI:t kan läsa det (via props, context, selectors, etc.), men de bör inte kunna ändra det direkt.

Tydligt ägande svarar på två frågor:

• Vem kan uppdatera detta värde? (ägaren)
• Vem kan läsa detta värde? (konsumenter)

När dessa gränser suddas ut får du konflikter, “varför ändrades detta?”-ögonblick och komponenter som är svåra att återanvända.

Globalt tillstånd: bekvämt, men koppling smyger sig in

Att lägga tillstånd i en global store (eller top-level context) kan kännas snyggt: allt kan nå det och du undviker prop drilling. Nackdelen är oavsiktlig koppling—plötsligt beror orelaterade skärmar på samma värden, och små ändringar sprider effekter över appen.

Globalt tillstånd passar bra för sådant som verkligen är tvärgående, som aktuell användarsession, app-omfattande feature-flaggor eller en delad notis-kö.

Lyft tillstånd upp—bara så långt det behövs

Ett vanligt mönster är att börja lokalt och “lyfta” tillstånd till närmaste gemensamma förälder endast när två syskon behöver koordinera.

Om bara en komponent behöver tillståndet, håll det där. Om flera komponenter behöver det, lyft det till den minsta delade ägaren. Om många avlägsna områden behöver det, då överväg globalt.

En enkel heuristik

Håll tillstånd nära där det används om inte delning krävs.

Det gör komponenter enklare att förstå, minskar oavsiktliga beroenden och gör framtida refaktorer mindre skrämmande eftersom färre delar av appen får mutera samma data.

Konkurrens, race och uppdateringar i fel ordning

Frontend-appar känns “en-trådade”, men användarinmatning, timers, animationer och nätverksförfrågningar kör alla oberoende. Det betyder att flera uppdateringar kan vara på gång samtidigt—och de slutförs inte nödvändigtvis i den ordning du startade dem.

När uppdateringar kolliderar

En vanlig kollision: två delar av UI:t uppdaterar samma tillstånd.

• Ett sökfält uppdaterar query vid varje tangenttryckning.
• En filter-dropdown uppdaterar query (eller samma resultatlista) när den ändras.

Var och en för sig är uppdateringen korrekt. Tillsammans kan de skriva över varandra beroende på timing. Ännu värre: du kan visa resultat för en tidigare fråga medan UI:t visar de nya filtren.

Race conditions: snabba användare, långsamma nätverk

Race conditions dyker upp när du skickar förfrågan A och snabbt efter det förfrågan B—men förfrågan A returnerar sist.

Exempel: användaren skriver “c”, “ca”, “cat”. Om “c”-förfrågan är långsam och “cat”-förfrågan snabb, kan UI:t kort visa “cat”-resultat och sen bli omskrivet av föråldrade “c”-resultat när det äldre svaret slutligen anländer.

Buggens natur är subtil eftersom allt “funkade”—bara i fel ordning.

Tekniker som minskar problem med fel ordning

Du vill i allmänhet ha en av dessa strategier:

1. Avbryt föregående förfrågan när en ny ersätter den (t.ex. med AbortController).
2. Ignorera föråldrade svar genom att kontrollera om svaret fortfarande matchar de senaste inputen.
3. Använd request IDs / sekvensnummer och acceptera bara det nyaste.

Ett enkelt request ID-tillyvägagångssätt:

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);
}

Optimistiska uppdateringar (och hur de går fel)

Optimistiska uppdateringar gör UI:t kännas omedelbart: du uppdaterar skärmen innan servern bekräftar. Men konkurrens kan bryta antaganden:

• Användaren klickar “Gilla” två gånger snabbt (gilla → ogilla), men förfrågningarna löser sig i fel ordning.
• Du minskar optimistiskt lagret, sedan misslyckas ett senare anrop och kräver rollback—men användaren har redan navigerat bort eller gjort fler ändringar.

För att hålla optimism säker behöver du vanligtvis en tydlig rekonsilieringsregel: spåra den väntande åtgärden, tillämpa serverresponses i ordning, och om du måste rollbacka, rollbacka till en känd checkpoint (inte “vad UI:t råkar se nu”).

Prestanda: när tillståndsändringar blir för dyra

Tillståndsuppdateringar är inte “gratis”. När tillstånd ändras måste appen lista ut vilka delar av skärmen som kan påverkas och sedan göra arbetet för att reflektera den nya verkligheten: räkna om värden, rendera om UI, köra formateringslogik och ibland hämta eller validera data igen. Om den kedjereaktionen är större än nödvändigt, känner användaren det som fördröjning, stutter eller knappar som verkar “tänka” innan de svarar.

Varför en liten ändring kan kännas stor

En enda växling kan av misstag trigga mycket extra arbete:

• Stora delar av UI:t renderas om trots att bara en liten del ändrades.
• Listor ritas om och mäts på nytt, vilket stammar scrollningen.
• Objekt och arrayer skapas om vid varje uppdatering (“deep churn”), så appen kan inte enkelt avgöra vad som verkligen skiljer.

Resultatet är inte bara tekniskt—det är upplevelsebaserat: skrivande känns fördröjt, animationer hakar upp sig och gränssnittet förlorar den “snabba” känsla som användare förväntar sig av välpolerade produkter.

Vanliga prestandafällor

En av de vanligaste orsakerna är att tillståndet är för brett: ett “stort hink”-objekt som håller mycket orelaterad information. Att uppdatera vilket fält som helst gör att hela hinken ser ny ut, så mer av UI:t vaknar än nödvändigt.

En annan fälla är att lagra beräknade värden i tillstånd och uppdatera dem manuellt. Det skapar ofta extra uppdateringar (och extra UI-arbete) bara för att hålla allt i synk.

Taktiker som håller UI:t snabbt

Dela upp tillstånd i mindre bitar. Håll orelaterade bekymmer separata så att en ändring i sökfältet inte refreschar en hel resultatsida.

Normalisera data. Istället för att lagra samma objekt på många ställen, lagra det en gång och referera till det. Detta minskar upprepade uppdateringar och förhindrar “change storms” där en ändring tvingar många kopior att skrivas om.

Memoisera avledda värden. Om ett värde kan beräknas från annat tillstånd (som filtrerade resultat), cache:a den beräkningen så den bara räknas om när inputarna faktiskt ändras.

Målet: färre stutter, färre överraskningar

God prestandamedveten tillståndshantering handlar mest om avgränsning: uppdateringar bör påverka minsta möjliga område, och dyrt arbete bör ske bara när det verkligen behövs. När det stämmer slutar användare märka ramverket och börjar lita på gränssnittet.

Debugga och testa tillstånd utan gissningar

Tillståndsbuggar känns ofta personliga: UI:t är “fel”, men du kan inte svara på den enklaste frågan—vem ändrade detta värde och när? Om ett nummer flippas, en banner försvinner eller en knapp inaktiveras, behöver du en tidslinje, inte en gissning.

Gör ändringar spårbara (inte mystiska)

Den snabbaste vägen till klarhet är ett förutsägbart uppdateringsflöde. Oavsett om du använder reducers, events eller en store, sikta på ett mönster där:

• Ändringar sker via ett litet antal väl namngivna actions (inte slumpmässiga mutationer)
• Varje action har en tydlig payload (setShippingMethod('express'), inte updateStuff)
• Du kan logga actions och resulterande tillståndsövergångar konsekvent

Tydlig action-logging förvandlar debug från “stirra på skärmen” till “följ kvittot”. Även enkla console logs (action-namn + nyckelfält) slår att försöka rekonstruera vad som hände från symptom.

Testa logiken där den är stabil

Försök inte testa varje omrendering. Testa istället de delar som ska bete sig som ren logik:

• Enhetstesta reducers / tillståndsuppdaterare: givet tidigare tillstånd + action, assert nästa tillstånd
• Enhetstesta selectors / avledda beräkningar: givet tillstånd, assert beräknat resultat
• Integrationstesta nyckelflöden: login → ladda data → redigera → spara → se bekräftelse

Denna mix fångar både “mattefel” och verkliga kopplingsproblem.

Lägg till lätt instrumentation för asynkrona buggar

Asynkrona problem gömmer sig i luckor. Lägg till minimal metadata som gör tidslinjer synliga:

• tidsstämplar på viktiga uppdateringar
• request IDs (koppla ID till actions och responses)

Då när ett sent svar skriver över ett nyare, kan du bevisa det omedelbart—och fixa det med förtroende.

Välja ett tillståndsangreppssätt (utan verktygskrig)

Att välja ett tillståndsverktyg är enklare när du ser det som ett resultat av designbeslut, inte startpunkten. Innan du jämför bibliotek, kartlägg dina tillståndsgränser: vad är rent lokalt för en komponent, vad behöver delas, och vad är egentligen “serverdata” som du hämtar och synkroniserar.

Urvalskriterier som spelar roll

Ett pragmatiskt sätt att avgöra är att titta på några begränsningar:

• Appens storlek och livslängd: ett litet internt verktyg kan förbli enkelt; en långlivad produkt gynnas av starkare konventioner.
• Teamets vanor: välj något teamet kan använda konsekvent (och granska tryggt).
• Asynkrona behov: tung hämtning, caching, paginering och mutationer förändrar bilden.
• Tillståndskomplexitet: flöden över sidor, undo/redo och flerstegsformulär kräver ofta mer struktur.

En övergripande jämförelse (utan ideologi)

• Context + hooks: bra för dependency injection och sällan uppdaterade delade värden (tema, auth-info). Det kan fungera för state, men frekventa uppdateringar kan bli högljudda utan extra mönster.
• Redux-liknande stores: starka konventioner, förutsägbara uppdateringar och bra verktyg. Bäst när du behöver en tydlig audit trail eller komplex samordning över funktioner.
• Atom-stores (finkornigt state): ergonomiskt för delat tillstånd utan att koppla ihop massor av reducers. Ofta enklare att skala inkrementellt.
• Query-cacher (server-state-verktyg): specialiserade på hämtning, caching, deduplering, bakgrundsrefetching och mutationer. De minskar en stor klass av “asynkron limkod”.

Undvik verktygs-först-tänkande

Om du börjar med “vi använder X överallt”, kommer du lagra fel saker på fel plats. Börja med ägande: vem uppdaterar detta värde, vem läser det och vad ska hända när det ändras.

Att kombinera verktyg är ofta bästa valet

Många appar fungerar bra med ett server-state-bibliotek för API-data plus en liten UI-state-lösning för klient-only-angelägenheter som modaler, filter eller utkast i formulär. Målet är tydlighet: varje typ av tillstånd bor där det är enklast att resonera om.

Var Koder.ai passar in

Om du itererar på tillståndsgränser och asynkrona flöden kan Koder.ai snabba upp ”prova, observera, förfina”-loopen. Eftersom det genererar React-frontends (och Go + PostgreSQL-backends) från chatt med ett agentbaserat arbetsflöde, kan du prototypa alternativa ägandesmodeller (lokalt vs globalt, server-cache vs UI-utkast) snabbt och sedan behålla den version som förblir förutsägbar.

Två praktiska funktioner hjälper när du experimenterar med tillstånd: Planning Mode (för att skissera tillståndsmodellen innan bygget) och snapshots + rollback (för att säkert testa refaktorer som “ta bort avlett tillstånd” eller “inför request IDs” utan att förlora en fungerande baseline).

En praktisk checklista för att göra tillstånd mindre smärtsamt

Tillstånd blir lättare när du behandlar det som ett designproblem: bestäm vem som äger det, vad det representerar och hur det förändras. Använd denna checklista när en komponent börjar kännas “mystisk”.

1) Förtydliga ägande och en enda källa för sanningen

Fråga: Vilken del av appen ansvarar för dessa data? Placera tillstånd så nära som möjligt där det används, och lyft bara upp det när flera delar verkligen behöver det.

• En ägare per tillståndsbit.
• Skicka data ner; skicka ändringar upp via callbacks/events.
• Om två platser kan uppdatera samma värde har du inte en källa för sanningen—du har en konflikt som väntar på att hända.

2) Undvik duplication och modellera avledda värden

Om du kan räkna ut något från annat tillstånd, spara det inte.

• Spara minimala inputs (t.ex. items, filterText).
• Beräkna outputs (t.ex. visibleItems) under render eller via memoization.

3) Gör asynkront tillstånd explicit (inte underförstått)

Asynkront arbete blir tydligare när du modellerar det direkt:

• Föredra en liten “request state”-form: status: 'idle' | 'loading' | 'success' | 'error', plus data och error.
• Behandla “loading” och “error” som förstaklass-tillstånd, inte utspridda booleaner.

4) Håll utkik efter vanliga antipatterns

• Kopiera props till state “ifall” (skapar drift).
• Globalisera allt (gör orelaterade skärmar ihopkopplade).
• Boolean-soppa (isLoading, isFetching, isSaving, hasLoaded, …) istället för en enda status.

5) Refaktorisera med små, säkra steg

• Dela upp blandat tillstånd: separera UI-angelägenheter (öppet/stängt, input-text) från serverdata.
• Ta bort lagrade avledda värden och räkna dem från den verkliga källan.
• Centralisera sidoeffekter (hämtning, prenumerationer) på ett ställe per feature.

Praktiska mål

Sikta på färre “hur hamnade det i detta tillstånd?”-buggar, ändringar som inte kräver att man rör fem filer, och en mental modell där du kan peka på en plats och säga: här bor sanningen.