Hai un’app Flutter che carica dati e… non si aggiorna. Premere un bottone non cambia nulla. Il colore di un pulsante resta quello di default, l’elenco non si ricarica, lo spinner non parte. E tu sei lì, a fissare il codice, chiedendoti: «Ma se ho richiamato setState, perché non funziona?».
Benvenuto nel cuore pulsante di Flutter: il Widget Tree, con i suoi StatelessWidget e StatefulWidget. No, non è una questione astratta da manuale. È il motivo per cui la tua interfaccia reagisce (o non reagisce) ai dati. È la differenza tra un’app che sembra viva e una che sembra morta.
Noi, di Meteora Web, costruiamo applicazioni con Flutter da anni. E abbiamo visto troppi sviluppatori — anche con esperienza — inciampare su questa distinzione. Perché non è solo teoria: ogni volta che scegli un widget sbagliato, condanni l’utente a scrollate inutili, refresh forzati o, peggio, crash silenziosi.
Questa guida ti porta dentro il Widget Tree, ti mostra esattamente quando usare uno StatelessWidget e quando uno StatefulWidget, e ti dà gli strumenti per capire perché Flutter decide di ricostruire (o non ricostruire) un pezzo di schermo. Niente filosofia: codice, esempi, e un po’ di numeri — perché qui ragioniamo anche in termini di performance e costo di sviluppo.
Cos’è il Widget Tree — e perché ti riguarda
Flutter è una macchina di widget annidati. Ogni widget è una classe Dart che restituisce una descrizione di ciò che deve essere dipinto a schermo. Non è il pixel finale: è la ricetta. Flutter prende queste ricette, le confronta con la versione precedente e decide cosa ridipingere. Questa differenza è il Widget Tree.
Immaginalo come un albero genealogico: un widget padre contiene widget figli, che a loro volta contengono altri figli. Quando qualcosa cambia (un dato, un’interazione), Flutter percorre l’albero, confronta il nuovo albero (dopo la modifica) con quello vecchio, e ridipinge solo i nodi che sono effettivamente cambiati. Questo meccanismo si chiama element tree + render tree, ma il concetto chiave è: più il tuo albero è piatto e ben strutturato, più veloce è la differenza.
Errore comune: mettere tutto dentro un unico grande widget che si ricostruisce ogni volta. Invece ogni piccola parte che può rimanere fissa (un’icona, una label statica) dovrebbe essere un widget separato, magari Stateless, per evitare ricostruzioni inutili.
Esempio pratico: un contatore che non si aggiorna
class WrongCounter extends StatelessWidget {
@override
Widget build(BuildContext context) {
int count = 0; // Dichiarato qui dentro
return Column(
children: [
Text('Hai cliccato $count volte'),
ElevatedButton(
onPressed: () {
count++; // Questo non funziona!
},
child: Text('Incrementa'),
),
],
);
}
}Perché non funziona? Perché non c’è setState. In uno StatelessWidget, il metodo build viene chiamato una volta e non viene mai ripetuto. La variabile count è persa dopo la prima build. Per avere uno stato che persiste tra le ricostruzioni, serve un StatefulWidget.
StatelessWidget: quando l’interfaccia non cambia mai (o quasi)
Uno StatelessWidget descrive una parte dell’interfaccia che non dipende da alcun dato mutabile. La sua build viene chiamata una volta per ogni stato dell’albero, e il widget è immutabile: non può cambiare nel tempo. Esempi classici: icone, titoli fissi, pulsanti con testo costante, divisori.
Quando usarlo? Quando il contenuto visivo è determinato solo dai parametri passati al costruttore e non cambia mai dopo la creazione. Se hai bisogno di aggiornare qualcosa (es: un contatore, un messaggio di errore che appare/scompare), devi passare a StatefulWidget.
Vantaggio concreto: meno codice, meno possibilità di errori, performance migliori perché Flutter sa che questo widget non ricostruirà mai la sua UI interna da solo.
Checklist per scegliere StatelessWidget
- Il widget rappresenta solo dati che arrivano da fuori (parametri) e non cambiano mai? → StatelessWidget
- Il widget ha uno stato interno (es: variabili count, flag booleani, timer)? → StatefulWidget
- Il widget deve reagire a eventi utente che modificano la UI? → StatefulWidget
- Hai un widget che mostra solo testo formattato, icone fisse, spazi vuoti? → StatelessWidget
StatefulWidget: lo stato che cambia e setState
Un StatefulWidget è composto da due classi: il widget stesso (immutabile) e uno State che vive separato e può essere sostituito. Quando chiami setState(), Flutter sa che deve richiamare il metodo build della State associata e confrontare il nuovo widget tree con il precedente. Senza setState, la UI resta congelata anche se le variabili cambiano.
class CorrectCounter extends StatefulWidget {
@override
_CorrectCounterState createState() => _CorrectCounterState();
}
class _CorrectCounterState extends State<CorrectCounter> {
int _count = 0;
void _increment() {
setState(() {
_count++;
});
}
@override
Widget build(BuildContext context) {
return Column(
children: [
Text('Hai cliccato $_count volte'),
ElevatedButton(
onPressed: _increment,
child: Text('Incrementa'),
),
],
);
}
}Nota: la variabile _count è dichiarata nella State, non nel widget. Lo State viene creato una volta e vive fino a quando il widget viene rimosso dall’albero. setState dice a Flutter: «Ehi, c’è una modifica, per favore ridisegna la UI di questo widget».
Errore tipico: chiamare setState ma modificare fuori
Non fare:
void _increment() {
_count++;
setState(() {}); // Funziona ma è brutto e confonde
}Fallo dentro la callback di setState, così Flutter sa esattamente cosa è cambiato. Il codice è più leggibile e meno soggetto a bug.
Il Widget Tree in azione: perché un widget figlio non si aggiorna
Immagina di avere un widget padre StatefulWidget che contiene un widget figlio StatelessWidget. Il padre chiama setState, ma il figlio non si aggiorna? Dipende. Se il figlio riceve come parametro un dato cambiato (es: il valore del contatore), Flutter lo ricostruirà perché il suo costruttore è stato chiamato con argomenti diversi. Se invece il figlio usa dati interni (non parametri), non si aggiornerà. Regola: un widget figlio si ricostruisce solo se il suo costruttore viene richiamato con parametri diversi.
Esempio:
class Parent extends StatefulWidget { … }
class _ParentState extends State<Parent> {
String _message = 'Ciao';
@override
Widget build(BuildContext context) {
return Column(
children: [
ChildWidget(message: _message), // ogni setState ricrea ChildWidget
TextButton(onPressed: () => setState((){}), child: Text('Forza update'))
],
);
}
}Qui ChildWidget riceve sempre lo stesso _message? Se non cambi _message, il ChildWidget non si ricostruisce (perché il parametro è identico, Flutter lo nota). Se però vuoi forzare un refresh anche senza cambiare parametro, devi usare un Key diversa o trasformare ChildWidget in StatefulWidget con un suo stato interno.
Come Flutter decide cosa ridipingere: un piccolo benchmark mentale
Flutter usa un algoritmo O(n) per confrontare vecchio e nuovo widget tree. Ogni volta che chiami setState, Flutter ricostruisce l’intero sotto-albero di quel widget. Se il tuo albero è profondo e gonfio, ogni setState costa caro. Noi, di Meteora Web, abbiamo ottimizzato app riducendo la profondità del tree del 40%: il risultato è stato un caricamento scrolling 2x più fluido su dispositivi mid-range.
Quando usare StatelessWidget con dipendenze esterne (costo/beneficio)
A volte si è tentati di dichiarare tutto StatelessWidget per semplicità, e poi spostare lo stato su un widget padre o su un provider esterno. È una strategia valida, ma devi valutare il costo in termini di complessità e performance. Se lo stato è locale a un singolo widget (es: checkbox, animazione minuta), tenerlo come StatefulWidget è spesso più efficiente e leggibile. Se lo stato è condiviso tra più widget, meglio alzarlo a un provider e usare StatelessWidget per il resto. La regola d’oro: ogni widget dovrebbe fare solo una cosa.
Cosa fare adesso — azioni immediate
- Rivedi il tuo codice: cerca widget che usano
buildcon variabili locali non derivate da parametri. Quelli devono diventare StatefulWidget o spostare lo stato esternamente. - Identifica i “candidati Stateless”: ogni widget che non ha variabili interne mutabili e non chiama setState può e deve essere StatelessWidget. Questo riduce il carico sull’albero.
- Testa con il debugger: usa i
printo ilFlutter Inspectorper vedere quanti widget vengono ricostruiti a ogni setState. Se vedi più nodi del previsto, spezza il tuo widget in sotto-widget più piccoli. - Impara a usare le
Key: quando sposti un widget nell’albero (es: in una lista ordinata), fornire una Key aiuta Flutter a non ricostruire l’intero elemento. Le Key sono la scorciatoia per aggiornamenti efficienti. - Non dimenticare la differenza tra “build” e “initState”: nomi parlanti. initState si chiama una volta, build ogni setState. Non mettere logiche pesanti in build se non serve.
Questa guida ti ha dato le basi per distinguere Stateless e Stateful, e per capire come il Widget Tree reagisce ai cambiamenti. Ma la vera maestria arriva con la pratica. Prendi un piccolo progetto Flutter, apri l’Inspector, e guarda cosa succede quando premi un bottone. Poi modifica il tuo albero, spezza un widget enorme in tanti piccoli Stateless, e misura la differenza di FPS. Solo così scoprirai quanto contano poche righe di codice ben posizionate.
Ricorda: un’app Flutter non è fatta di pixel, ma di decisioni su quando ricostruire. E noi, di Meteora Web, scegliamo sempre la via che fa risparmiare batteria e secondi all’utente.
Sponsored Protocol
