Gestione dello stato in React: mantienila noiosa nelle app generate

Cosa va storto con lo stato nelle app React reali

Lo stato è qualsiasi dato che può cambiare mentre la tua app è in esecuzione. Include quello che vedi (una modal aperta), quello che stai modificando (una bozza di form) e i dati che recuperi (una lista di progetti). Il problema è che tutto questo viene chiamato "stato", anche se si comportano in modo molto diverso.

La maggior parte delle app disordinate si rompe nello stesso modo: troppi tipi di stato vengono mescolati nello stesso posto. Un componente finisce per contenere dati server, flag UI, bozze di form e valori derivati, e poi prova a tenerli allineati con effetti. Prima o poi non sai più rispondere a domande semplici come "da dove viene questo valore?" o "chi lo aggiorna?" senza cercare in più file.

Le app React generate si ritrovano più rapidamente in questa situazione perché è facile accettare la prima versione funzionante. Aggiungi una nuova schermata, copi un pattern, sistemi un bug con un altro useEffect e ora hai due fonti di verità. Se il generatore o il team cambia direzione a metà strada (stato locale qui, store globale là), il codebase colleziona pattern invece di costruire su uno solo.

L'obiettivo è noioso: meno tipi di stato e meno posti da controllare. Quando c'è una casa ovvia per i dati server e una casa ovvia per lo stato solo UI, i bug diventano più piccoli e le modifiche smettono di sembrare rischiose.

"Mantienilo noioso" significa seguire poche regole:

• Non duplicare i dati server nello stato client a meno che non ci sia una ragione chiara.
• Non promuovere lo stato UI locale a uno store globale solo perché potrebbe servire in futuro.
• Non trasformare valori derivati in stato a meno che il loro calcolo non sia davvero costoso.

Un esempio concreto: se una lista di utenti viene dal backend, trattala come server state e falla fetchare dove viene usata. Se selectedUserId esiste solo per pilotare un pannello dettagli, tienilo come stato UI vicino a quel pannello. Mescolare i due è l'inizio della complessità.

Stato server vs stato client in parole semplici

La maggior parte dei problemi di stato in React inizia con una confusione: trattare i dati server come stato UI. Separa prima i due e la gestione dello stato resta calma, anche quando l'app cresce.

Lo stato server appartiene al backend: utenti, ordini, task, permessi, prezzi, feature flag. Può cambiare senza che la tua app faccia nulla (un'altra tab lo aggiorna, un admin lo modifica, un job lo aggiorna, i dati scadono). Poiché è condiviso e modificabile, serve fetching, caching, refetching e gestione degli errori.

Lo stato client è quello che interessa solo alla tua UI in questo momento: quale modal è aperta, quale tab è selezionata, un toggle di filtro, l'ordine di ordinamento, una sidebar compressa, una bozza di ricerca. Se chiudi la scheda, può andare bene perderlo.

Un test rapido è: "Potrei ricaricare la pagina e ricostruire questo dal server?"

• Se sì, è probabilmente server state.
• Se no, è probabilmente client state.

Esiste anche lo stato derivato, che ti evita di creare stato extra. È un valore che puoi calcolare da altri valori, quindi non lo memorizzi. Liste filtrate, totali, isFormValid e "mostra stato vuoto" di solito appartengono qui.

Esempio: recuperi una lista di progetti (server state). Il filtro selezionato e la flag del dialog "Nuovo progetto" sono client state. La lista visibile dopo il filtro è stato derivato. Se memorizzi la lista visibile separatamente, si sfaserà e ti ritroverai a inseguire bug del tipo "perché è obsoleta?".

Questa separazione aiuta quando uno strumento come Koder.ai genera schermate velocemente: tieni i dati backend in uno strato di fetching, tieni le scelte UI vicino ai componenti e evita di salvare valori calcolati.

Un set di regole noioso che previene la maggior parte dei problemi

Lo stato diventa doloroso quando un pezzo di dati ha due proprietari. Il modo più veloce per mantenere le cose semplici è decidere chi possiede cosa e rispettarlo.

• Tratta i dati API come qualcosa da fetchare e cachare, non come qualcosa da mantenere manualmente nello stato del componente.
• Non clonare i dati fetchati nello stato locale "per sicurezza". Le copie creano deriva.
• Mantieni lo stato client vicino al luogo in cui è usato. Rialzalo solo quando parti separate dell'albero ne hanno veramente bisogno.
• Salva ID e flag piccoli, non oggetti interi. Ricalcola l'oggetto dalla cache quando renderizzi.

Esempio: fetchi una lista di utenti e mostri i dettagli quando uno è selezionato. Un errore comune è salvare l'intero oggetto utente selezionato nello stato. Salva selectedUserId invece. Tieni la lista nella cache server. La vista dettagli cerca l'utente per ID, così i refetch aggiornano la UI senza codice di sincronizzazione extra.

Nelle app React generate, è facile accettare stato "utile" generato che duplica i dati server. Quando vedi codice che fa fetch -> setState -> edit -> refetch, fermati. Spesso è il segno che stai costruendo un secondo database nel browser.

Come gestire lo stato server senza pensarci troppo

Lo stato server è tutto ciò che vive nel backend: liste, pagine di dettaglio, risultati di ricerca, permessi, conteggi. L'approccio noioso è scegliere uno strumento per questo e restarci. Per molte app React, TanStack Query è sufficiente.

L'obiettivo è semplice: i componenti chiedono i dati, mostrano loading e error, e non si preoccupano di quante chiamate fetch avvengono sotto il cofano. Questo è importante nelle app generate perché piccole incongruenze si moltiplicano velocemente con nuove schermate.

Tratta le chiavi di query come un sistema di naming, non come un ripensamento. Mantienile coerenti: chiavi array stabili, includi solo gli input che cambiano il risultato (filtri, pagina, ordinamento) e preferisci poche forme prevedibili rispetto a molte eccezioni. Molti team mettono la costruzione delle key in helper piccoli in modo che ogni schermata usi le stesse regole.

Per le scritture, usa mutations con gestione esplicita del successo. Una mutation dovrebbe rispondere a due domande: cosa è cambiato e cosa deve fare la UI dopo?

Esempio: crei un nuovo task. Al successo, o invalidi la query della lista tasks (così si ricarica) oppure fai un aggiornamento mirato della cache (aggiungi il nuovo task alla lista cached). Scegli un approccio per funzionalità e mantienilo coerente.

Se ti senti tentato di aggiungere chiamate di refetch in più posti "per sicurezza", scegli una mossa noiosa invece:

• Invalida la chiave di query esatta che è diventata stale.
• Aggiorna la cache per la query esatta che è cambiata.
• Naviga verso una schermata che già fetcha la query corretta.

Pattern di stato client che restano piccoli

Lo stato client è ciò che il browser possiede: una flag di sidebar aperta, una riga selezionata, testo di filtro, una bozza prima di salvare. Tienilo vicino al punto di utilizzo e generalmente resta gestibile.

Parti in piccolo: useState nel componente più vicino. Quando generi schermate (per esempio con Koder.ai), è tentante mettere tutto in uno store globale "per sicurezza". È così che finisci con uno store che nessuno capisce.

Una semplice regola di promozione

Sposta lo stato verso l'alto solo quando sai nominare il problema di condivisione.

• Mantieni lo stato UI locale per default.
• Rialzalo al genitore comune più vicino quando i componenti fratelli ne hanno bisogno.
• Usa un piccolo shared store solo quando più route o componenti distanti hanno veramente bisogno dello stesso valore nello stesso momento.

Esempio: una tabella con un pannello dettagli può tenere selectedRowId nel componente tabella. Se una toolbar in un'altra parte della pagina ne ha bisogno, rialzalo al componente pagina. Se una route separata (come bulk edit) ne ha bisogno, allora uno store piccolo può avere senso.

Forme di store che restano leggibili

Se usi uno store (Zustand o simili), tienilo focalizzato su un lavoro. Salva il "cosa" (ID selezionati, filtri), non i "risultati" (liste ordinate) che puoi derivare.

Quando uno store inizia a crescere, chiediti: è ancora una sola feature? Se la risposta sincera è "più o meno", dividilo ora, prima che la prossima feature lo trasformi in una palla di stato che fai fatica a toccare.

Form, bozze e stato UI temporaneo

I bug dei form spesso vengono dalla mescolanza di tre cose: quello che l'utente sta digitando, quello che il server ha salvato e quello che la UI mostra.

Per una gestione noiosa dello stato, tratta il form come client state finché non invii. I dati server sono l'ultima versione salvata. Il form è una bozza. Non modificare l'oggetto server in place. Copia i valori nello stato bozza, lascia che l'utente li cambi liberamente, poi invia e refetcha (o aggiorna la cache) al successo.

Decidi presto cosa deve persistere quando l'utente naviga via. Quella singola scelta previene molte sorprese. Per esempio, una modalità inline edit e dropdown aperti dovrebbero di solito resettarsi, mentre una bozza di wizard lunga o un messaggio non inviato potrebbe persistere. Persisti attraverso il reload solo quando gli utenti se lo aspettano chiaramente (come in un checkout).

Tieni le regole di validazione in un solo posto. Se disperdi regole tra input, handler di submit e helper, finirai con errori non corrispondenti. Preferisci uno schema (o una funzione validate()), e lascia che la UI decida quando mostrare gli errori (on change, on blur o on submit).

Esempio: generi una schermata Edit Profile in Koder.ai. Carica il profilo salvato come server state. Crea stato bozza per i campi del form. Mostra "modifiche non salvate" confrontando bozza vs salvato. Se l'utente cancella, scarta la bozza e mostra la versione server. Se salva, invia la bozza, poi sostituisci la versione salvata con la risposta del server.

Passo dopo passo: semplificare una configurazione di stato disordinata

Man mano che un'app generata cresce, è comune ritrovarsi con gli stessi dati in tre posti: stato del componente, uno store globale e una cache. La correzione di solito non è una nuova libreria. È scegliere una casa per ogni pezzo di stato.

Un flusso di pulizia che funziona nella maggior parte delle app:

1. Fai l'inventario dello stato. Elenca quello che hai (liste, elemento selezionato, filtri, modali, bozze) e etichetta ciascuno come server o client.
2. Elimina i duplicati. Rimuovi stato come filteredUsers se puoi calcolarlo da users + filter. Preferisci selectedUserId rispetto a un selectedUser duplicato.
3. Metti il fetching in un solo strato. Usa un approccio server-state in modo che caching, refetching e invalidation abbiano un solo regolamento.
4. Aggiungi un piccolo client store solo dove si guadagna davvero (bisogni UI cross-page come una bozza di wizard).
5. Blocca regole di naming così il disordine non ritorna.

Esempio: un'app CRUD generata da Koder.ai spesso parte con un useEffect che fetcha più una copia globale dello stesso elenco. Dopo aver centralizzato lo stato server, la lista proviene da una sola query e "refresh" diventa invalidation invece di syncing manuale.

Per il naming, mantienilo coerente e noioso:

• Query: users.list, users.detail(id)
• Stato client: ui.isCreateModalOpen, filters.userSearch
• Azioni: openCreateModal(), setUserSearch(value)
• Scritture server: users.create, users.update, users.delete

L'obiettivo è una sola fonte di verità per ogni cosa, con confini chiari tra stato server e stato client.

Segnali precoci che la complessità dello stato sta per esplodere

I problemi di stato iniziano piccoli, poi un giorno cambi un campo e tre parti della UI non sono d'accordo sul valore "reale".

Il segnale più chiaro è il dato duplicato: lo stesso utente o carrello vive in un componente, uno store globale e una cache di richiesta. Ogni copia si aggiorna a tempi diversi e aggiungi altro codice solo per tenerle uguali.

Un altro segnale è il codice di sincronizzazione: effetti che spingono stato avanti e indietro. Pattern come "quando la query cambia, aggiorna lo store" e "quando lo store cambia, refetch" possono funzionare finché un caso limite non provoca valori obsoleti o loop.

Alcuni segnali di pericolo rapidi:

• Non riesci a spiegare "da dove viene questo valore" e "chi lo possiede" in una frase.
• Il tuo store o reducer importa client API o conosce codici di stato HTTP.
• Ogni nuova schermata aggiunge flag condivisi come needsRefresh, didInit, isSaving che nessuno rimuove.
• Stai scrivendo effetti principalmente per specchiare uno stato in un altro.
• Risolvere un bug significa aggiornare lo stesso campo in più layer.

Esempio: generi una dashboard in Koder.ai e aggiungi una modal Edit Profile. Se i dati del profilo sono nella query cache, copiati in uno store globale e duplicati nello stato locale del form, ora hai tre fonti di verità. Appena aggiungi refetch in background o aggiornamenti ottimistici, compaiono incongruenze.

Quando vedi questi segnali, la mossa noiosa è scegliere un proprietario singolo per ogni pezzo di dato e cancellare i duplicati.

Trappole comuni e come evitarle

Salvare cose "nel caso servisse" è uno dei modi più rapidi per peggiorare lo stato, specialmente in app generate.

Copiare risposte API nello store globale è una trappola comune. Se i dati vengono dal server (liste, dettagli, profilo), non copiarli nello store client per default. Scegli una casa per i dati server (di solito la cache delle query). Usa lo store client per valori UI che il server non conosce.

Salvare valori derivati è un'altra trappola. Conteggi, liste filtrate, totali, canSubmit e isEmpty dovrebbero di solito essere calcolati dagli input. Se le prestazioni diventano un problema reale, memoizza dopo aver misurato, ma non iniziare salvando il risultato.

Un mega-store per tutto (auth, modali, toasts, filtri, bozze, flag onboarding) diventa una discarica. Dividi per confini di feature. Se lo stato è usato solo da una schermata, tienilo locale.

Context è ottimo per valori stabili (theme, user id corrente, locale). Per valori che cambiano spesso, può causare re-render estesi. Usa Context per wiring, e stato del componente (o un piccolo store) per valori UI che cambiano frequentemente.

Infine, evita naming incoerente. Chiavi di query e campi di store quasi identici creano duplicazioni sottili. Scegli uno standard semplice e seguilo.

Checklist rapida prima di aggiungere altro stato

Quando ti viene la voglia di aggiungere "solo un'altra" variabile di stato, fai un controllo rapido di proprietà.

Primo: puoi indicare un posto unico dove avviene fetching e caching server (uno strumento di query, un set di chiavi)? Se gli stessi dati vengono fetchati in più componenti e anche copiati in uno store, stai già pagando interessi.

Secondo: questo valore serve solo dentro una schermata (es. "pannello filtri aperto")? Se sì, non dovrebbe essere globale.

Terzo: puoi salvare un ID invece di duplicare un oggetto? Salva selectedUserId e leggi l'utente dalla cache o dalla lista.

Quarto: è derivato? Se lo puoi calcolare da stato esistente, non salvarlo.

Infine, fai il test di tracciamento di un minuto. Se un collega non riesce a rispondere "da dove viene questo valore?" (prop, stato locale, cache server, URL, store) in meno di un minuto, sistema la proprietà prima di aggiungere altro stato.

Esempio: una app CRUD che resta noiosa mentre cresce

Immagina una admin app generata (per esempio da un prompt in Koder.ai) con tre schermate: lista clienti, pagina dettaglio cliente e form di modifica.

Lo stato resta calmo quando ha case ovvie:

• Server state: lista clienti, record cliente, richieste di save/delete.
• Client state: filtri della lista, riga selezionata, bozza di modifica.

La lista e le pagine dettaglio leggono lo stato server dalla cache delle query. Quando salvi, non riscrivi i clienti nello store globale: mandi la mutation e lasci che la cache si aggiorni o venga invalidata.

Per la schermata di modifica, tieni la bozza del form locale. Inizializzala dal cliente fetchato, ma trattala come separata mentre l'utente digita. Così la vista dettaglio può aggiornarsi senza sovrascrivere modifiche a metà.

Un aggiornamento ottimistico noioso

L'UI ottimistica è un punto dove i team spesso duplicano tutto. Di solito non è necessario.

Quando l'utente preme Salva, aggiorna solo il record cached e l'item corrispondente nella lista, poi fai rollback se la richiesta fallisce. Tieni la bozza nel form finché il salvataggio non riesce. Se fallisce, mostra un errore e mantieni la bozza così l'utente può riprovare.

Quando una seconda feature vuole lo stesso stato

Supponiamo che aggiungi bulk edit che ha bisogno delle righe selezionate. Prima di creare un nuovo store, chiediti: questo stato deve sopravvivere a navigazione e refresh?

• Se sì, mettilo nell'URL (ID selezionati, filtri).
• Se no, tienilo nel componente pagina.
• Se più componenti distanti ne hanno davvero bisogno nello stesso momento (toolbar + tabella + footer), introduce un piccolo store condiviso solo per quello stato client.

Passi successivi: mantieni le regole coerenti nelle app generate

Le schermate generate possono moltiplicarsi velocemente, ed è ottimo finché ogni nuova schermata non porta le sue decisioni sullo stato.

Scrivete una breve nota di team nel repo: cosa è server state, cosa è client state e quale strumento possiede ciascuno. Mantienila sufficientemente breve perché la gente la segua.

Aggiungi un'abitudine nelle PR: etichettare ogni nuovo pezzo di stato come server o client. Se è server, chiedi "dove si carica, come è cached e cosa lo invalida?" Se è client, chiedi "chi lo possiede e quando si resetta?"

Se usi Koder.ai (koder.ai), Planning Mode può aiutare a decidere i confini di proprietà prima di generare nuove schermate. Snapshot e rollback ti danno un modo sicuro per sperimentare quando una modifica di stato va male.

Scegli una feature (come modifica profilo), applica le regole end-to-end e lascia che sia l'esempio che tutti copiano.