Perché la gestione dello stato è uno dei problemi frontend più difficili

Cosa significa davvero lo “stato” in un'app frontend

Una definizione in linguaggio semplice

In un'app frontend, lo stato è semplicemente i dati su cui l'interfaccia dipende e che possono cambiare nel tempo.

Quando lo stato cambia, lo schermo dovrebbe aggiornarsi per riflettere quel cambiamento. Se lo schermo non si aggiorna, lo fa in modo incoerente o mostra una miscellanea di valori vecchi e nuovi, i problemi di stato si percepiscono subito: pulsanti che restano disabilitati, totali che non tornano o una vista che non rispecchia l'azione appena fatta dall'utente.

Esempi comuni che vedi ogni giorno

Lo stato compare in interazioni piccole e grandi, per esempio:

• Campi di un form: quello che l'utente ha digitato, se una checkbox è selezionata, quali errori mostrare
• Scelte di navigazione: tab selezionato, passo corrente in una procedura guidata, sezioni espanse/compresse
• Dati del carrello: articoli, quantità, coupon applicati, totali calcolati
• Sessione utente: informazioni utente loggato, permessi, feature flag, preferenze “ricordami”

Alcuni di questi sono “temporanei” (come una tab selezionata), altri sembrano “importanti” (come un carrello). Sono tutti stato perché influenzano ciò che l'interfaccia renderizza in questo momento.

Perché lo stato è più di “variabili in un componente”

Una variabile banale conta solo dove vive. Lo stato è diverso perché ha regole:

• Proprietà: quale parte dell'app può cambiarlo
• Flusso di aggiornamento: quando e come i cambiamenti provocano re-render
• Coerenza: assicurare che più parti dell'interfaccia non si scostino tra loro

Lo scopo reale della gestione dello stato non è memorizzare i dati, ma rendere gli aggiornamenti predicibili in modo che l'interfaccia resti coerente. Quando riesci a rispondere a “cosa è cambiato, quando e perché”, lo stato diventa gestibile. Quando non puoi, anche funzionalità semplici si trasformano in sorprese.

Perché lo stato sembra facile all'inizio (e poi non lo è più)

All'inizio di un progetto frontend lo stato sembra quasi noioso—in senso positivo. Hai un componente, un input e un aggiornamento ovvio. Un utente digita in un campo, salvi quel valore e l'interfaccia si ri-renderizza. Tutto è visibile, immediato e contenuto.

Il caso semplice: un componente, un aggiornamento

Immagina un singolo campo di testo che mostra in anteprima ciò che digiti:

• Lo stato vive nello stesso componente che renderizza l'input.
• L'aggiornamento avviene in risposta diretta all'azione dell'utente.
• Non c'è discussione su “chi possiede” i dati.

In questo scenario lo stato è fondamentalmente: una variabile che cambia nel tempo. Puoi indicare dove è memorizzata e dove è aggiornata, e il gioco è fatto.

Perché lo stato locale del componente sembra semplice

Lo stato locale funziona perché il modello mentale corrisponde alla struttura del codice:

• Lo scope è piccolo (un componente, magari qualche figlio).
• Gli aggiornamenti sono sincroni dal punto di vista dell'utente.
• Il flusso dei dati è ovvio: input → aggiornamento → render.

Anche se usi un framework come React, non devi pensare profondamente all'architettura. I comportamenti di default sono sufficienti.

Cosa cambia man mano che l'app cresce

Non appena l'app smette di essere “una pagina con un widget” e diventa “un prodotto”, lo stato smette di vivere in un solo posto.

Ora lo stesso dato può essere necessario su:

• più schermate (navigazione)
• componenti distanti (UI condivisa)
• ricariche e riavvii (persistenza)
• multi‑utente/dispositivi (sincronizzazione server)

Un nome profilo può comparire in un header, essere modificato in una pagina impostazioni, essere cache‑ato per un caricamento più veloce e servire a personalizzare un messaggio di benvenuto. Improvvisamente la domanda non è “come memorizzo questo valore?” ma “dove dovrebbe vivere questo valore perché sia corretto ovunque?”

La complessità cresce in modo non lineare

La complessità dello stato non aumenta gradualmente con le feature: salta.

Aggiungere un secondo posto che legge gli stessi dati non è “il doppio del lavoro”. Introduce problemi di coordinamento: mantenere le viste consistenti, prevenire valori obsoleti, decidere cosa aggiorna cosa e gestire i tempi. Una volta che hai qualche pezzo di stato condiviso più lavoro asincrono, puoi ottenere comportamenti difficili da ragionare—anche se ogni singola feature sembra semplice da sola.

Troppe fonti di verità

Lo stato diventa doloroso quando lo stesso “fatto” è memorizzato in più posti. Ogni copia può scostarsi e la tua interfaccia comincia a litigare con se stessa.

I soliti sospetti

La maggior parte delle app finisce per avere diversi posti che possono contenere la “verità”:

• Dati server (API/database): il record canonico
• Cache client (es. cache di librerie di fetch): un mirror locale da aggiornare
• Stato UI locale (stato dei componenti): quello che l'utente sta facendo ora
• URL (path, query params, hash): stato che puoi mettere nei preferiti, condividere e ripristinare

Tutte queste sono proprietarie valide per alcuni stati. Il problema inizia quando provano tutte a possedere lo stesso stato.

Come avviene la duplicazione

Un pattern comune: fetchi i dati dal server, poi li copi nello stato locale “così posso modificarli”. Per esempio carichi un profilo utente e fai formState = userFromApi. Poi il server rifetch (o un'altra tab aggiorna il record) e ora hai due versioni: la cache dice una cosa, il form dice un'altra.

La duplicazione si insinua anche tramite trasformazioni “utili”: memorizzare sia items che itemsCount, o sia selectedId che selectedItem.

Sintomi che riconoscerai

Quando ci sono più fonti di verità, i bug tendono a suonare come:

• “Funziona solo su questa schermata.”
• L'interfaccia è incoerente dopo una navigazione o un refresh.
• I dati sembrano corretti in un componente ma obsoleti in un altro.
• Il salvataggio ha successo, ma la lista non si aggiorna (o si aggiorna due volte).

Regola pratica

Per ogni pezzo di stato, scegli un solo proprietario—il posto in cui si fanno gli aggiornamenti—e tratta tutto il resto come una proiezione (in sola lettura, derivata o sincronizzata in una sola direzione). Se non riesci a indicare il proprietario, probabilmente stai memorizzando la stessa verità due volte.

Lavori asincroni ed effetti collaterali rendono lo stato complicato

Molto dello stato frontend sembra semplice perché è sincrono: un utente clicca, imposti un valore, l'interfaccia si aggiorna. Gli effetti collaterali rompono quella storia passo‑per‑passo.

Cosa conta come effetto collaterale?

Gli effetti collaterali sono azioni che raggiungono fuori dal puro modello “render basato sui dati” di un componente:

• Chiamate di rete (fetch, salvataggi, retry)
• Timer e debouncing (setTimeout, intervalli)
• Sottoscrizioni (web socket, listener di eventi)
• Memorizzazione nel browser (localStorage/sessionStorage)

Ognuno di questi può scattare dopo, fallire inaspettatamente o eseguirsi più volte.

Perché lo stato asincrono è più difficile dello stato sincrono

Gli aggiornamenti asincroni introducono il tempo come variabile. Non ragioni più su “cosa è successo”, ma su “cosa potrebbe ancora essere in corso”. Due richieste possono sovrapporsi. Una risposta lenta può arrivare dopo una più veloce. Un componente può smontarsi mentre una callback asincrona tenta ancora di aggiornare lo stato.

Ecco perché i bug spesso si presentano come:

• Flag di caricamento rimasti bloccati (il percorso d'errore non li ha resettati o la richiesta è stata cancellata)
• UI che lampeggia dati vecchi (valore cache obsoleto mostrato come “finale”)
• Risposte fuori ordine che sovrascrivono quelle più nuove (la richiesta A termina dopo la B)

Una strategia semplice: modellare esplicitamente la richiesta

Invece di spargere booleani come isLoading nell'interfaccia, tratta il lavoro asincrono come una piccola macchina a stati:

• idle (niente iniziato)
• loading (in corso)
• success (dati disponibili)
• error (errore catturato)

Tieni insieme i dati e lo status, e conserva un identificatore (come un request id o una query key) così puoi ignorare risposte arrivate in ritardo. Questo rende la domanda “cosa dovrebbe mostrare ora l'interfaccia?” una decisione semplice, non un azzardo.

Stato UI vs Stato Server (sembrano simili, ma non lo sono)

Molti problemi di stato iniziano da una confusione semplice: trattare “quello che l'utente sta facendo ora” come identico a “quello che il backend dice essere vero”. Entrambi possono cambiare nel tempo, ma seguono regole diverse.

Stato UI: cosa sta facendo l'interfaccia

Lo stato UI è temporaneo e guidato dall'interazione. Esiste per renderizzare lo schermo come l'utente se lo aspetta in questo momento.

Esempi: modali aperti/chiusi, filtri attivi, bozza di ricerca, hover/focus, tab selezionata e UI di paginazione (pagina corrente, dimensione pagina, posizione di scorrimento).

Questo stato è di solito locale a una pagina o a un albero di componenti. Va bene se si resetta alla navigazione.

Stato server: quello che hai fetchato (e che può cambiare altrove)

Lo stato server è il dato dall'API: profili utente, liste di prodotti, permessi, notifiche, impostazioni salvate. È la “verità remota” che può cambiare senza che la tua UI faccia nulla (qualcun altro la modifica, il server la ricalcola, un job in background la aggiorna).

Poiché è remoto, ha anche bisogno di metadata: stati di caricamento/errore, timestamp della cache, tentativi e invalidazione.

Perché miscelarli crea confusione

Se memorizzi bozze dell'interfaccia dentro i dati server, un refetch può cancellare le modifiche locali. Se metti risposte server nello stato UI senza regole di caching, combatterai dati obsoleti, fetch duplicati e schermate incoerenti.

Un fallimento comune: l'utente modifica un form mentre un refetch di background finisce e la risposta in arrivo sovrascrive la bozza.

Linea guida pratica

Gestisci lo stato server con pattern di caching (fetch, cache, invalidate, refetch on focus) e trattalo come condiviso e asincrono.

Gestisci lo stato UI con strumenti UI (stato locale del componente, context per questioni UI veramente condivise) e tieni le bozze separate finché non decidi esplicitamente di “salvarle” sul server.

Stato derivato e la regola “non memorizzare ciò che puoi calcolare”

Lo stato derivato è qualsiasi valore che puoi calcolare da altri stati: un totale del carrello dai line items, una lista filtrata dalla lista originale + query di ricerca, o un flag canSubmit dai valori dei campi e dalle regole di validazione.

È tentante memorizzare questi valori perché comodo (“tengo anche total nello stato”). Ma appena gli input cambiano in più posti rischi la deriva: il total memorizzato non corrisponde più agli articoli, la lista filtrata non riflette la query corrente, o il pulsante di invio resta disabilitato dopo aver corretto un errore. Questi bug sono frustranti perché nulla sembra “sbagliato” isolatamente—ogni variabile di stato è valida da sola, semplicemente incoerente con il resto.

Preferisci selector / valori calcolati

Un pattern più sicuro è: memorizza la minima fonte di verità e calcola tutto il resto al momento della lettura. In React questo può essere una funzione semplice o un calcolo memoizzato.

const items = useCartItems();
const total = items.reduce((sum, item) => sum + item.price * item.qty, 0);

const filtered = products.filter(p => p.name.includes(query));

Nelle app più grandi, i “selector” (o getter computati) formalizzano questa idea: un solo posto definisce come derivare total, filteredProducts, visibleTodos, e ogni componente usa la stessa logica.

Quando è accettabile cacheare valori derivati

Calcolare a ogni render di solito va bene. Fai caching quando hai misurato un costo reale: trasformazioni pesanti, liste enormi o valori derivati condivisi tra molti componenti. Usa memoizzazione (useMemo, memoizzazione dei selector) così le chiavi di cache sono i veri input—altrimenti torni alla deriva, semplicemente con l'obiettivo delle prestazioni.

Globale vs Locale: scegliere il proprietario giusto

Lo stato diventa frustrante quando non è chiaro chi ne è proprietario.

Cosa significa “proprietà”

Il proprietario di un pezzo di stato è il posto nella tua app che ha il diritto di aggiornarlo. Altre parti dell'interfaccia possono leggerlo (via props, context, selector, ecc.), ma non dovrebbero cambiarlo direttamente.

Una proprietà chiara risponde a due domande:

• Chi può aggiornare questo valore? (il proprietario)
• Chi può leggerlo? (i consumatori)

Quando quei confini si confondono, ottieni aggiornamenti in conflitto, momenti di “perché è cambiato questo?” e componenti difficili da riutilizzare.

Stato globale: comodo, ma l'accoppiamento si insinua

Mettere lo stato in uno store globale (o context di alto livello) può sembrare pulito: tutto può accedervi e eviti il prop drilling. Il compromesso è accoppiamento non intenzionale—all'improvviso schermate non correlate dipendono dagli stessi valori e piccole modifiche si propagano in tutta l'app.

Lo stato globale è adatto a cose veramente trasversali, come la sessione utente corrente, feature flag a livello app o una coda di notifiche condivisa.

Solleva lo stato—solo fino a dove serve

Un pattern comune è partire locale e “sollevare” lo stato al genitore comune più vicino solo quando due parti sorelle devono coordinarsi.

Se solo un componente lo usa, tienilo lì. Se più componenti lo usano, sollevalo al proprietario condiviso più piccolo. Se molte aree distanti lo usano, allora considera il globale.

Un'euristica semplice

Tieni lo stato vicino a dove viene usato salvo quando è richiesto condivisione.

Questo mantiene i componenti più semplici da capire, riduce le dipendenze accidentali e rende i refactor futuri meno spaventosi perché meno parti dell'app possono mutare gli stessi dati.

Concorrenza, race e aggiornamenti fuori ordine

Le app frontend sembrano “single‑threaded”, ma input utente, timer, animazioni e richieste di rete corrono indipendenti. Ciò significa che più aggiornamenti possono essere in volo contemporaneamente—e non finiscono necessariamente nell'ordine in cui li hai avviati.

Quando gli aggiornamenti collidono

Una collisione comune: due parti dell'interfaccia aggiornano lo stesso stato.

• Una casella di ricerca aggiorna query a ogni battitura.
• Un dropdown filtro aggiorna query (o la stessa lista di risultati) quando viene cambiato.

Individualmente ognuno è corretto. Insieme possono sovrascriversi a seconda dei tempi. Peggio ancora, potresti mostrare risultati per una query precedente mentre l'interfaccia mostra i nuovi filtri.

Race condition: utenti veloci, reti lente

Le race condition emergono quando lanci la richiesta A e poi rapidamente la richiesta B—ma la A torna per ultima.

Esempio: l'utente digita “c”, “ca”, “cat”. Se la richiesta per “c” è lenta e quella per “cat” è veloce, l'interfaccia potrebbe mostrare brevemente i risultati per “cat” e poi essere sovrascritta dai risultati obsoleti di “c” quando quella risposta arriva.

Il bug è sottile perché tutto “ha funzionato”—solo nell'ordine sbagliato.

Tecniche che riducono i bug fuori ordine

In genere vuoi una di queste strategie:

1. Cancella la richiesta precedente quando una nuova la sostituisce (es. con AbortController).
2. Ignora risposte stale controllando se la risposta corrisponde ancora agli input più recenti.
3. Usa request ID / numeri di sequenza e accetta solo la più recente.

Un semplice approccio con request ID:

let latestRequestId = 0;

async function fetchResults(query) {
  const requestId = ++latestRequestId;
  const res = await fetch(`/api/search?q=${encodeURIComponent(query)}`);
  const data = await res.json();

  if (requestId !== latestRequestId) return; // stale response
  setResults(data);
}

Aggiornamenti ottimistici (e come possono fallire)

Gli aggiornamenti ottimistici rendono l'interfaccia istantanea: aggiorni lo schermo prima che il server confermi. Ma la concorrenza può rompere le assunzioni:

• L'utente clicca “Mi piace” due volte velocemente (mi piace → non mi piace), ma le richieste risolvono fuori ordine.
• Decrementi ottimisticamente l'inventario, poi un fallimento successivo impone un rollback—tranne che l'utente ha già navigato via o fatto altre modifiche.

Per mantenere l'ottimismo sicuro, di solito hai bisogno di una regola di riconciliazione chiara: traccia l'azione pendente, applica le risposte del server in ordine e, se devi fare rollback, fallo rispetto a un checkpoint noto (non “a qualunque cosa l'interfaccia mostri ora”).

Prestazioni: quando gli aggiornamenti di stato costano troppo

Gli aggiornamenti di stato non sono “gratuiti”. Quando lo stato cambia, l'app deve capire quali parti dello schermo potrebbero essere interessate e poi fare il lavoro per riflettere la nuova realtà: ricalcolare valori, ri-renderizzare UI, rieseguire logica di formattazione e talvolta rifetchare o rivalidare dati. Se quella reazione a catena è più grande del necessario, l'utente lo avverte come lag, scatti o pulsanti che sembrano “pensare” prima di rispondere.

Perché un piccolo cambiamento può sembrare grande

Un singolo toggle può innescare molto lavoro extra:

• Ampie sezioni dell'interfaccia si ri-renderizzano anche se è cambiata solo una piccola parte.
• Liste si ridisegnano e ricalcolano misure, causando scatti nello scroll.
• Oggetti e array vengono ricreati a ogni aggiornamento (“deep churn”), così l'app non riesce a capire cosa è effettivamente cambiato.

Il risultato non è solo tecnico—è esperienziale: scrivere sembra lento, le animazioni scattano e l'interfaccia perde quella qualità “reattiva” che associamo a prodotti rifiniti.

Trappole comuni sulle prestazioni

Una delle cause più comuni è uno stato troppo ampio: un oggetto “cestino” che contiene molte informazioni non correlate. Aggiornare un campo fa sembrare nuovo l'intero contenitore, quindi più UI si risvegliano del necessario.

Un'altra trappola è memorizzare valori calcolati nello stato e aggiornarli manualmente. Questo spesso crea aggiornamenti extra (e lavoro UI extra) solo per mantenere tutto sincronizzato.

Tattiche per mantenere l'interfaccia veloce

Dividi lo stato in fette più piccole. Tieni preoccupazioni non correlate separate così cambiare un input di ricerca non rinfreschi un'intera pagina di risultati.

Normalizza i dati. Invece di memorizzare lo stesso elemento in molti posti, memorizzalo una sola volta e riferiscilo. Questo riduce gli aggiornamenti ripetuti e previene “tempeste di cambiamento” dove una modifica forza la riscrittura di molte copie.

Memoizza valori derivati. Se un valore può essere calcolato da altri stati (come risultati filtrati), fai caching del calcolo così si riesegue solo quando gli input cambiano davvero.

L'obiettivo: meno rallentamenti, meno sorprese

Una buona gestione dello stato orientata alle prestazioni riguarda la contenimento: gli aggiornamenti dovrebbero interessare l'area più piccola possibile ed il lavoro costoso dovrebbe avvenire solo quando serve davvero. Quando questo è vero, gli utenti smettono di notare il framework e cominciano a fidarsi dell'interfaccia.

Debuggare e testare lo stato senza indovinare

I bug di stato spesso sembrano personali: l'interfaccia è “sbagliata”, ma non sai rispondere alla domanda più semplice—chi ha cambiato questo valore e quando? Se un numero cambia, un banner scompare o un pulsante si disabilita, ti serve una timeline, non un'ipotesi.

Rendi gli aggiornamenti tracciabili (non misteriosi)

La via più veloce alla chiarezza è un flusso di aggiornamento prevedibile. Che tu usi reducer, eventi o uno store, punta a un pattern dove:

• I cambiamenti avvengono tramite un piccolo set di azioni ben nominate (non mutazioni casuali)
• Ogni azione ha un payload chiaro (setShippingMethod('express'), non updateStuff)
• Puoi loggare azioni e transizioni di stato risultanti in modo consistente

Un logging chiaro delle azioni trasforma il debugging da “fissare lo schermo” a “seguire la ricevuta”. Anche semplici console log (nome azione + campi chiave) battono cercare di ricostruire cosa è successo dai sintomi.

Testa la logica dove è stabile

Non cercare di testare ogni re-render. Invece, testa le parti che dovrebbero comportarsi come logica pura:

• Unit test per reducer / updater di stato: dato uno stato precedente + azione, asserisci il prossimo stato
• Unit test per selector / calcoli derivati: dato uno stato, asserisci l'output calcolato
• Integration test per i flussi utente chiave: login → carica dati → modifica → salva → mostra conferma

Questa combinazione cattura sia i “bug matematici” sia i problemi di wiring nel mondo reale.

Aggiungi strumentazione leggera per i bug asincroni

I problemi asincroni si nascondono nelle falle. Aggiungi metadata minimali che rendano visibili le timeline:

• timestamp sugli aggiornamenti importanti
• request ID (allega l'ID ad azioni e risposte)

Così quando una risposta in ritardo sovrascrive una più nuova puoi provarlo immediatamente—e correggerlo con sicurezza.

Scegliere un approccio di gestione dello stato (senza guerre di tool)

Scegliere uno strumento di stato è più facile quando lo tratti come esito di decisioni di design, non come punto di partenza. Prima di confrontare librerie, mappa i confini dello stato: cosa è puramente locale a un componente, cosa va condiviso e cosa è veramente “dati server” che fetchi e sincronizzi.

Criteri di selezione che contano

Un modo pratico per decidere è guardare alcuni vincoli:

• Dimensione e durata dell'app: uno strumento interno piccolo può rimanere semplice; un prodotto che vive a lungo beneficia di convenzioni più forti.
• Abitudini del team: scegli qualcosa che il team possa usare in modo coerente (e rivedere con sicurezza).
• Necessità asincrone: fetch pesanti, caching, paginazione e mutazioni cambiano l'equazione.
• Complessità dello stato: workflow cross‑page, undo/redo e form multi‑step spesso richiedono più struttura.

Confronto ad alto livello (senza ideologia)

• Context + hooks: ottimo per dependency injection e valori condivisi a bassa frequenza (tema, info auth). Può funzionare anche per stato, ma aggiornamenti frequenti possono diventare rumorosi senza pattern aggiuntivi.
• Store stile Redux: forti convenzioni, aggiornamenti prevedibili e ottimo tooling. Ideale quando servono tracce chiare e coordinazione complessa tra feature.
• Atom store (stato a grana fine): ergonomico per stato condiviso senza scrivere tanti reducer. Spesso più facile da scalare incrementando gradualmente.
• Query cache (strumenti per server‑state): specializzati per fetch, caching, deduping, refetch di background e mutazioni. Ridimensionano una grande classe di codice “colla” asincrono.

Evita il pensiero guidato dagli strumenti

Se inizi con “usiamo X ovunque”, finirai per memorizzare le cose sbagliate nei posti sbagliati. Parti dalla proprietà: chi aggiorna questo valore, chi lo legge e cosa dovrebbe succedere quando cambia.

Spesso la combinazione di strumenti è la scelta migliore

Molte app funzionano bene con una libreria per lo stato server per i dati API più una piccola soluzione per lo stato UI per questioni client‑only come modali, filtri o bozze di form. L'obiettivo è chiarezza: ogni tipo di stato vive dove è più facile ragionarci sopra.

Dove si inserisce Koder.ai

Se stai iterando su confini di stato e flussi asincroni, Koder.ai può accelerare il ciclo “prova, osserva, affina”. Perché genera frontend React (e backend Go + PostgreSQL) da chat con un workflow agent‑based, puoi prototipare modelli di ownership alternativi (locale vs globale, cache server vs bozze UI) velocemente, quindi mantenere la versione che resta prevedibile.

Due funzionalità pratiche aiutano quando sperimenti lo stato: Planning Mode (per delineare il modello di stato prima di costruire) e snapshot + rollback (per testare refactor come “rimuovi stato derivato” o “introduci request ID” senza perdere una baseline funzionante).

Una checklist pratica per rendere lo stato meno doloroso

Lo stato diventa più semplice quando lo tratti come un problema di design: decidi chi lo possiede, cosa rappresenta e come cambia. Usa questa checklist quando un componente comincia a sembrare “misterioso”.

1) Chiarisci la proprietà e la singola fonte di verità

Chiedi: Quale parte dell'app è responsabile di questi dati? Metti lo stato il più vicino possibile a dove viene usato e sollevalo solo quando più parti ne hanno davvero bisogno.

• Un proprietario per ogni pezzo di stato.
• Passa i dati verso il basso; invia le modifiche verso l'alto tramite callback/eventi.
• Se due posti possono aggiornare lo stesso valore, non hai una fonte di verità—hai un conflitto in arrivo.

2) Evita duplicazioni e modella i valori derivati

Se puoi calcolare qualcosa da altro stato, non memorizzarlo.

• Conserva gli input minimi (es. items, filterText).
• Calcola gli output (es. visibleItems) durante il render o via memoizzazione.

3) Rendi espliciti gli stati asincroni (non impliciti)

Il lavoro asincrono è più chiaro quando lo modelli direttamente:

• Preferisci una piccola forma di “request state”: status: 'idle' | 'loading' | 'success' | 'error', più data ed error.
• Tratta “loading” e “error” come stati UI di prima classe, non booleani sparsi.

4) Fai attenzione agli antipattern comuni

• Copiare props nello stato “per ogni evenienza” (crea deriva).
• Globalizzare tutto (accoppia schermate non correlate).
• Zuppa di booleani (isLoading, isFetching, isSaving, hasLoaded, …) invece di un unico status.

5) Refactor in passi piccoli e sicuri

• Separa stato misto: dividi le preoccupazioni UI (aperto/chiuso, testo input) dai dati server.
• Elimina valori derivati memorizzati e calcolali dalla fonte vera.
• Centralizza gli effetti collaterali (fetch, sottoscrizioni) in un solo posto per feature.

Obiettivi pratici

Punta a meno bug del tipo “come è finito in questo stato?”, cambiamenti che non richiedono toccare cinque file e un modello mentale dove puoi indicare un solo posto e dire: qui vive la verità.