State Management: Oltre Redux vs Zustand
Una guida per porre fine al monolite dello store globale. Ownership strategica dello stato, confini Server/Client e l'impatto dei React Server Components.
L’errore più costoso nello sviluppo React moderno è trattare lo stato come un contenitore piatto e globale.
Lo stato globale è un “architectural smell”. Questo è un concetto chiave dell’Architecture Mindset necessario per sistemi complessi.
Per anni siamo stati ossessionati da “Redux vs Zustand” o “Context vs Recoil”. Queste sono le domande sbagliate. Un Senior Architect non sceglie una libreria; progetta un distributed state ownership model.
La Morte del Monolite “Global Store”
La “Single Source of Truth” era una soluzione del 2015 per i problemi del 2015. Oggi, lo store globale è diventato un collo di bottiglia per la manutenibilità.
Il Problema dell’Accoppiamento Nascosto (Hidden Coupling)
Quando tutto è globale, nulla è incapsulato.
- Paura del Refactoring: Gli sviluppatori smettono di fare refactoring perché non sanno chi consuma cosa dallo store.
- Carico Cognitivo: Per risolvere un bug, ti ritrovi a dover tenere a mente l’intero stato dell’applicazione.
Strategic Mantra: Se lo stato non deve essere condiviso tra diverse feature, non deve uscire dalla feature boundary.
Il Confine tra Stato Server e Client
La separazione architetturale più critica è quella tra Server State (dati recuperati dal backend) e Client State (interazioni UI effimere).
Server State: I Dati come Cache Aggiornabile
Il 90% di ciò che mettevamo in Redux era semplicemente “dati da un’API”. Strumenti come TanStack Query o SWR hanno vinto questa battaglia perché trattano i dati per quello che sono: una cache che scade.
Il Server State appartiene a un layer di cache dedicato, non al tuo gestore dello stato UI.
Client State: L’Interazione come Segnale
Il vero Client State è raro. Include cose come:
- La sidebar è aperta?
- Quale tab è attiva?
- L’input di un form prima dell’invio.
Per questo, usiamo l’Atomic State (Jotai/Recoil) o i Signals, che permettono aggiornamenti ad alta frequenza con un costo di re-render quasi nullo.
L’Impatto di RSC sull’Architettura dello Stato
Tutte le nuove strategie di rendering e i React Server Components hanno cambiato fondamentalmente il luogo in cui risiede lo stato.
Spostare la Source of Truth
In un mondo RSC-first, la “Source of Truth” è spesso l’URL o il database stesso.
- Ricerca & Filtri: Questi ora risiedono nell’URL (Search Params), rendendo lo stato condivisibile e “a prova di refresh”.
- Coerenza dei Dati: I Server Components possono passare i dati come props, eliminando la necessità di uno “store idratato” lato client per la maggior parte dei dati in sola lettura.
Matrice della State Ownership
| Scenario | Scelta Strategica | Razionale Architetturale |
|---|---|---|
| Dati API (CRUD) | TanStack Query / RSC | Caching automatico, revalidation e loading states. |
| Global UI Config | Atomic Store (Jotai) | Aggiornamenti disaccoppiati e ad alte prestazioni. |
| Stato Form Locale | useState / useActionState | Massimo incapsulamento, nessun side effect. |
| Workflow Complessi | State Machines (XState) | Elimina il “Boolean Hell” e gli stati UI impossibili. |
Strategic Insight: L’obiettivo è spostare quanto più stato possibile dal monolite alle boundaries.
Mantra Strategici per gli Architect
- L’URL è stato: Se un utente deve poter ricaricare la pagina e vedere la stessa cosa, quella informazione appartiene all’URL.
- Incapsulamento sopra la Comodità: È facile mettere lo stato in uno store globale oggi, ma sarà 10 volte più difficile rimuoverlo domani.
- Derivato sopra Archiviato: Mai memorizzare uno stato che può essere calcolato da altri dati. L’efficienza computazionale costa meno della complessità di sincronizzazione.
Conclusione: Progettare per il Cambiamento
Lo state management non è più una scelta tecnica sulle performance: è una scelta di design sulla manutenzione.
Per costruire un’applicazione React che scali fino al 2030, smetti di chiedere quale libreria sia migliore. Inizia a chiederti: “Chi possiede questi dati e qual è il loro ambito d’azione minimo possibile?”
Controlla le tue boundaries di stato, o loro controlleranno la tua architettura.