Como você modela async/loading state?

Question

IT Interview Practice · Accepted Answer

Operações assíncronas (chamadas de API) têm múltiplos resultados possíveis, portanto você deve modelar **mais do que apenas os dados** — você precisa representar loading, success e error states. Modelar isso bem evita bugs de UI como mostrar dados obsoletos ou nenhum feedback. ## The naive approach and its flaws ```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. ``` Flags independentes permitem combinações contraditórias (loading *e* error *e* dados ao mesmo tempo) que deveriam ser impossíveis — uma fonte de bugs de UI confusos. ## Better: a status enum (a small 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 }); } } ``` Um único campo `status` torna os estados **mutuamente exclusivos** — você não pode estar carregando e com erro ao mesmo tempo. Renderizar se torna um switch limpo: ```jsx switch (state.status) { case "loading": return ; case "error": return ; case "success": return ; default: return ; } ``` ## Don't forget the often-missed 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) ``` ## The best approach for server data: use a library ```jsx // React Query / SWR model all of this for you const { data, isLoading, isError, error } = useQuery({ queryKey: ["x"], queryFn }); ``` Bibliotecas de server-state fornecem esses estados (mais caching, refetch, stale-while-revalidate) prontos para uso — geralmente melhor do que criar o seu próprio. ## Por que isso importa Modelar adequadamente async state — como um único status em vez de booleans soltos — elimina toda uma classe de bugs de UI (estados contraditórios, feedback faltando em loading/error/empty) e torna a lógica de renderização limpa e exaustiva. Reconhecer o conjunto completo de estados (idle, loading, success, error, empty, refetching) leva a uma melhor UX, e saber que as bibliotecas de server-state lidam com tudo isso é o que mantém o código de busca de dados simples e robusto.

The naive approach and its flaws

Better: a status enum (a small state machine)

Don't forget the often-missed states

The best approach for server data: use a library

Por que isso importa

Perguntas relacionadas