Se React a un certo punto ti è sembrato confuso, ingestibile o “magico”, molto probabilmente il problema non era React.
👉 Era lo stato.
La maggior parte dei progetti React non diventa caotica per colpa dei componenti,
ma perché lo stato cresce senza una strategia chiara.
All’inizio tutto funziona.
Poi arrivano:
- dati che devono essere condivisi
- componenti che dipendono l’uno dall’altro
- aggiornamenti che rompono parti lontane
Ed è lì che nasce la sensazione di perdita di controllo.
Cos’è davvero lo stato (e cosa non è)
Errore comune:
“Lo stato è una variabile che cambia.”
No.
In React, lo stato è:
la fonte di verità che determina cosa viene renderizzato
Questo significa una cosa cruciale:
- se lo stato è confuso, l’interfaccia sarà confusa
- se lo stato è sparso, il comportamento sarà imprevedibile
Lo stato non serve a memorizzare valori.
Serve a guidare il rendering.
Questo è coerente con il modello dichiarativo spiegato nella documentazione ufficiale quando si parla di pensare in React: l’interfaccia è sempre una conseguenza dei dati.
Il vero problema: troppo stato (e nel posto sbagliato)
La causa numero uno del caos non è “mancanza di Redux” o “hook sbagliati”.
È questo:
mettere stato ovunque, senza chiedersi perché
Segnali che stai andando nella direzione sbagliata:
- lo stesso dato esiste in più componenti
- passi props in profondità “solo per arrivare sotto”
- aggiorni uno stato e qualcosa di distante si rompe
Quando succede, non serve un nuovo tool.
Serve ridisegnare la responsabilità dello stato.
Regola fondamentale: lo stato vive dove serve
Principio chiave:
lo stato deve vivere nel componente più alto che ne ha realmente bisogno
Non più in alto.
Non più in basso.
Se uno stato:
- serve solo a un componente → resta lì
- serve a più componenti fratelli → sale
- serve a tutta l’app → va centralizzato
Questo principio è spiegato chiaramente anche nella guida MDN su React, quando si introduce la gestione dello stato e il passaggio dei dati.
Ignorare questa regola porta a:
- prop drilling
- duplicazione
- bug difficili da tracciare
Stato locale: il tuo miglior alleato (se non lo tradisci)
Lo stato locale (useState) non è una soluzione di serie B.
È lo strumento principale.
Usalo per:
- input
- toggle
- stati temporanei
- UI state
Se inizi a spostare stato verso l’alto “per sicurezza”, stai creando complessità preventiva.
La semplicità viene prima della riusabilità.
Quando lo stato deve salire (e quando no)
Una buona domanda da farti è questa:
“Chi ha davvero bisogno di sapere questa informazione?”
Se la risposta è:
- “solo questo componente” → resta
- “più parti della stessa vista” → sale
- “parti lontane dell’app” → centralizza
Salire senza motivo crea componenti “contenitori” vuoti.
Scendere senza criterio crea dipendenze nascoste.
Entrambi portano caos.
Stato derivato: uno degli errori più costosi
Errore tipico:
“Salvo nello stato qualcosa che posso calcolare.”
Questo è uno dei bug architetturali più diffusi.
Se un valore:
- può essere calcolato da props o stato
- non serve essere persistito
👉 non è stato
Salvare stato derivato significa:
- duplicare fonti di verità
- introdurre sincronizzazioni inutili
- creare bug intermittenti
React funziona meglio quando lo stato è minimo e necessario.
useEffect non serve a “far funzionare le cose”
Altro errore grave:
“Uso
useEffectper sistemare lo stato.”
useEffect non è un collante.
È uno strumento per gestire effetti collaterali.
Se lo usi per:
- sincronizzare stati
- correggere rendering
- “aggiustare” flussi
stai coprendo un problema di progettazione.
Questo è uno dei motivi per cui molti sviluppatori odiano useEffect:
lo incontrano quando l’architettura è già fragile.
Quando ha senso centralizzare lo stato
Centralizzare non è sbagliato.
È sbagliato farlo troppo presto.
Ha senso quando:
- più parti lontane condividono dati
- il flusso è bidirezionale
- il dato è davvero globale
Non perché:
- “così è più ordinato”
- “forse servirà in futuro”
- “lo fanno tutti”
Redux, Context, store esterni non risolvono il caos.
Lo amplificano se lo porti dentro senza un modello mentale chiaro.
Un modello semplice che funziona (quasi sempre)
Prima di aggiungere strumenti, assicurati che:
- lo stato è minimo
- ogni stato ha un solo proprietario
- i dati fluiscono dall’alto verso il basso
- le azioni risalgono in modo esplicito
Questo modello è sufficiente per la maggior parte delle applicazioni React.
Se non funziona, il problema non è “React troppo semplice”.
È che l’app è davvero complessa — e allora servono strumenti, non prima.
Conclusione: lo stato non è il problema, è lo specchio
Lo stato in React non crea caos.
Rivela il caos.
Se:
- lo stato è chiaro
- le responsabilità sono definite
- il flusso è leggibile
React diventa prevedibile.
Se invece lo stato:
- è duplicato
- è sparso
- viene “aggiustato” con effetti
allora nessun framework ti salverà.
Gestire bene lo stato non significa conoscere più hook.
Significa prendere decisioni chiare su cosa conta davvero.
Vuoi completare il cluster?
A questo punto il passo naturale è capire quali hook servono davvero all’inizio e quali puoi ignorare senza rimpianti.
👉 React Hooks: quali servono davvero (e quali puoi ignorare)
