Wie modellierst du asynchrone/Loading-States?

Question

Accepted Answer

Asynchrone Operationen (API-Aufrufe) haben mehrere mögliche Ergebnisse, daher musst du **mehr als nur die Daten** modellieren — du musst Loading-, Success- und Error-States darstellen. Eine gute Modellierung verhindert UI-Bugs wie das Anzeigen veralteter Daten oder fehlende Rückmeldung. ## Der naive Ansatz und seine Mängel ```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. ``` Unabhängige Flags ermöglichen widersprüchliche Kombinationen (Loading *und* Error *und* Daten gleichzeitig), die unmöglich sein sollten — eine Quelle verwirrender UI-Bugs. ## Besser: ein Status-Enum (eine kleine State Machine) ```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 }); } } ``` Ein einzelnes `status`-Feld macht die States **sich gegenseitig ausschließend** — du kannst nicht gleichzeitig Loading und Error sein. Rendering wird zu einem sauberen Switch: ```jsx switch (state.status) { case "loading": return ; case "error": return ; case "success": return ; default: return ; } ``` ## Vergiss nicht die oft übersehenen States ```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) ``` ## Der beste Ansatz für Server-Daten: verwende eine Bibliothek ```jsx // React Query / SWR model all of this for you const { data, isLoading, isError, error } = useQuery({ queryKey: ["x"], queryFn }); ``` Server-State-Bibliotheken bieten diese States (plus Caching, Refetch, Stale-While-Revalidate) vorkonfiguriert — normalerweise besser als selbst implementiert. ## Warum es wichtig ist Asynchrone States korrekt zu modellieren — als einzelnen Status statt loser Booleans — eliminiert eine ganze Klasse von UI-Bugs (widersprüchliche States, fehlende Loading/Error/Empty-Rückmeldung) und macht Rendering-Logik sauber und erschöpfend. Die volle Menge von States zu erkennen (Idle, Loading, Success, Error, Empty, Refetching) führt zu besserer UX, und zu wissen, dass Server-State-Bibliotheken all das handhaben, ist das, was Daten-Fetching-Code einfach und robust hält.