Valet mellan React hooks och Redux handlar om omfattning, inte om kvalitet. Använd React hooks för tillstånd som hör hemma i en komponent, samt för mindre delade värden som tema eller språkinställningar. Vänd dig till Redux när flera orelaterade funktioner förlitar sig på samma data, när fler än fem utvecklare arbetar i kodbasen, eller när du behöver en spårbar historik över varje ändring. De flesta produktionsappar använder i slutändan båda, fast på olika nivåer.
Se tillstånd som vatten i en byggnad. Hooks är kranarna i varje rum, nära där vattnet används. Redux är huvudledningen, tryckventilerna och mätaren som talar om exakt vem som tappade upp ett bad klockan tre på natten.
Samma substans. Helt olika uppgifter. Det är hela argumentet, och allt nedan är uträkningen.
Arkitektur för tillståndshantering är ett av få val inom frontend som får kumulativ effekt. Väljer du för lite struktur får du betala i form av längre introduktionstid för nyanställda och buggar som ingen kan återskapa. Väljer du för mycket får du betala i form av boilerplate-kod som ingen bett om.
Det intressanta är asymmetrin. Att överarbeta en lösning kostar några bortkastade veckor, och det märks direkt. Att underarbeta den kostar kvartal av smygande hastighetsförlust, och det märker du först när teamet har vuxit förbi punkten där en omskrivning är billig.
Det här är alltså en fråga för CTO:n, förklädd till en preferens för utvecklare. Vi har ramat in varje tekniskt avsnitt nedan utifrån den leveransrisk det innebär, eftersom det är den delen som påverkar din roadmap.
React-hooks är sättet du hanterar tillstånd och livscykel i funktionskomponenter, utan klasser. De introducerades i React 16.8 och skapades för att minska komponenternas komplexitet genom att göra logik återanvändbar.
Den verkliga vinsten är anpassade hooks. Bryt ut beteenden som du använder på flera ställen och slipp skriva samma kod två gånger.
// 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;
}
Haken är att hooks inte ställer några krav på struktur. Var delat tillstånd ska ligga blir en bedömningsfråga för varje enskild utvecklare, och verktygen ger ingen vägledning. Det fungerar utmärkt med två utvecklare, men blir kostsamt med tio.
Redux är ett bibliotek för att hantera globalt applikationstillstånd. En lagringsplats, ett strukturerat sätt att ändra den, och verktyg som övervakar varje ändring i realtid.
Den officiella dokumentationen anger tre principer:
Redux levereras även med sina egna hooks, useSelector och useDispatch, så att funktionskomponenter kan läsa från lagringsplatsen utan klassbaserad koppling. (Detta är react-redux-bindningen, och ja, du behöver den: mer om det i FAQ:n.)
Vad ceremonin ger dig:
Kostnaden: installationstid, boilerplate-kod och en inlärningskurva för alla som är nya inför det. Redux Toolkit minskar alla tre avsevärt, och det är det officiellt rekommenderade sättet att skriva Redux på idag.
Redux är ett bibliotek för att hantera globalt applikationstillstånd. I detta bibliotek finns flera verktyg som hjälper oss utvecklare att hålla koll på applikationens tillstånd och även transformera det genom att ge användaren möjlighet att skicka åtgärder.
Reduxkan, enligt dokumentationen, beskrivas utifrån tre grundläggande principer:
Redux uppdaterade till och med biblioteket med sina anpassade hooks. Dessa kan användas för att integrera komponenter som använder React Hooks funktioner för att hämta data från store och skicka actions utan att behöva förlita sig på komponentklasser.
Nu när vi är lite mer bekanta med Redux och React Hooks ska vi titta på skillnaden mellan dem.
De flesta artiklar om detta ämne utgår från att du redan kan språket. Det antagandet är precis varför ämnet förblir otydligt, så här är vokabulären på vanlig svenska.
State är all data som ändras över tid och påverkar vad användaren ser. Ett formulärfält. En inloggad användare. En varukorg.
En reducer är en funktion som tar det nuvarande tillståndet och en åtgärd, och sedan returnerar ett nytt tillstånd utan att röra det ursprungliga. Den gör varje ändring explicit och spårbar.
En ren funktion ger alltid samma utdata för samma indata och ändrar ingenting utanför sig själv. Inga nätverksanrop, ingen skrivning till variabler på andra ställen. Reducers måste vara rena, eftersom det är det som gör tillståndsändringar reproducerbara och testbara.
Att skicka (eller dispatcha) en åtgärd innebär att beskriva en ändring som ett enkelt objekt istället för att bara utföra den. Du muterar inte varukorgen. Du skickar { type: 'basket/itemAdded', payload: item } och låter reducern räkna ut resultatet.
Provider och consumer är de två halvorna av Reacts Context API. Providern håller ett värde och erbjuder det till allt nedanför i trädet. Consumern är vilken komponent som helst som läser det.
En selector är en liten funktion som plockar ut en del av storen, som state => state.basket.total. Selector-baserad prenumeration innebär att en komponent bara ritas om när dess del ändras.
Blast radius är den uppsättning komponenter som en enskild tillståndsändring tvingar att ritas om. Liten är bra.
En thunk är en funktion som du skickar iväg istället för en vanlig action, så att du kan köra asynkront arbete (oftast ett API-anrop) innan du skickar iväg den riktiga.
RTK Query är lagret för datahämtning och cachning som ingår i Redux Toolkit. Det hanterar serverdata så att du slipper hantera den manuellt i din store.
Context skapades för värden som sällan ändras. Det saknar helt en väljarmekanism. När ett värde i en provider ändras, renderas därför alla underliggande konsumenter om, även de komponenter som inte ens använder den del som ändrades.
Låt oss återgå till VVS-liknelsen. Context är ett enda stort rör som försörjer hela byggnaden. Vrid på en kran på tredje våningen och hela huset skakar.
För en temaväxlare spelar det ingen roll. Men för en kontext som hanterar den aktuella användaren, en kundvagn, ett live-flöde med notiser och en filterpanel, är det en katastrof. Ett enda tangenttryck i filterfältet gör att hela notislistan renderas om.
Team upptäcker oftast detta tre månader före lansering, när alla tillfälliga lösningar har börjat hopa sig. Och det är dessa lösningar som är den verkliga kostnaden: att dela upp en kontext i sex, memoise-a provider-värden, och att kapsla in konsumenter i React.memo, samt att bygga om trädet för att minska skadeverkningarna.
Varje åtgärd är försvarbar var för sig. Tillsammans utgör de en skräddarsydd, odokumenterad tillståndshanterare som bara en enda utvecklare förstår, och som kostar mer att underhålla än det bibliotek man försökte undvika från början. Det är en välkänd väg mot teknisk skuld.
Redux undviker detta genom sin design. Tack vare selectors begränsas skadeverkningarna till det som komponenten faktiskt läser.
useReducer hör hemma i komponenter med komplex intern logik. Ett formulär i flera steg. En guide. En datatabell som hanterar sortering, filtrering och paginering. Där useState lämnar dig med fem ömsesidigt beroende setter-funktioner, ger en reducer dig en enda sammanhängande övergångsfunktion.
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 tar emot din reducer och det initiala tillståndet, och returnerar det aktuella tillståndet samt en dispatch -funktion. Skriv aldrig direkt till tillståndet. Skicka en action, alltid formad som ett objekt med en type (vad som hände) och en payload (datan som ändringen kräver).
Så kan useReducer ersätta Redux? På komponentnivå uppstår frågan aldrig riktigt, eftersom det helt enkelt är rätt verktyg för jobbet.
Om du däremot lyfter upp det till globalt tillstånd via context, får du det mesta av Redux struktur utan dess infrastruktur. Du kommer att märka att du bygger om väljarbaserade prenumerationer, middleware för asynkront arbete och felsökningsverktyg. Från grunden. En tisdag, mitt i en sprint som var tänkt att handla om produkten.
Det ombygget är inte gratis, och det finns inte med i någons tidsplan. Gränsdragningen handlar om omfattning, inte komplexitet.
Sanningen är att för de flesta nya projekt är den ärliga jämförelsen inte längre en ren tvåvägskamp. Zustand har blivit den självklara utmanaren, och att låtsas som något annat ger dig ett falskt val.
Zustand är en minimalistisk store. Du skapar ett tillstånd och använder det via en hook. Ingen provider, knappt någon boilerplate och, avgörande nog, väljarbaserade prenumerationer direkt från start – vilket är den enda sak som vanlig context inte kan erbjuda.
Enligt State of React 2025-undersökningen, är Redux och Redux Toolkit fortfarande de mest spridda lösningarna för tillståndshantering, men Zustand vinner mark snabbt och leder kategorin när det gäller användarnöjdhet – så pass mycket att undersökningens författare kallar det för kategoriledare. Samma undersökning noterar att en stor andel av respondenterna inte använder något bibliotek för tillståndshantering alls, eftersom useState och useContext fungerar alldeles utmärkt för det de bygger.
Se det som ett beslut, inte en trend:
En viktig brasklapp, och det är den stora. Mycket av det som team vänder sig till en store för att lösa är server-state, det vill säga cachade API-svar. Det hör hemma i TanStack Query eller SWR, inte i någon klient-store. Sortera ut det först, så blir det återstående beslutet oftast mycket enklare.
De flesta jämförelser rycker på axlarna och säger "det beror på". Här är vad vi faktiskt använder när vi granskar eller påbörjar en React-kodbas. Två axlar: applikationskomplexitet, vilket innebär hur många funktioner som delar samma data, och teamstorlek, vilket innebär hur många utvecklare som ändrar den datan.
Samma fyra regler, i textform, eftersom bilder fungerar dåligt:
Och här är det som förvånar folk. Teamstorlek, inte applikationskomplexitet, är den starkare indikatorn. En genuint komplex app som underhålls av två utvecklare som delar en mental modell körs utmärkt med hooks. En bara småkrånglig app som underhålls av nio utvecklare i tre team gör det inte, och inte för att koden inte kan uttrycka det. Utan för att nio personer inte kan hålla en odokumenterad konvention i huvudet samtidigt.
Föreställ dig en produkt som växer från två utvecklare till tio under ett par kvartal.
Vid två är hooks-only optimalt. Delat tillstånd ligger i tre kontexter, konventionerna är oskrivna eftersom båda utvecklarna skapade dem, och leveranstakten är hög. Redux skulle bara vara en belastning.
Vid tio vänder sig samma arkitektur mot dig. Introduktionstiden sträcker sig från dagar till veckor, eftersom det inte finns något kanoniskt svar på "var bor den här datan", bara prejudikat.
Två utvecklare löser samma problem med omrenderingar oberoende av varandra, på inkompatibla sätt.
Att felsöka en incident i produktion innebär att återskapa tillståndet genom att läsa kod, eftersom det saknas en händelselogg. Utvecklingstakten sjunker, utan att det beror på ett enskilt beslut.
Avvägningen handlar alltså inte om boilerplate kontra elegans. Det handlar om en kostnad som betalas i förskott kontra en kostnad som betalas i stor skala, med ränta.
Misslyckandet går åt båda hållen, förstås. Att införa Redux för en MVP med två utvecklare är en reell kostnad utan avkastning. Det du ska hålla utkik efter är inte antalet kodrader. Det är dagen då ditt team inte längre kan svara på "varför renderades detta om" utan att behöva öppna en debugger.
Den omvända migreringen blir allt vanligare, oftast när det visar sig att Redux-storen mest består av cachad serverdata i förklädnad.
useReducer, eller en enda Zustand-store.
Team upptäcker ofta att steg 2 löser hela diskussionen på egen hand. Problemet var aldrig Redux. Problemet var att använda en hanterare för klientstate som en nätverkscache.
Vill du se helheten? Vår guide till tillståndshantering i React täcker hela landskapet, och våra artiklar om att välja teknikstack och asynkrona JavaScript-mönster täcker områdena runtomkring.
Redux är ett bibliotek med öppen källkod för att hantera globalt applikationstillstånd i JavaScript-appar, oftast React-appar. Det håller delat tillstånd i ett enda objekt som kallas store, och ändrar det endast genom skickade händelser (actions) som hanteras av rena funktioner som kallas reducers. Namnet avslöjar innebörden: tillståndsändringar reduceras till ett förutsägbart flöde.
Använd hooks för lokalt komponenttillstånd och mindre delade värden som tema eller språkinställningar. Välj Redux när flera funktioner är beroende av samma data, när fler än fem utvecklare arbetar i kodbasen, eller när du behöver en logg över tillståndsändringar. I de flesta produktionsapplikationer är svaret båda, på olika nivåer.
Börja med hooks. Gå över till Zustand när delat tillstånd växer ur context och du börjar kämpa med onödiga omrenderingar. Byt till Redux Toolkit när teamet växer till ungefär fem utvecklare, eller när domänen kräver spårbara tillståndsändringar. Zustand leder just nu kategorin när det gäller utvecklarnöjdhet, medan Redux förblir den mest använda lösningen.
Ja. Men inte som det självklara förstahandsvalet. Undersökningen State of React 2025 visar att Redux och Redux Toolkit fortfarande är de mest spridda lösningarna, och de förblir det starkaste alternativet för stora team och reglerade branscher. För ett nytt projekt med ett litet team är Zustand, eller inget bibliotek alls, numera den vanligare startpunkten.
Använd useReducer när komplex tillståndshantering är begränsad till en enskild komponent eller en tät grupp: ett formulär i flera steg, en guide eller ett datagrid. Använd Redux när tillståndet delas av orelaterade delar av applikationen. Det är omfattningen, inte komplexiteten, som avgör.
För små och medelstora applikationer, ja. useContext och useReducer återskapar tillsammans det mesta av vad Redux gör. Det de inte kan ersätta utan omfattande anpassningar är väljarbaserad kontroll av omrenderingar, middleware för asynkron logik och felsökningsupplevelsen i DevTools. Vilket är precis vad stora team förlitar sig på.
Redux är ramverksoberoende, en tillståndsbehållare som fungerar med vilket UI-lager som helst. react-redux är den officiella bryggan som kopplar samman det med React och ger dig useSelector och useDispatch -hooks. Du behöver båda för att använda Redux i en React-applikation.
Det kan det göra. Context saknar en väljarmekanism, så när en providers värde ändras renderas alla konsumenter under den om, även de som aldrig använde den ändrade delen. Det fungerar bra för värden som sällan ändras, men blir problematiskt för allt som ändras ofta eller används på många ställen.
Så är Redux dött? Nej, självklart inte. React hooks och Redux är komplement, inte rivaler. Hooks hanterar komponenttillstånd och delbar logik, Redux hanterar globalt tillstånd, skickade händelser och den observerbarhet som stora team är beroende av, och Zustand har nu hittat sin naturliga plats däremellan.
Tillbaka till byggnadsliknelsen en sista gång. Du väljer inte mellan kranen och huvudledningen. Du räknar ut hur många rum som behöver vatten, hur många som vrider på kranarna, och drar rören därefter.
Var på komplexitetsskalan befinner sig din applikation, var på storleksskalan befinner sig ditt team, och var kommer båda att befinna sig om tolv månader? Arkitektera för det. Inte för idag.
Om du bygger eller skalar en React-applikation och vill ha ett rakt svar gällande din tillståndsarkitektur innan den låser sig, så genomför vårt team tekniska revisioner som gör precis det.
Javascript-utvecklare sedan 2016 har jag byggt mobilappar med Ionic och React Native. Gitarrspelare och matlagningsälskare.
People who read this post, also found these interesting:
.webp)
