Implementare manualmente gli aggiornamenti ottimistici

Gli aggiornamenti ottimistici manuali iniziano dallo stato locale del componente, inizializzato con i dati del server: const [items, setItems] = useState(serverItems). Questo stato locale è quello che viene visualizzato ed è quello che verrà modificato ottimisticamente. NON si devono modificare direttamente i dati recuperati dal server: è opportuno mantenere una copia locale sotto il proprio controllo.

Quando l'utente avvia una mutazione (facendo clic su "Aggiungi", "Mi piace" o "Elimina"), si esegue immediatamente l'aggiornamento dello stato prima di chiamare l'API: setItems(prev => [...prev, newItem]). La UI riflette subito la modifica. Solo dopo questo aggiornamento si invia la richiesta di rete effettiva.

Prima di eseguire l'aggiornamento ottimistico, si acquisisce lo stato corrente: const previousItems = items. Questa istantanea è il punto di destinazione del rollback. Se la chiamata API fallisce, si ripristina questo valore. È opportuno memorizzarlo in una variabile (non nello stato), perché serve solo per la durata della mutazione in sospeso.

Dopo l'aggiornamento ottimistico, si esegue la chiamata API in modo asincrono. La si racchiuda in try/catch. In caso di successo, è possibile eseguire nuovamente il recupero dei dati per sincronizzarsi con lo stato del server oppure considerare attendibile lo stato ottimistico, se il server restituirebbe gli stessi dati. In caso di errore, si utilizza lo stato precedente acquisito per il rollback.

Nel blocco catch della mutazione: setItems(previousItems). In questo modo lo stato torna a quello precedente all'aggiornamento ottimistico. Dopo il rollback, si mostri una notifica di errore. Gli utenti comprendono che gli errori rari possono verificarsi: ciò che non possono accettare è un'incoerenza silenziosa.

Dopo il rollback, si mostri un messaggio di errore: "Impossibile salvare le modifiche. Riprovare." con un pulsante Riprova che esegua nuovamente la stessa mutazione. In questo modo si lascia il controllo agli utenti. La combinazione di rollback, toast di errore e possibilità di riprovare gestisce il caso di errore con eleganza senza bloccare l'intera UI.

Quando si aggiunge ottimisticamente un nuovo elemento, il server non gli ha ancora assegnato un ID reale. Si crei un ID temporaneo per l'elemento ottimistico: const tempId = crypto.randomUUID(). Lo si utilizzi come chiave dell'elemento nell'elenco. Dopo una risposta positiva dell'API, si sostituisca l'ID temporaneo con quello reale assegnato dal server.

Dopo una mutazione di creazione riuscita, il server restituisce l'ID reale. Si aggiorni lo stato sostituendo l'elemento temporaneo: setItems(prev => prev.map(item => item.id === tempId ? { ...item, id: serverResponse.id } : item)). Questa riconciliazione garantisce che le operazioni successive utilizzino l'ID corretto del server.

Se l'utente avvia due mutazioni in rapida successione, le risposte possono arrivare fuori ordine. La risposta della seconda mutazione potrebbe arrivare prima di quella della prima, e il rollback della prima potrebbe sovrascrivere lo stato corretto prodotto dalla seconda. Questa è una condizione di gara tipica della UI ottimistica.

Una soluzione alle race condition consiste nel serializzare le mutazioni usando una coda. Mentre una mutazione è in corso, disabiliti il pulsante che la attiva (impostando lo stato isSubmitting su true). Consenta la mutazione successiva solo dopo il completamento della precedente. Questo riduce in parte la reattività, ma garantisce il corretto ordine degli aggiornamenti dello stato.

Per le operazioni di eliminazione: salvi gli elementi precedenti, filtri dallo stato l'elemento eliminato, chiami l'API di eliminazione ed esegua il rollback in caso di errore. L'eliminazione è più semplice della creazione (non richiede la riconciliazione degli ID), ma gli stessi principi restano validi. Valuti la possibilità di aggiungere un breve ritardo prima dell'eliminazione (mostrando un'opzione "annulla") prima di effettuare la chiamata API.

Perché agli elementi aggiunti in modo ottimistico serve un ID temporaneo?

Il pattern manuale: salvi previousItems, imposti lo stato con setItems usando il nuovo stato, effettui la chiamata API, esegui il rollback in caso di errore con setItems(previousItems) e mostri un errore. Per le aggiunte, usi crypto.randomUUID() come ID temporaneo e riconcili l'ID con quello del server in caso di successo. Previeni le race condition disabilitando il trigger durante le mutazioni in corso. Rollback + toast + retry è la UX standard in caso di errore.