Context API vs Zustand vs Redux: come scegliere la gestione dello stato globale in React

Hai un'app React che cresce. I prop-drilling iniziano a farti impazzire. I componenti condividono dati che dovrebbero essere globali: carrello, utente loggato, preferenze tema. E ora arriva la domanda: Context API, Zustand o Redux?

Noi di Meteora Web la vediamo spesso nei progetti che ci arrivano: sviluppatori che scelgono la libreria di moda senza capire cosa cambia davvero nei costi di manutenzione, nelle performance e nella velocità di sviluppo. Un negozio di abbigliamento che abbiamo gestito internamente ci ha insegnato che ogni scelta tecnica ha un ritorno economico: un carrello che si aggiorna in 300ms invece che 800ms fa vendere di più. Una soluzione troppo astratta rallenta il team. Una troppo semplice si rompe alla prima feature complessa.

Questa guida ti dà il criterio. Non elenchi di feature, ma il perché e il quando. Alla fine saprai esattamente quale strumento usare per il tuo prossimo progetto.

Il problema che risolvono: stato condiviso oltre il componente singolo

In React, ogni componente ha il suo stato locale con useState. Quando due componenti fratelli devono leggere e scrivere gli stessi dati, devi sollevare lo stato al genitore comune. Se la gerarchia è profonda, ti ritrovi a passare props per 5 livelli. È il famoso prop-drilling. Non è solo brutto da leggere: ogni volta che tocchi un prop intermedio ri-renderizzi componenti che non dovrebbero.

Le soluzioni di stato globale risolvono questo: un deposito centrale (store) accessibile da qualsiasi componente, senza passare props. Context API è nativa in React, Zustand e Redux sono librerie esterne. Ognuna con compromessi diversi.

Context API: semplice ma attenta alle performance

La Context API permette di creare un contenitore di stato con React.createContext e di consumarlo con useContext. È integrata, zero dipendenze.

Come funziona

Definisci un contesto, Provider avvolge l'albero dei componenti, i figli leggono con useContext.

// store/UserContext.jsx
import { createContext, useContext, useState } from 'react';

const UserContext = createContext(null);

export function UserProvider({ children }) {
 const [user, setUser] = useState(null);
 return (
   
     {children}
   
 );
}

export const useUser = () => useContext(UserContext);

Poi nei componenti:

import { useUser } from './store/UserContext';

function UserAvatar() {
 const { user } = useUser();
 return user ?  : 
Non loggato
;
}

Quando usarla

• Stato piccolo e poco modificato (tema, lingua, utente base).
• Prototipi rapidi o app con pochi componenti.
• Non hai bisogno di middleware o strumenti di debugging avanzati.

Attenzione ai ri-render

Context API ha un difetto noto: ogni volta che il valore del Provider cambia, tutti i componenti che consumano quel contesto si ri-renderizzano, anche se leggono solo una parte dello stato. Se il valore è un oggetto e lo aggiorni senza memoizzazione, la performance cala.

Soluzione parziale: separa i contesti per dominio. Un contesto per l'utente, uno per il tema, uno per il carrello. Oppure usa useMemo per evitare oggetti nuovi a ogni render.

const value = useMemo(() => ({ user, setUser }), [user]);
return {children};

Redux: robustezza a costo di boilerplate

Redux è la soluzione storica. Store globale immutabile, azioni, reducers puri, middleware (Thunk, Saga). Aziende enterprise lo usano da anni.

Struttura base

// store/cartSlice.js
import { createSlice, configureStore } from '@reduxjs/toolkit';

const cartSlice = createSlice({
 name: 'cart',
 initialState: { items: [] },
 reducers: {
   addItem: (state, action) => { state.items.push(action.payload); },
   removeItem: (state, action) => {
     state.items = state.items.filter(i => i.id !== action.payload.id);
   }
 }
});

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

// store/index.js
import { configureStore } from '@reduxjs/toolkit';
import cartReducer from './cartSlice';

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

Nei componenti:

import { useSelector, useDispatch } from 'react-redux';
import { addItem } from './store/cartSlice';

function AddToCartButton({ product }) {
 const dispatch = useDispatch();
 const itemsCount = useSelector(state => state.cart.items.length);
 return (
    dispatch(addItem(product))}>
     Aggiungi ({itemsCount})
   
 );
}

Pro

• Strumenti di sviluppo eccellenti (Redux DevTools, time-travel debugging).
• Middleware per side effect (chiamate API, logging).
• Pattern chiaro e prevedibile, adatto a team grandi.
• Performance ottimizzata grazie a selettori memoizzati (createSelector).

Contro

• Molto boilerplate: azioni, reducer, store, slice, selettori.
• Curva di apprendimento ripida.
• Per app piccole è eccessivo: 100 righe di setup per due variabili globali.

Zustand: la via di mezzo pragmatica

Zustand è una libreria minimalista per lo stato globale. Non richiede provider, non ha azioni o reducer formali. Crea uno store con create e lo usi con un hook.

// store/useCartStore.js
import { create } from 'zustand';

const useCartStore = create((set) => ({
 items: [],
 addItem: (item) => set((state) => ({ items: [...state.items, item] })),
 removeItem: (id) => set((state) => ({
   items: state.items.filter(i => i.id !== id)
 })),
 get totalItems() {
   return this.items.length;
 }
}));

export default useCartStore;

Nel componente:

import useCartStore from './store/useCartStore';

function AddToCartButton({ product }) {
 const addItem = useCartStore(state => state.addItem);
 const itemsCount = useCartStore(state => state.items.length);
 return (
    addItem(product)}>
     Aggiungi ({itemsCount})
   
 );
}

Pro

• Zero boilerplate. Scrivere uno store è come scrivere una funzione.
• Nessun Provider. I componenti possono consumare lo store direttamente.
• Performance fine-grained: ogni selettore si iscrive solo alla parte di stato che legge.
• Supporto per middleware (persist, immer, devtools) opzionale.

Contro

• Meno strutturato di Redux. Per team grandi può mancare di disciplina.
• DevTools non nativi (ma esiste devtools middleware).
• Non scala come Redux se hai centinaia di azioni asincrone complesse.

Confronto diretto: quando usare cosa

Non esiste la soluzione migliore in assoluto. Esiste quella giusta per il tuo contesto. Ecco uno schema decisionale.

Scenario	Scelta	Motivo
Piccola app, pochi stati (tema, lingua, auth)	Context API	Niente dipendenze, semplice, veloce da scrivere
App media con stato frequente (carrello, filtri, preferiti)	Zustand	Performance, flessibilità, poco boilerplate
Grande applicazione enterprise, team multipli	Redux Toolkit	Pattern standardizzato, debugging, scalabilità
Prototipo rapido o hackathon	Context API o Zustand	Zero setup
App con molti side effect asincroni (API, WebSocket)	Redux + createAsyncThunk o Zustand + immer	Entrambi gestibili, ma Redux middleware è maturo
Necessiti di persistenza locale immediata	Zustand con middleware persist	2 righe di codice

I costi nascosti (perché noi ragioniamo in termini di costo e ritorno)

Ogni scelta tecnica ha un impatto sul budget di sviluppo e manutenzione. Noi di Meteora Web veniamo dalla contabilità: guardiamo il TCO (Total Cost of Ownership).

• Context API: costo iniziale bassissimo, ma se il progetto cresce il costo di refactoring può esplodere. Spesso la vediamo in app che diventano lente perché ogni contesto ri-renderizza tutto.
• Redux: costo iniziale alto (formazione, boilerplate), ma costo di manutenzione lineare. Ogni nuovo sviluppatore capisce subito il pattern.
• Zustand: costo iniziale medio, manutenzione bassa. Il rischio è la mancanza di struttura in team senza senior.

Il consiglio? Parti con Zustand. Se senti il bisogno di più struttura, migrare a Redux Toolkit è semplice (lo store è simile). Context API lasciala per quello che è: stato di configurazione, non di business.

In sintesi — cosa fare adesso

1. Identifica lo stato globale del tuo progetto: quante variabili? Quanto spesso cambiano? Quanti componenti le leggono?
2. Testa Zustand su un componente esistente. Ci vogliono 10 minuti. Se ti trovi bene, adottalo come standard.
3. Se devi integrare con Redux esistente, usa Redux Toolkit. Non scrivere Redux classico a mano: è un costo inutile.
4. Per stato di tema, lingua o auth semplice, usa Context API. Ma separa i contesti e memorizza i valori con useMemo.
5. Misura le performance: usa React DevTools Profiler. Se vedi ri-render indesiderati, è il momento di passare a Zustand o Redux.

Noi di Meteora Web abbiamo visto troppe app rallentare per uno stato gestito male. Scegli lo strumento giusto e risparmierai mesi di bug e refactoring. Se hai un progetto in corso e non sai da che parte iniziare, contattaci: ti aiutiamo a fare diagnosi senza impegno.