Se vieni da HTML e CSS, c’è un errore che quasi tutti fanno quando iniziano con React:
progettare i componenti partendo dal markup.
È istintivo.
Apri il layout, guardi la pagina, e inizi a spezzarla in header, card, sidebar, footer.
Funziona visivamente.
Ma concettualmente è il modo più lento di usare React.
React non chiede di dividere una pagina in pezzi HTML.
Chiede di modellare comportamenti.
E finché non cambi questo approccio, i componenti ti sembreranno:
- troppi
- confusi
- difficili da riutilizzare
- legati al layout
Il problema: componenti progettati come “pezzi di pagina”
Quando progetti componenti come se fossero sezioni HTML:
- crei componenti enormi
- li riempi di
div - li rendi dipendenti dal contesto visivo
- li riusi a fatica (o per niente)
Questo succede perché stai rispondendo alla domanda sbagliata.
❌ Domanda sbagliata
“Quali parti visive vedo nella pagina?”
✅ Domanda giusta
“Quali responsabilità ha questa parte dell’interfaccia?”
React lavora sulle responsabilità, non sui rettangoli.
Il vero criterio: responsabilità prima della struttura
Un buon componente React non nasce perché “serve un box”.
Nasce perché esiste una responsabilità chiara.
Esempi di responsabilità:
- gestire un input
- mostrare uno stato
- reagire a un’azione
- rappresentare un’entità del dominio
Il layout viene dopo.
Questo è coerente con il principio base spiegato nella documentazione ufficiale quando si parla di pensare in React: prima si scompone l’interfaccia in componenti logici, poi si pensa a come renderizzarli.
Se inizi dal markup, invertirai sempre l’ordine.
Perché pensare in HTML porta a componenti fragili
Quando pensi in HTML:
- le props diventano rattoppi
- lo stato finisce ovunque
- ogni modifica rompe qualcos’altro
- il refactor fa paura
Il segnale più chiaro che stai sbagliando è questo:
“Non posso riusare questo componente senza copiarlo.”
Quello non è un componente.
È una pagina spezzata.
Un modello mentale più utile: componenti come funzioni di stato
In React un componente è, prima di tutto:
una funzione che riceve dati e produce interfaccia
Non una sezione.
Non un contenitore.
Non un template.
Concettualmente:
Componente = f(stato, props)
Questo significa che un buon componente:
- ha input chiari
- ha una sola responsabilità
- produce sempre lo stesso output a parità di stato
Questo approccio è alla base del modello dichiarativo di React, spiegato anche nella panoramica MDN su React, dove l’interfaccia è descritta come conseguenza dei dati, non come sequenza di istruzioni.
Errori comuni nella progettazione dei componenti
❌ Componenti troppo grandi
Se un componente:
- gestisce stato
- layout
- logica
- side effects
probabilmente fa troppo.
Un componente che cresce senza controllo è un warning architetturale.
❌ Componenti legati al layout
Se un componente:
- funziona solo in una pagina
- rompe se cambi grid o flex
- dipende da classi esterne
stai progettando HTML con JavaScript, non React.
❌ Spezzare solo per riuso visivo
Creare componenti solo perché “si ripete il markup” è una falsa ottimizzazione.
Il riuso utile in React è:
- riuso di comportamento
- riuso di logica
- riuso di stato
Il resto è estetica.
Come partire nel modo giusto (senza overengineering)
Se stai progettando una nuova UI in React:
- Scrivi prima il flusso logico (non il JSX)
- Identifica quali dati cambiano nel tempo
- Chiediti chi è responsabile di quello stato
- Solo alla fine pensa a come appare
Questo ti evita:
- componenti inutili
- gerarchie profonde
- dipendenze fragili
E ti permette di cambiare layout senza riscrivere logica.
React non è un sistema di layout
Questa è una delle confusioni più diffuse.
React:
- non sostituisce HTML
- non sostituisce CSS
- non gestisce layout
React decide:
- quando qualcosa viene renderizzato
- perché cambia
- in base a cosa
Il layout rimane responsabilità di:
- CSS
- Grid
- Flexbox
Quando separi davvero queste responsabilità, tutto diventa più semplice.
Conclusione: smetti di disegnare pagine, inizia a modellare comportamenti
Se progetti componenti partendo dal markup:
- React ti sembrerà verboso
- il codice crescerà male
- la manutenzione diventerà costosa
Se progetti componenti partendo dalla logica:
- i componenti diventano piccoli
- il codice è prevedibile
- il refactor fa meno paura
Il passaggio chiave è questo:
non chiederti cosa vedi nella pagina, ma cosa deve fare quella parte dell’interfaccia
Quando fai questo salto, React inizia davvero a lavorare con te, non contro di te.
Vuoi chiudere il cerchio?
Se questo approccio ora è più chiaro, il passo successivo naturale è capire come gestire lo stato senza farlo esplodere tra i componenti.
👉 React: come gestire lo stato senza creare caos
Collegamento al post precedente
Se non l’hai ancora letto, questo articolo nasce direttamente da qui:
👉 React per chi viene da HTML e CSS: l’errore mentale che ti sta rallentando
