Zustand vs Redux Toolkit nel 2026: quale state manager React scegliere?

Zustand vs Redux Toolkit è la decisione sulla gestione dello stato che la maggior parte dei team React si trova ad affrontare nel 2026, e la risposta corretta dipende da compromessi che vanno ben oltre le dimensioni del bundle. Entrambe le librerie gestiscono lo stato globale, ma partono da filosofie opposte: Zustand 5 predilige un'API minimale, orientata agli hook e con quasi zero boilerplate, mentre Redux Toolkit 2.x porta struttura, DevTools con time-travel e RTK Query per il recupero dei dati. Questo confronto analizza in dettaglio la configurazione, la gestione dell'asincronia, le prestazioni e i segnali che i responsabili delle assunzioni cercano durante i colloqui.

Zustand vs Redux Toolkit: le differenze principali in sintesi

Zustand è una libreria di stato non opinionata costruita sopra useSyncExternalStore di React, che espone un'unica funzione create la quale restituisce un hook. Redux Toolkit è il modo ufficiale e completo di scrivere Redux: avvolge il core di Redux con createSlice, reducer basati su Immer, uno store preconfigurato e un livello opzionale per il recupero dei dati. La tabella seguente riassume dove si colloca ciascuno dei due.

| Criterio | Zustand 5 | Redux Toolkit 2.x | |-----------|-----------|-------------------| | Dimensione approssimativa del bundle (gzip) | ~1 KB core | ~14 KB con React-Redux | | Boilerplate | Minimo, un file per store | Slice, configurazione store, provider | | Curva di apprendimento | Bassa | Moderata | | Async / recupero dati integrato | Azioni manuali | RTK Query incluso | | DevTools | Redux DevTools tramite middleware | Di prima classe, con time-travel | | Provider richiesto | No | Sì (<Provider>) | | Ideale per | App piccole e medie, store mirati | App grandi, flussi complessi, team numerosi |

La differenza principale è di filosofia. Zustand assume che lo store sia semplicemente un hook e resta in disparte. Redux Toolkit assume che un'applicazione tragga beneficio da una struttura imposta, da un'unica fonte di verità e da un flusso azione-reducer prevedibile che scala su decine di contributori.

Configurare uno store in Zustand 5

Uno store Zustand è una singola chiamata di funzione. Non ci sono provider, costanti per le azioni, né istruzioni switch dentro un reducer. Lo stato e le funzioni che lo aggiornano convivono in un unico oggetto.

import { create } from 'zustand'

interface CartState {
  items: string[]
  addItem: (id: string) => void
  clear: () => void
}

// create returns a hook usable anywhere in the component tree
export const useCartStore = create<CartState>((set) => ({
  items: [],
  // set merges the returned object into current state
  addItem: (id) => set((state) => ({ items: [...state.items, id] })),
  clear: () => set({ items: [] }),
}))

Quel singolo file è l'intero store. Non serve alcun componente di wrapping alla radice dell'app, ed è in parte per questo che Zustand si sposa naturalmente con i React Server Components: solo i componenti foglia che consumano lo store portano "use client".

Configurare uno store Redux Toolkit 2.x

Redux Toolkit distribuisce la stessa funzionalità tra una slice e una configurazione dello store. La slice definisce lo stato più i reducer, e Immer permette di scrivere i reducer come se lo stato fosse mutabile, producendo però un aggiornamento immutabile dietro le quinte.

import { createSlice, type PayloadAction } from '@reduxjs/toolkit'

interface CartState {
  items: string[]
}

const initialState: CartState = { items: [] }

const cartSlice = createSlice({
  name: 'cart',
  initialState,
  reducers: {
    // Immer makes this "mutation" produce a safe immutable update
    addItem: (state, action: PayloadAction<string>) => {
      state.items.push(action.payload)
    },
    clear: (state) => {
      state.items = []
    },
  },
})

export const { addItem, clear } = cartSlice.actions
export default cartSlice.reducer

Lo store combina poi ogni reducer delle slice ed esporta helper tipizzati da usare in tutta l'app.

import { configureStore } from '@reduxjs/toolkit'
import cartReducer from './cartSlice'

export const store = configureStore({
  reducer: { cart: cartReducer },
})

// Inferred types keep selectors and dispatch fully typed
export type RootState = ReturnType<typeof store.getState>
export type AppDispatch = typeof store.dispatch

Redux Toolkit 2.0 include inoltre combineSlices per il caricamento lazy dei reducer a runtime e abilita di default l'enhancer di auto-batching, così gli store di grandi dimensioni restano performanti senza tuning manuale.

Leggere e aggiornare lo stato nei componenti

Entrambe le librerie espongono un pattern a selettori, ed è qui che l'ergonomia quotidiana diverge. Zustand legge lo stato direttamente dal proprio hook e ri-renderizza un componente solo quando cambia la porzione selezionata.

'use client'

import { useCartStore } from '@/stores/useCartStore'

export function CartBadge() {
  // Selecting a narrow value avoids unnecessary re-renders
  const count = useCartStore((state) => state.items.length)
  return <span>{count}</span>
}

Redux Toolkit raggiunge lo stesso risultato tramite useSelector, ma l'albero dei componenti deve essere avvolto in un <Provider> alla radice, e gli aggiornamenti vengono dispatchati come azioni anziché chiamati direttamente.

'use client'

import { useSelector } from 'react-redux'
import type { RootState } from '@/store'

export function CartBadge() {
  const count = useSelector((state: RootState) => state.cart.items.length)
  return <span>{count}</span>
}

Il compromesso è evidente. Zustand richiede meno parti in movimento, mentre Redux Toolkit aggiunge un provider e un confine di azione esplicito che ripaga quando molti team toccano lo stesso stato e hanno bisogno di una cronologia tracciabile degli aggiornamenti. Per un'analisi più approfondita di come la granularità dei selettori influisca sul rendering, il modulo ottimizzazione delle prestazioni React tratta nel dettaglio la memoizzazione e il controllo dei ri-render.

Recupero dati asincrono: RTK Query vs azioni Zustand

Il recupero dei dati è l'ambito in cui Redux Toolkit prende il sopravvento per le app complesse. RTK Query, incluso in @reduxjs/toolkit, genera hook con caching, deduplicazione e refetching automatico a partire da una singola definizione di endpoint.

import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react'

interface Product { id: string; name: string }

export const api = createApi({
  reducerPath: 'api',
  baseQuery: fetchBaseQuery({ baseUrl: '/api' }),
  endpoints: (build) => ({
    getProducts: build.query<Product[], void>({
      query: () => 'products',
    }),
  }),
})

// The hook is generated from the endpoint name
export const { useGetProductsQuery } = api

L'hook generato gestisce loading, error e dati in cache con zero codice aggiuntivo, come documentato nella panoramica di RTK Query. Zustand adotta un approccio manuale: la logica asincrona vive in un'azione dello store, e caching o deduplicazione sono responsabilità dello sviluppatore.

import { create } from 'zustand'

interface Product { id: string; name: string }

interface ProductState {
  products: Product[]
  loading: boolean
  fetchProducts: () => Promise<void>
}

export const useProductStore = create<ProductState>((set) => ({
  products: [],
  loading: false,
  fetchProducts: async () => {
    set({ loading: true })
    const res = await fetch('/api/products')
    set({ products: await res.json(), loading: false })
  },
}))

In pratica, la maggior parte delle app Zustand nel 2026 delega lo stato del server a TanStack Query e mantiene Zustand per lo stato UI puramente client. Redux Toolkit consolida entrambe le esigenze all'interno di un unico store, il che è più semplice da ragionare in codebase di grandi dimensioni ma più pesante da adottare in quelle piccole.

Persistenza dello stato e idratazione SSR in Next.js

Lo stato che sopravvive a un ricaricamento della pagina è importante per carrelli, scelte di tema e token di autenticazione. Zustand gestisce la persistenza con un singolo wrapper middleware che scrive su localStorage e reidrata al mount.

import { create } from 'zustand'
import { persist } from 'zustand/middleware'

interface ThemeState {
  theme: 'light' | 'dark'
  toggle: () => void
}

export const useThemeStore = create<ThemeState>()(
  persist(
    (set) => ({
      theme: 'light',
      toggle: () =>
        set((state) => ({ theme: state.theme === 'light' ? 'dark' : 'light' })),
    }),
    { name: 'theme-storage' }, // localStorage key
  ),
)

Redux Toolkit ottiene lo stesso risultato tramite il pacchetto separato redux-persist o un listener personalizzato, il che aggiunge configurazione ma si integra con la timeline dello store esistente. Nel Next.js App Router, entrambe le librerie richiedono attenzione per evitare disallineamenti di idratazione: lo stato client persistito non dovrebbe pilotare il primo render lato server. La soluzione comune consiste nel leggere i valori persistiti solo dopo il mount, mantenendo identico l'output di server e client nel passaggio iniziale.

DevTools, middleware e maturità dell'ecosistema

Redux Toolkit eredita la matura esperienza dei Redux DevTools: debugging con time-travel, replay delle azioni e una timeline completa dello stato pronta all'uso. Zustand si connette agli stessi Redux DevTools tramite il proprio middleware devtools, ma l'integrazione è più leggera e non traccia un log formale delle azioni per impostazione predefinita. Il sistema di middleware di Zustand copre comunque le esigenze più comuni, tra cui persist per il local storage, immer per aggiornamenti in stile mutabile e subscribeWithSelector per sottoscrizioni a grana fine. L'elenco completo dei middleware si trova nel repository di Zustand.

Per i team già investiti nell'ecosistema Redux, il tooling di RTK, gli entity adapter e il listener middleware rappresentano anni di consolidamento in produzione. Per i progetti greenfield, la superficie più ridotta di Zustand significa meno da imparare e meno da mantenere.

Domande da colloquio su Redux Toolkit da aspettarsi

La gestione dello stato è un argomento frequente nei colloqui, e un colloquio su Redux Toolkit di solito indaga sia il perché sia il come. Tra le domande comuni:

• Perché Redux Toolkit raccomanda createSlice rispetto a tipi di azione e reducer scritti a mano?
• In che modo Immer permette ai reducer di apparire come se mutassero lo stato pur rimanendo immutabili?
• Quale problema risolve RTK Query che il semplice fetching con useEffect non risolve?
• Quando un progetto dovrebbe scegliere Zustand invece di Redux Toolkit, e quali sono i rischi di ciascuna scelta?
• In cosa differisce configureStore dal legacy createStore, e perché è importante?

Saper spiegare i compromessi, non solo la sintassi, è ciò che distingue una risposta solida da una imparata a memoria. Il modulo gestione dello stato con Zustand offre esercitazioni mirate su entrambe le librerie, e la guida sui pattern e ottimizzazioni avanzate degli hook React collega questi concetti alla progettazione reale dei componenti.

Quale state manager React scegliere nel 2026

Non esiste un vincitore universale, solo la scelta più adatta al progetto. La decisione si riduce alla scala, alle dimensioni del team e a quanto stato del server l'app deve gestire.

| Situazione | Scelta consigliata | |-----------|--------------------| | App piccola, pochi sviluppatori, prevalentemente stato UI | Zustand | | App grande, molti contributori, flussi complessi | Redux Toolkit | | Stato del server pesante con esigenze di caching | Redux Toolkit + RTK Query, oppure Zustand + TanStack Query | | Migrazione da Redux legacy | Redux Toolkit | | Prototipo o progetto personale | Zustand | | Audit trail rigoroso e debugging con time-travel | Redux Toolkit |

Zustand ha guadagnato slancio concreto nel 2026 man mano che i team abbandonano configurazioni più pesanti per lo stato client, mentre Redux Toolkit resta la scelta sicura di default per applicazioni grandi e di lunga durata che traggono beneficio da una struttura imposta. Molte codebase in produzione usano entrambi: Zustand per lo stato UI locale e RTK Query o TanStack Query per lo stato del server.

Conclusione

• Scegli Zustand per un boilerplate minimo, app piccole e medie e store mirati puramente client che si sposano naturalmente con i Server Components
• Scegli Redux Toolkit per applicazioni di grandi dimensioni, team numerosi e flussi asincroni complessi dove RTK Query e i DevTools ripagano il loro overhead
• Il core di Zustand pesa circa 1 KB in gzip senza provider, mentre Redux Toolkit aggiunge circa 14 KB ma include recupero dati, caching e struttura
• Entrambe le librerie supportano i selettori di React 19 ed evitano ri-render superflui quando i selettori restano ristretti
• Suddividi le responsabilità nelle app grandi: mantieni lo stato UI client in Zustand e delega lo stato del server a RTK Query o TanStack Query
• Per i colloqui, spiega i compromessi dietro ogni scelta anziché recitare le firme delle API