Redux Toolkit vs Context API: quando serve davvero uno state manager

"Ti serve Redux?" è quasi sempre la domanda sbagliata. La domanda giusta è che tipo di stato stai gestendo, perché Context API e Redux Toolkit risolvono problemi diversi, anche se si sovrappongono in superficie.

Il problema che risolvono non è lo stesso

Context API è un meccanismo di dependency injection: passa un valore attraverso l'albero dei componenti senza prop drilling. Non è ottimizzata per stato che cambia spesso — ogni update del valore in un Context ri-renderizza tutti i consumer, a meno di tecniche di ottimizzazione manuali.

Redux Toolkit è pensato per stato applicativo che cambia frequentemente e in modo prevedibile: azioni tipizzate, reducer puri, DevTools per ispezionare ogni cambiamento nel tempo.

Context API: per cosa è fatta bene

Tema dell'interfaccia, utente autenticato, lingua selezionata: valori che cambiano raramente e servono a molti componenti sparsi nell'albero. Per questi casi Context API, magari con useReducer per la logica di aggiornamento, è più che sufficiente e non introduce dipendenze extra.

Quando Context inizia a scricchiolare

Quando lo stato cambia spesso (es. un carrello che si aggiorna a ogni click, un editor con autosalvataggio) e coinvolge molti componenti, i re-render indiscriminati diventano un problema di performance reale, non teorico. È anche il punto in cui manca qualcosa che Redux offre di default: history delle azioni, time-travel debugging, middleware per side-effect asincroni.

Redux Toolkit: cosa risolve davvero

Redux "classico" aveva una reputazione di boilerplate eccessivo — action creator, tipi di azione come stringhe, reducer scritti a mano. Redux Toolkit (createSlice, configureStore) elimina gran parte di questo attrito:

const cartSlice = createSlice({
  name: "cart",
  initialState,
  reducers: {
    itemAdded: (state, action: PayloadAction<CartItem>) => {
      state.items.push(action.payload);
    },
  },
});

Con Immer integrato, si scrive codice che sembra mutare lo stato direttamente, restando comunque immutabile sotto il cofano — meno occasioni di introdurre bug nei reducer.

Come decido io

Parto sempre da Context API + useState/useReducer locale. Passo a Redux Toolkit solo quando osservo almeno uno di questi segnali: stato condiviso da più feature non correlate, necessità reale di debug time-travel, o performance degradate misurabili per via di re-render causati da un Context troppo "affollato".

Conclusione

Introdurre Redux Toolkit su un progetto piccolo per abitudine è overhead non necessario. Non introdurlo su un progetto che ne ha davvero bisogno si traduce, di solito, in un Context gigante che fa la stessa cosa in modo peggiore.