Valget mellem React hooks og Redux handler om omfang, ikke om kvalitet. Brug React hooks til tilstand, der hører til i en komponent, samt mindre delte værdier som tema eller sprogindstillinger. Vælg Redux, når flere uafhængige funktioner skal bruge de samme data, når mere end fem udviklere arbejder på kodebasen, eller når du har brug for en sporbar log over alle ændringer. De fleste produktionsklare apps ender med at bruge begge dele på forskellige niveauer.
Betragt tilstand som vand i en bygning. Hooks er vandhanerne i hvert rum, tæt på hvor vandet skal bruges. Redux er hovedforsyningen, trykventilerne og måleren, der fortæller dig præcis, hvem der tændte for badet klokken tre om natten.
Samme substans. Meget forskellige opgaver. Det er hele argumentet, og alt nedenfor er uddybningen.
Arkitektur for tilstandshåndtering er et af de få valg inden for frontend, der akkumulerer over tid. Vælger du for lidt struktur, betaler du prisen i form af længere onboarding og fejl, som ingen kan genskabe. Vælger du for meget, betaler du prisen i form af boilerplate-kode, som ingen har bedt om.
Det interessante er asymmetrien. Over-engineering koster dig et par spildte uger, og det mærker du med det samme. Under-engineering koster dig kvartaler med snigende hastighedstab, og det opdager du først, når dit team er vokset til et punkt, hvor en omskrivning ikke længere er en billig løsning.
Så dette er i virkeligheden et CTO-spørgsmål forklædt som en udviklerpræference. Vi har knyttet leveringsrisikoen til hvert teknisk afsnit nedenfor, fordi det er den del, der påvirker din roadmap.
React hooks er måden, du håndterer state og lifecycle i funktionskomponenter uden brug af klasser. De blev introduceret i React 16.8 for at reducere kompleksiteten i komponenter ved at gøre logik genanvendelig.
Den virkelige fordel er custom hooks. Udtræk adfærd, som du bruger flere steder, og undgå at skrive den samme kode to gange.
// useDebouncedValue.js
import { useEffect, useState } from 'react';
export function useDebouncedValue(value, delay = 300) {
const [debounced, setDebounced] = useState(value);
useEffect(() => {
const timer = setTimeout(() => setDebounced(value), delay);
return () => clearTimeout(timer);
}, [value, delay]);
return debounced;
}
Udfordringen er, at hooks ikke pålægger nogen faste konventioner. Hvor delt state skal placeres, bliver en vurderingssag for den enkelte udvikler, og værktøjerne hjælper ikke med at dokumentere det. Det fungerer fint med to udviklere, men bliver dyrt med ti.
Redux er et bibliotek til håndtering af global applikationstilstand. Ét lager, en disciplineret måde at ændre det på, og værktøjer, der overvåger hver eneste ændring, efterhånden som den sker.
Den officielle dokumentation angiver tre principper:
Redux leveres også med sine egne hooks, useSelector og useDispatch, så funktionskomponenter kan læse fra lageret uden klassebaseret opsætning. (Dette er react-redux-bindingen, og ja, du får brug for den: læs mere om det i vores FAQ.)
Hvad du får ud af ceremonien:
Prisen: opsætningstid, boilerplate og en indlæringskurve for alle, der er nye til det. Redux Toolkit skærer betydeligt ned på alle tre, og det er den officielt anbefalede måde at skrive Redux på i dag.
Redux er et bibliotek til håndtering af global applikationstilstand. I dette bibliotek finder vi adskillige værktøjer, der hjælper os udviklere med at holde styr på applikationens tilstand og transformere den ved at give brugeren mulighed for at udsende handlinger.
Reduxkan, som dokumentationen beskriver, defineres ud fra tre grundlæggende principper:
Redux opdaterede endda biblioteket med sine custom hooks. Disse kan bruges til at integrere de komponenter, der benytter React Hooks funktioner til at hente data fra storen og afsende handlinger uden at være afhængig af komponentklasser.
Nu hvor vi er lidt mere fortrolige med Redux og React Hooks , lad os se på forskellen mellem dem.
De fleste artikler om dette emne antager, at du allerede kender sproget. Netop den antagelse er grunden til, at emnet forbliver uklart, så her er ordlisten forklaret i et letforståeligt sprog.
State er alle data, der ændrer sig over tid og påvirker, hvad brugeren ser. Et inputfelt. En bruger, der er logget ind. En indkøbskurv.
En reducer er en funktion, der tager den nuværende state og en handling, og derefter returnerer en ny state uden at ændre den oprindelige. Den gør enhver ændring eksplicit og sporbar.
En ren funktion (pure function) giver altid det samme output for det samme input og ændrer intet uden for sig selv. Ingen netværkskald, ingen skrivning til variabler andre steder. Reducere skal være rene, fordi det er det, der gør tilstandsændringer reproducerbare og testbare.
At udsende (eller dispatch) en handling betyder at beskrive en ændring som et simpelt objekt i stedet for bare at udføre den. Du ændrer ikke direkte i indkøbskurven. Du disatcher { type: 'basket/itemAdded', payload: item } og lader reduceren finde frem til resultatet.
Provider og consumer er de to halvdele af Reacts Context API. Provideren indeholder en værdi og tilbyder den til alt, der ligger under den i hierarkiet. Consumeren er enhver komponent, der læser værdien.
En selector er en lille funktion, der henter en bestemt del ud af storen, som f.eks. state => state.basket.total. Selector-baseret abonnement betyder, at en komponent kun genindlæses (re-render), når dens specifikke del ændrer sig.
Blast radius er det sæt af komponenter, som en enkelt tilstandsændring tvinger til at genindlæse. Lille er godt.
En thunk er en funktion, du dispatcher i stedet for en almindelig action, så du kan udføre asynkront arbejde (typisk et API-kald), før du dispatcher den egentlige action.
RTK Query er laget til datahentning og caching, der følger med Redux Toolkit. Det håndterer serverdata, så du slipper for manuelt at skulle styre data i dit store.
Context er bygget til værdier, der sjældent ændrer sig. Den har ingen form for selektormekanisme. Så når en providers værdi ændres, genindlæses alle forbrugere under den, inklusive de komponenter, der aldrig har rørt ved den del, der blev ændret.
Tilbage til VVS-analogien. Context er ét stort rør, der forsyner hele bygningen. Åbner du for en hane på tredje sal, ryster hele bygningen.
Til en skift af tema betyder det ikke noget. Men for en context, der indeholder den aktuelle bruger, en indkøbskurv, et live-feed med notifikationer og et filterpanel, er det en katastrofe. Ét tastetryk i filterfeltet genindlæser hele notifikationslisten.
Teams opdager typisk dette tre måneder før lancering, når de midlertidige løsninger er hobet sig op. Og det er disse løsninger, der er den egentlige omkostning: at opdele én context i seks, memoise provider-værdier og pakke forbrugere ind i React.memo, samt at omstrukturere træet for at mindske skadesomfanget.
Hver for sig kan de retfærdiggøres. Samlet set udgør de en skræddersyet, udokumenteret state-manager, som kun én programmør forstår, og den er dyrere at vedligeholde end det bibliotek, man forsøgte at undgå. Det er en sikker vej til teknisk gæld.
Redux undgår dette ved design. Selektorer betyder, at skadesomfanget defineres af, hvad en komponent rent faktisk læser.
useReducer hører hjemme i komponenter med kompleks intern logik. En formular i flere trin. En guide. Et datagitter, der håndterer sortering, filtrering og paginering. Hvor useState efterlader dig med fem indbyrdes afhængige settere, giver én reducer dig en enkelt, sammenhængende transitionsfunktion.
const initialState = { status: 'idle', items: [], error: null };
function feedReducer(state, action) {
switch (action.type) {
case 'FETCH_STARTED':
return { ...state, status: 'loading', error: null };
case 'FETCH_SUCCEEDED':
return { status: 'ready', items: action.payload, error: null };
case 'FETCH_FAILED':
return { ...state, status: 'error', error: action.payload };
default:
return state;
}
}
const [state, dispatch] = useReducer(feedReducer, initialState);
Den tager reduceren og den oprindelige tilstand og returnerer den aktuelle tilstand samt en dispatch funktion. Skriv aldrig direkte til tilstanden. Send en handling (dispatch), der altid er formet som et objekt med en type (hvad der skete) og en payload (de data, ændringen kræver).
Så kan useReducer erstatte Redux? På komponentniveau opstår spørgsmålet aldrig rigtigt, fordi det ganske enkelt er det rette værktøj.
Hvis du derimod promoverer det til global tilstand via context, får du det meste af Redux' struktur uden nogen af dens infrastruktur. Du vil ende med at skulle genopbygge selector-baserede abonnementer, middleware til asynkront arbejde og debugging-værktøjer. Fra bunden. På en tirsdag, midt i et sprint, der skulle have handlet om produktet.
Den genopbygning er ikke gratis, og den står ikke på nogens roadmap. Skillelinjen er scope, ikke kompleksitet.
Sandheden er, at for de fleste nye projekter er den ærlige sammenligning ikke længere en direkte duel. Zustand er blevet den foretrukne udfordrer, og at lade som om andet giver dig et falsk valg.
Zustand er et minimalistisk store. Du opretter noget state og bruger det via en hook. Ingen provider, stort set ingen boilerplate og, vigtigst af alt, selector-baserede abonnementer direkte ud af boksen, hvilket er den ene ting, almindelig context ikke kan give dig.
Ifølge State of React 2025-undersøgelsen, er Redux og Redux Toolkit stadig de mest udbredte løsninger til state management, men Zustand vinder hurtigt frem og fører kategorien inden for brugertilfredshed – i en grad så undersøgelsens forfattere kalder det kategorilederen. Samme undersøgelse bemærker, at en stor andel af respondenterne slet ikke bruger et state management-bibliotek, fordi useState og useContext fungerer helt fint til det, de bygger.
Se det som en beslutning, ikke en trend:
Der er dog ét væsentligt forbehold. Meget af det, som teams forsøger at løse ved hjælp af et store, er server state, altså cachede API-svar. Det hører hjemme i TanStack Query eller SWR, ikke i et client store. Få styr på det først, så bliver den resterende beslutning oftest meget lettere.
De fleste sammenligninger trækker på skuldrene og siger "det kommer an på". Her er, hvad vi rent faktisk bruger, når vi auditerer eller starter en React-kodebase. To akser: applikationskompleksitet, hvilket betyder, hvor mange funktioner der deler de samme data, og teamstørrelse, hvilket betyder, hvor mange udviklere der ændrer disse data.
De samme fire regler i tekstform, da billeder ikke altid fungerer optimalt:
Og her er den del, der overrasker folk. Teamstørrelse, ikke applikationskompleksitet, er den stærkeste indikator. En oprigtigt kompleks app, der vedligeholdes af to udviklere, som deler en mental model, kører fremragende med hooks. En blot småirriterende app, der vedligeholdes af ni udviklere fordelt på tre teams, gør ikke – og det er ikke, fordi koden ikke kan udtrykke det. Det er, fordi ni mennesker ikke kan have en udokumenteret konvention i hovedet på samme tid.
Forestil dig et produkt, der vokser fra to til ti udviklere over et par kvartaler.
Ved to udviklere er hooks-only optimalt. Delt state ligger i tre contexts, konventionerne er uskrevne, fordi begge udviklere har skrevet dem, og leveringstiden er kort. Redux ville være en unødig belastning.
Ved ti udviklere vender den samme arkitektur sig mod dig. Onboarding strækker sig fra dage til uger, fordi der ikke findes et kanonisk svar på "hvor bor disse data", kun præcedens.
To ingeniører løser det samme re-render-problem uafhængigt af hinanden på måder, der ikke er kompatible.
At debugge en hændelse i produktionen betyder, at man skal rekonstruere tilstanden ved at læse koden, fordi der ikke findes nogen handlingslog. Hastigheden falder, og det skyldes ikke én enkelt beslutning.
Så afvejningen handler ikke om boilerplate versus elegance. Det handler om omkostninger betalt på forhånd versus omkostninger betalt i stor skala, med renter.
Fejlen går begge veje, forstås. At indføre Redux til et MVP med to ingeniører er en reel omkostning uden afkast. Det signal, du skal holde øje med, er ikke antallet af kodelinjer. Det er den dag, hvor dit team ikke længere kan svare på, "hvorfor skete denne re-render", uden at åbne en debugger.
Den omvendte migrering bliver mere og mere almindelig, typisk når det viser sig, at Redux-storen mest af alt består af cachede serverdata i forklædning.
useReducereller én enkelt Zustand-store.
Teams oplever ofte, at trin 2 i sig selv løser hele diskussionen. Problemet var aldrig Redux. Problemet var at bruge en klient-state-manager som netværkscache.
Vil du have det store overblik? Vores guide til React state management dækker hele landskabet, og vores artikler om valg af tech stack og asynkrone JavaScript-mønstre dækker de omkringliggende emner.
Redux er et open-source-bibliotek til håndtering af global applikationstilstand i JavaScript-apps, oftest React-baserede. Det gemmer delt tilstand i et enkelt objekt kaldet storen, og ændrer den kun via dispatched handlinger, der håndteres af rene funktioner kaldet reducere. Navnet afslører pointen: tilstandsændringer bliver reduceret til ét forudsigeligt flow.
Brug hooks til lokal komponenttilstand og små delte værdier som tema eller sprogindstillinger. Vælg Redux, når flere funktioner afhænger af de samme data, når mere end fem udviklere arbejder på kodebasen, eller når du har brug for en log over tilstandsændringer. I de fleste produktionsapplikationer er svaret begge dele, på forskellige niveauer.
Start med hooks. Skift til Zustand, når delt tilstand vokser ud over context, og du begynder at kæmpe med unødvendige re-renders. Skift til Redux Toolkit, når teamet overstiger cirka fem udviklere, eller når domænet kræver sporbare tilstandsændringer. Zustand fører i øjeblikket kategorien inden for udviklertilfredshed, mens Redux forbliver den mest udbredte løsning.
Ja. Bare ikke som det automatiske standardvalg. State of React 2025-undersøgelsen viser, at Redux og Redux Toolkit stadig er de mest udbredte løsninger, og de forbliver det stærkeste valg til store teams og regulerede domæner. Til et nyt projekt med et lille team er Zustand, eller slet intet bibliotek, nu det mest almindelige udgangspunkt.
Brug useReducer når kompleks tilstand er begrænset til én komponent eller en tæt gruppe: en formular med flere trin, en guide eller et datagitter. Brug Redux, når tilstanden skal deles på tværs af uafhængige dele af applikationen. Det er rækkevidden, ikke kompleksiteten, der er afgørende.
Til små og mellemstore applikationer, ja. useContext og useReducer kan tilsammen genskabe det meste af det, Redux gør. Det, de ikke kan erstatte uden omfattende tilpasning, er selector-baseret styring af re-rendering, middleware til asynkron logik og debugging-oplevelsen i DevTools. Og det er netop det, store teams læner sig op ad.
Redux er framework-agnostisk, en state-container der fungerer med ethvert UI-lag. react-redux er den officielle binding, der forbinder det med React og giver dig useSelector og useDispatch hooks. Du skal bruge begge dele for at benytte Redux i en React-applikation.
Det kan det. Context har ingen indbygget selektormekanisme, så når en providers værdi ændres, genindlæses alle forbrugere under den – også dem, der aldrig har brugt den del, der blev ændret. Det fungerer fint til værdier, der sjældent ændrer sig, men det er problematisk for alt, der ændrer sig ofte eller bruges mange steder.
Så er Redux færdig? Nej, selvfølgelig ikke. React hooks og Redux er komplementære, ikke rivaler. Hooks håndterer komponenttilstand og delbar logik, Redux håndterer global tilstand, dispatched actions og den observerbarhed, som store teams er afhængige af, og Zustand placerer sig nu bekvemt midt imellem dem.
Tilbage til bygningen en sidste gang. Du vælger ikke mellem vandhanen og hovedledningen. Du finder ud af, hvor mange rum der har brug for vand, hvor mange mennesker der åbner for vandhanerne, og så installerer du VVS derefter.
Hvor befinder din applikation sig på kompleksitetsaksen, hvor befinder dit team sig på størrelsesaksen, og hvor vil de begge befinde sig om tolv måneder? Arkitektér efter det. Ikke efter i dag.
Hvis du bygger eller skalerer en React-applikation og ønsker et klart svar på din tilstandsarkitektur, før den låser sig fast, så udfører vores team tekniske audits der gør netop det.
Javascript-udvikler siden 2016 har jeg bygget mobile apps ved hjælp af Ionic og React Native. Guitarist og madlavningselsker.
People who read this post, also found these interesting:
.webp)
