Dopo aver chiarito che React non è HTML, non è MVC e non vive di hook accumulati, resta l’ultimo errore strutturale da eliminare:
👉 organizzare il progetto React copiando modelli mentali che non gli appartengono.
Cartelle controllers, models, views.
Oppure separazioni forzate per “tipo di file”.
O peggio: una struttura che cresce per imitazione, non per necessità.
Il risultato è sempre lo stesso:
- codice frammentato
- responsabilità confuse
- onboarding lento
- refactor costosi
Il problema non è la struttura in sé.
È il criterio con cui la scegli.
React non chiede una struttura “giusta”. Chiede una struttura coerente
Una verità scomoda:
React non impone un’architettura.
Ed è proprio questo che manda in crisi.
Chi viene da framework opinionati cerca:
- regole rigide
- cartelle standard
- pattern “ufficiali”
React invece ti chiede di fare una cosa più difficile:
👉 pensare in termini di responsabilità e cambiamento nel tempo.
Questo approccio è coerente con quanto spiegato nella documentazione ufficiale quando React parla di composizione e separazione logica, non di layer architetturali fissi (vedi Thinking in React su react.dev).
L’errore più comune: separare per “tipo” invece che per “dominio”
Struttura tipica sbagliata:
components/
hooks/
services/
utils/
pages/
Sembra ordinata.
Ma nasconde un problema serio: la logica di una feature è sparsa ovunque.
Per capire come funziona una singola funzionalità devi:
- saltare tra cartelle
- tenere tutto in testa
- ricostruire il flusso
Questa non è architettura.
È frammentazione.
Un criterio migliore: separare per responsabilità funzionale
In React funziona meglio un approccio feature-oriented.
Non separi per “cos’è” un file.
Separi per cosa fa nel dominio dell’app.
Esempio concettuale:
features/
auth/
AuthForm.jsx
useAuth.js
authService.js
profile/
ProfileView.jsx
useProfile.js
profileService.js
Qui:
- tutto ciò che cambia insieme sta insieme
- la logica è localizzata
- l’impatto di una modifica è prevedibile
Questo modello riduce:
- accoppiamento
- dipendenze nascoste
- paura del refactor
I componenti non sono “view”: sono unità di comportamento
Altro errore mentale:
“Questo è un componente di presentazione, questo è logica.”
In React questa distinzione è spesso artificiale.
Un componente può:
- gestire stato
- reagire a eventi
- renderizzare UI
E va bene così.
Forzare separazioni premature crea:
- wrapper inutili
- prop drilling
- componenti fantasma
React non ti chiede purezza architetturale.
Ti chiede chiarezza.
Dove mettere lo stato (e dove NO)
Una struttura sana riflette ciò che abbiamo già chiarito sullo stato:
- stato locale → vicino a chi lo usa
- stato condiviso → sale solo quando serve
- stato globale → raro e intenzionale
Se la struttura ti obbliga a:
- spostare stato “perché la cartella lo impone”
- centralizzare tutto “per ordine”
stai facendo architettura contro React, non con React.
Attenzione ai “framework mentali importati”
Alcuni segnali che stai importando modelli sbagliati:
- cartelle MVC in un progetto React
- servizi che “decidono cosa fare”
- componenti passivi che aspettano istruzioni
- logica nascosta fuori dal flusso di rendering
React funziona meglio quando:
- le decisioni emergono dallo stato
- il rendering è conseguenza, non comando
- la struttura segue il dominio, non la tecnologia
Questo è coerente anche con le linee guida MDN su React, dove il focus è sempre su flusso dei dati e responsabilità, non su layer architetturali rigidi.
Una struttura “giusta” è quella che regge il cambiamento
La domanda corretta non è:
“Questa struttura è elegante?”
Ma:
“Quando cambierà questa feature, quante cose dovrò toccare?”
Se la risposta è:
- “poche, e so dove” → stai facendo bene
- “dipende, devo cercare” → stai accumulando debito
Una buona architettura React:
- non impressiona
- non è accademica
- sopravvive al cambiamento
Conclusione: l’architettura non è una cartella, è una decisione continua
React non ti dà un’architettura perché:
- ogni app è diversa
- ogni dominio ha priorità diverse
- ogni team evolve
Ma ti dà un modello chiaro:
- stato come fonte di verità
- composizione come strumento
- flusso unidirezionale come garanzia
Se costruisci la struttura seguendo questi principi,
non avrai bisogno di “pattern salvifici”.
Avrai un progetto:
- leggibile
- manutenibile
- onesto
E questo, nel tempo, vale più di qualunque struttura “perfetta”.
Questo articolo è collegato a:
- 👉 React per chi viene da HTML e CSS: l’errore mentale che ti sta rallentando
- 👉 React: come progettare componenti senza pensare in HTML
- 👉 React: come gestire lo stato senza creare caos
- 👉 React Hooks: quali servono davvero (e quali puoi ignorare)
- 👉 Perché React non è MVC (e smettere di trattarlo come tale)
