Uno degli errori più comuni (e più costosi) quando si lavora con React è cercare di incastrarlo dentro il modello MVC.
Succede quasi sempre a chi:
- viene da backend tradizionale
- ha studiato architetture “classiche”
- cerca ordine replicando schemi già conosciuti
Il risultato è prevedibile:
- componenti che fanno troppe cose
- stato sparso
- logica difficile da seguire
- refactor dolorosi
👉 Il problema non è React.
👉 Il problema è forzare un modello che React non è.
Perché MVC è così difficile da abbandonare
MVC (Model–View–Controller) ha funzionato bene per anni perché risolveva un problema preciso:
separare responsabilità in sistemi server-centrici
Ma React nasce per un contesto diverso:
- UI dinamiche
- stato che cambia spesso
- rendering reattivo
- flussi asincroni continui
Applicare MVC a React è come usare una mappa di carta per guidare un drone:
ti dà l’illusione di controllo, ma non descrive il sistema che stai usando.
React non ha Controller (e questo manda in crisi)
Nel modello MVC:
- il Model gestisce i dati
- il View mostra
- il Controller coordina
In React:
- non esiste un controller centrale
- non c’è un punto unico che “decide cosa fare”
- la UI è una funzione dello stato
Questo è il cuore del modello dichiarativo di React, spiegato chiaramente anche nella documentazione ufficiale quando si introduce il concetto di pensare in React.
Tu non dici:
“quando succede X, fai Y”
Dici:
“se lo stato è X, la UI è Y”
È una differenza sottile, ma devastante se la ignori.
Il danno più comune: componenti-controller mascherati
Quando tratti React come MVC, succede questo:
- nascono componenti enormi
- pieni di logica decisionale
- che orchestrano tutto
Sono controller travestiti da componenti.
Segnali tipici:
ifannidati ovunque- stato che governa mezzo albero
- side effect gestiti “per far funzionare le cose”
- difficoltà a testare
Questi componenti diventano colli di bottiglia.
Ogni modifica è rischiosa. Ogni bug è difficile da isolare.
In React il flusso è unidirezionale (e questo cambia tutto)
Un altro punto di rottura con MVC è il flusso dei dati.
In React:
- i dati scendono
- le azioni risalgono
- lo stato guida il rendering
Questo flusso unidirezionale è uno dei principi fondamentali del framework ed è alla base della sua prevedibilità, come spiegato anche nella panoramica MDN su React e sulla gestione dello stato.
MVC invece:
- prevede più direzioni
- più punti di coordinamento
- più accoppiamento implicito
Se cerchi di replicare questo schema in React, stai combattendo il framework.
React non è MVC. È composizione + stato + dichiaratività
Un modello mentale più corretto per React è questo:
- Componenti → funzioni di rendering
- Stato → fonte di verità
- Composizione → modo di costruire UI complesse
- Eventi → segnali che richiedono cambiamento
Non c’è un controller che coordina tutto.
C’è uno stato che determina cosa esiste.
Quando accetti questo:
- i componenti diventano più piccoli
- la logica si distribuisce
- il codice è più leggibile
Perché “separare tutto” spesso peggiora le cose
Chi ragiona in MVC tende a forzare:
- cartelle
controllers - cartelle
models - cartelle
views
In React questo spesso produce:
- frammentazione artificiale
- passaggi inutili
- più boilerplate
React non chiede di separare per tipo.
Chiede di separare per responsabilità.
Un componente può:
- gestire stato
- renderizzare UI
- reagire a eventi
Non è un problema.
È una scelta intenzionale del framework.
Il vero criterio: cosa cambia nel tempo
Se vuoi un principio pratico che funziona meglio di MVC, usa questo:
Se qualcosa cambia nel tempo, è stato.
Se qualcosa reagisce al cambiamento, è rendering.
Se qualcosa descrive come combinare parti, è composizione.
Questo ti evita:
- controller centrali
- logica duplicata
- dipendenze nascoste
Ed è perfettamente allineato con il modo in cui React è stato progettato.
Conclusione: smettere di cercare MVC è un atto di maturità
React non è MVC.
Non lo diventerà.
E non è un limite.
È un framework pensato per:
- interfacce dinamiche
- flussi complessi
- cambiamento continuo
Continuare a trattarlo come MVC significa:
- rallentare
- complicare
- perdere i benefici reali
Quando smetti di cercare controller e inizi a modellare lo stato e le responsabilità, React diventa finalmente leggibile.
Non perché è semplice.
Ma perché stai usando il modello giusto.
Vuoi completare davvero il quadro?
A questo punto il passo naturale è capire come organizzare un progetto React senza cadere in cartelle MVC travestite.
👉 Architettura React: come strutturare un progetto senza framework mentali sbagliati
