Come modellate lo stato asincrono/caricamento?

Question

IT Interview Practice · Accepted Answer

Le operazioni asincrone (chiamate API) hanno più risultati possibili, quindi dovete modellare **più che solo i dati** — dovete rappresentare gli stati di caricamento, successo e errore. Modellare bene questo previene bug UI come mostrare dati obsoleti o nessun feedback. ## La soluzione ingenua e i suoi difetti ```js // ❌ separate booleans — can represent impossible combinations const [data, setData] = useState(null); const [loading, setLoading] = useState(false); const [error, setError] = useState(null); // What does { loading: true, error: "x", data: [...] } even mean? An invalid state. ``` I flag indipendenti consentono combinazioni contraddittorie (caricamento *e* errore *e* dati contemporaneamente) che dovrebbero essere impossibili — una fonte di confusi bug UI. ## Meglio: un enum di stato (una piccola macchina a stati) ```js // ✅ a single `status` makes states mutually exclusive const [state, setState] = useState({ status: "idle", data: null, error: null }); // status is one of: 'idle' | 'loading' | 'success' | 'error' async function load() { setState({ status: "loading", data: null, error: null }); try { const data = await api.get(); setState({ status: "success", data, error: null }); } catch (e) { setState({ status: "error", data: null, error: e.message }); } } ``` Un singolo campo `status` rende gli stati **mutuamente esclusivi** — non potete essere sia caricando che errore. Il rendering diventa uno switch pulito: ```jsx switch (state.status) { case "loading": return ; case "error": return ; case "success": return ; default: return ; } ``` ## Non dimenticate gli stati spesso trascurati ```text idle — hasn't started yet (vs loading) empty — succeeded but no results (show "No items" not a blank screen) refetching— has old data AND is loading new (show data + a subtle spinner) ``` ## L'approccio migliore per i dati del server: usate una libreria ```jsx // React Query / SWR model all of this for you const { data, isLoading, isError, error } = useQuery({ queryKey: ["x"], queryFn }); ``` Le librerie di server-state forniscono questi stati (più caching, refetch, stale-while-revalidate) pronte all'uso — solitamente meglio che implementarli a mano. ## Perché è importante Modellare correttamente lo stato asincrono — come un singolo status anziché booleani sparsi — elimina un'intera classe di bug UI (stati contraddittori, feedback di caricamento/errore/vuoto mancanti) e rende la logica di rendering pulita ed esaustiva. Riconoscere l'insieme completo di stati (idle, loading, success, error, empty, refetching) porta a una migliore UX, e sapere che le librerie di server-state gestiscono tutto questo è ciò che mantiene il codice di data-fetching semplice e robusto.

La soluzione ingenua e i suoi difetti

Meglio: un enum di stato (una piccola macchina a stati)

Non dimenticate gli stati spesso trascurati

L'approccio migliore per i dati del server: usate una libreria

Perché è importante

Domande correlate