React si impara in un pomeriggio e si complica in un mese. Quasi mai il problema è la sintassi: sono le scelte su dove vive lo stato, su chi è responsabile di cosa e su come scorrono i dati tra i componenti. Questa pagina mette in ordine gli articoli del blog su React e sull’architettura frontend: un percorso in cinque tappe, dalle basi del linguaggio fino alla struttura di un progetto che regge nel tempo, più i principi che valgono anche fuori da React.
In breve: prima JavaScript moderno, poi il passaggio da HTML e CSS ai componenti, poi lo stato, infine l’architettura del progetto e gli strumenti. Se hai già scritto qualche componente e il codice comincia a sfuggirti di mano, parti dalla guida all’architettura React.
Il percorso: React e architettura frontend
L’ordine non è casuale. Ogni tappa dà per scontato quello che hai visto nella precedente: saltare JavaScript per arrivare prima a React è il modo più rapido per non capire perché un componente si comporta in un certo modo.
1. Le basi: HTML semantico, layout e JavaScript moderno
Un componente React restituisce markup: se quel markup è fatto di div senza significato, React non lo migliora. Parti dall’HTML semantico e da un layout responsive con Flexbox e Grid, perché sono la materia prima di ogni interfaccia.
Poi il linguaggio. React usa ovunque destrutturazione, arrow function, spread e moduli: la guida a JavaScript moderno (ES6+) copre la sintassi che incontrerai in ogni file, la guida a var, let e const chiarisce scope e il fatto che const non rende immutabile un oggetto, che è la base per capire perché lo stato in React non si modifica direttamente, e async/await serve appena un componente deve caricare dati da un’API.
2. Da HTML e CSS ai componenti
Il salto mentale più grande è smettere di pensare in pagine e iniziare a pensare in componenti: pezzi di interfaccia che ricevono dati (le props) e restituiscono markup. React per chi viene da HTML e CSS fa questo passaggio con esempi concreti: JSX, props, composizione e il primo useState.
Qui impari anche il modello dichiarativo: non scrivi “quando succede X, cambia il DOM così”, ma “se lo stato è X, la UI è Y”. La documentazione ufficiale lo spiega bene in Thinking in React, che parte proprio dallo scomporre un mockup in una gerarchia di componenti.
3. Lo stato: locale, condiviso, globale
Lo stato è il punto in cui la maggior parte dei progetti React si complica. La guida su come gestire lo stato in React parte da useState, passa per il sollevamento dello stato al genitore comune e per Context, e arriva alle librerie come Redux e Zustand, spiegando quando servono e quando aggiungono solo complessità.
La domanda da portarti dietro è una sola: chi è davvero responsabile di questo dato? Se la risposta è “un solo componente”, lo stato resta lì. Per i criteri pratici su come dare forma allo stato, la pagina Choosing the State Structure di react.dev elenca cinque regole utili: raggruppare lo stato correlato, evitare contraddizioni, ridondanze, duplicazioni e annidamenti profondi.
4. Architettura: struttura del progetto e modelli mentali
Quando i componenti diventano decine, serve un criterio per organizzarli. La guida Architettura React: come strutturare un progetto (e perché non è MVC) è il cuore di questa sezione: spiega perché le cartelle controllers, models e views non funzionano in React, come riconoscere i “componenti-controller” che orchestrano tutto e come organizzare il codice per feature invece che per tipo di file.
A supporto ci sono due articoli che valgono per qualsiasi frontend: moduli JavaScript, per decidere cosa esporre e cosa tenere privato in ogni file, e clean code in JavaScript, per funzioni piccole, nomi chiari e meno effetti collaterali. Sono le stesse regole che rendono leggibile un componente.
5. Ecosistema e strumenti
Un progetto React vive dentro un ambiente di lavoro: editor configurato bene, controllo di versione con Git, qualche automazione da terminale. La raccolta di strumenti per sviluppatori copre questa cassetta degli attrezzi di base, prima di bundler e framework. Vale la regola del resto del percorso: uno strumento si aggiunge quando risolve un problema che hai già, non perché è di moda.
Principi di architettura frontend
Molti progetti frontend non falliscono per limiti tecnici, ma per scelte architetturali fatte troppo presto o senza un modello mentale chiaro. Architettura frontend non significa applicare un pattern: significa decidere come dividere le responsabilità, come scorrono i dati e dove passano i confini tra le parti dell’applicazione. Questi principi valgono in React come in Vue o in JavaScript senza framework.
Separazione delle responsabilità
Un componente dovrebbe avere un motivo per cambiare. Quando lo stesso file recupera dati, li trasforma, gestisce errori e disegna la UI, ogni modifica tocca tutto. Separare non vuol dire creare layer rigidi alla MVC: vuol dire estrarre la logica di dominio in funzioni o hook dedicati e lasciare ai componenti il compito di mostrare lo stato e raccogliere gli eventi.
Flusso dei dati in una direzione
In React i dati scendono tramite le props e le azioni risalgono tramite callback. È questo vincolo a rendere il comportamento prevedibile: se un valore è sbagliato, sai dove cercare. Quando due componenti devono restare sincronizzati, la soluzione è spostare lo stato nel genitore comune, come mostra la guida ufficiale su come condividere lo stato tra componenti, non creare canali laterali.
Dove vive lo stato
Lo stato va tenuto il più vicino possibile a chi lo usa e sollevato solo quando serve davvero. Lo stato globale introdotto come scorciatoia, per collegare componenti senza una relazione chiara, è uno dei segnali più comuni di un’architettura debole. Una libreria di state management è uno strumento per un problema reale e stabile, non il punto di partenza di ogni progetto.
Struttura delle cartelle
Organizzare per tipo (tutti i componenti qui, tutti gli hook là) funziona finché il progetto è piccolo. Oltre una certa dimensione conviene raggruppare per feature: ogni cartella contiene componenti, hook, test e stili di una parte dell’applicazione, con un solo punto di ingresso pubblico. Una modifica resta così dentro una cartella invece di attraversarne cinque.
Errori ricorrenti
- pattern copiati da altri contesti senza capire il problema che risolvevano
- separazioni forzate in layer che React non prevede
- logica di business dispersa dentro i componenti
- stato condiviso senza una strategia chiara su chi lo possiede
- astrazioni costruite per problemi che non esistono ancora
Nessuno di questi errori si risolve con una libreria in più. Si risolve con un modello mentale corretto: la UI è una funzione dello stato, ogni dato ha un proprietario, la semplicità ben progettata scala meglio della complessità anticipata.
Da dove iniziare adesso
- Se React è nuovo per te: React per chi viene da HTML e CSS.
- Se i componenti si passano dati in modi che non capisci più: Gestire lo stato in React.
- Se il progetto è cresciuto e ogni modifica rompe qualcosa: Architettura React.
