Máquinas de Estado para Lógica de UI - Modele estados complexos de UI como transições de estado finitas e explícitas

Q: Como a função reducer atua como a máquina de estado?

O switch externo em state.step (ou state.status) define em qual estado você está. Verificações if aninhadas em event.type definem quais transições são válidas nesse estado. O return state padrão ignora eventos que não são válidos para o estado atual.

Q: O que acontece se o reducer esquecer de retornar state para eventos não tratados?

O estado se torna undefined, o que pode travar o componente ou causar bugs silenciosos. Sempre adicione return state como o caso padrão para cada estado na instrução switch. O TypeScript pode ajudar a capturar isso com um tipo de retorno explícito no reducer.

Q: Por que evitar campos booleanos em objetos de estado?

n campos booleanos criam 2^n combinações possíveis, a maioria das quais são inválidas. Exemplo: { isLoading: true, isError: true } é um estado impossível que booleanas permitem. Correção: use uma única union discriminada com estados nomeados como "idle" | "loading" | "error" | "success".

Receita

// Máquina de estado simples com useReducer
type FetchState =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "success"; data: unknown }
  | { status: "error"; error: Error };
 
type FetchEvent =
  | { type: "FETCH" }
  | { type: "RESOLVE"; data: unknown }
  | { type: "REJECT"; error: Error }
  | { type: "RESET" };
 
function fetchReducer(state: FetchState, event: FetchEvent): FetchState {
  switch (state.status) {
    case "idle":
      if (event.type === "FETCH") return { status: "loading" };
      return state;
    case "loading":
      if (event.type === "RESOLVE") return { status: "success", data: event.data };
      if (event.type === "REJECT") return { status: "error", error: event.error };
      return state;
    case "error":
      if (event.type === "FETCH") return { status: "loading" };
      if (event.type === "RESET") return { status: "idle" };
      return state;
    case "success":
      if (event.type === "FETCH") return { status: "loading" };
      if (event.type === "RESET") return { status: "idle" };
      return state;
  }
}
 
const [state, send] = useReducer(fetchReducer, { status: "idle" });

Quando usar isso: Quando um componente tem múltiplos estados com transições restritas (por exemplo, um formulário de várias etapas, fluxo de trabalho assíncrono ou modal com estados de carregamento/erro/sucesso). Se você se encontrar gerenciando múltiplas booleanas como isLoading, isError, isSuccess, use uma máquina de estado em vez disso.

Exemplo de Trabalho

import { useReducer, useCallback, type ReactNode } from "react";
 
// --- Máquina de estado de formulário de várias etapas ---
 
interface FormData {
  name: string;
  email: string;
  plan: string;
}
 
type FormState =
  | { step: "details"; data: Partial<FormData> }
  | { step: "plan"; data: Partial<FormData> }
  | { step: "review"; data: FormData }
  | { step: "submitting"; data: FormData }
  | { step: "complete"; data: FormData }
  | { step: "error"; data: FormData; error: string };
 
type FormEvent =
  | { type: "NEXT"; fields: Partial<FormData> }
  | { type: "BACK" }
  | { type: "SUBMIT" }
  | { type: "SUCCESS" }
  | { type: "FAIL"; error: string }
  | { type: "RETRY" };
 
function formReducer(state: FormState, event: FormEvent): FormState {
  switch (state.step) {
    case "details":
      if (event.type === "NEXT") {
        return { step: "plan", data: { ...state.data, ...event.fields } };
      }
      return state;
 
    case "plan":
      if (event.type === "NEXT") {
        const data = { ...state.data, ...event.fields } as FormData;
        return { step: "review", data };
      }
      if (event.type === "BACK") return { step: "details", data: state.data };
      return state;
 
    case "review":
      if (event.type === "SUBMIT") return { step: "submitting", data: state.data };
      if (event.type === "BACK") return { step: "plan", data: state.data };
      return state;
 
    case "submitting":
      if (event.type === "SUCCESS") return { step: "complete", data: state.data };
      if (event.type === "FAIL") {
        return { step: "error", data: state.data, error: event.error };
      }
      return state;
 
    case "error":
      if (event.type === "RETRY") return { step: "submitting", data: state.data };
      if (event.type === "BACK") return { step: "review", data: state.data };
      return state;
 
    case "complete":
      return state; // Estado terminal
  }
}
 
function SignupWizard() {
  const [state, send] = useReducer(formReducer, {
    step: "details",
    data: {},
  });
 
  const handleSubmit = useCallback(async () => {
    send({ type: "SUBMIT" });
    try {
      await fetch("/api/signup", {
        method: "POST",
        body: JSON.stringify(state.step === "review" ? state.data : null),
      });
      send({ type: "SUCCESS" });
    } catch (err) {
      send({ type: "FAIL", error: (err as Error).message });
    }
  }, [state]);
 
  switch (state.step) {
    case "details":
      return (
        <DetailsStep
          data={state.data}
          onNext={(fields) => send({ type: "NEXT", fields })}
        />
      );
    case "plan":
      return (
        <PlanStep
          data={state.data}
          onNext={(fields) => send({ type: "NEXT", fields })}
          onBack={() => send({ type: "BACK" })}
        />
      );
    case "review":
      return (
        <ReviewStep
          data={state.data}
          onSubmit={handleSubmit}
          onBack={() => send({ type: "BACK" })}
        />
      );
    case "submitting":
      return <LoadingSpinner message="Criando sua conta..." />;
    case "error":
      return (
        <ErrorDisplay
          error={state.error}
          onRetry={() => send({ type: "RETRY" })}
          onBack={() => send({ type: "BACK" })}
        />
      );
    case "complete":
      return <SuccessMessage data={state.data} />;
  }
}

O que isso demonstra:

Tipos de union discriminada para estados - cada etapa carrega exatamente os dados que necessita
Guardas de transição explícitas - eventos só têm efeito no estado correto
Estados impossíveis são irrepresentáveis - sem confusão isLoading && isError
Efeitos colaterais (chamada de API) acionados por transições de estado, não espalhados por effects

Mergulho Profundo

Como Funciona

Uma máquina de estado define um conjunto finito de estados e um conjunto finito de eventos (transições) entre eles.
Cada estado determina quais eventos são válidos. Eventos inválidos são ignorados (ou podem gerar erro em desenvolvimento).
useReducer é o primitivo nativo do React para estados. A função reducer É a máquina de estado.
Tipos de union discriminada em TypeScript tornam a forma de cada estado explícita e permitem que o compilador imponha o tratamento exaustivo.
O switch em state.step (ou state.status) atua como o diagrama de estados; verificações if aninhadas em event.type definem transições válidas.

Parâmetros e Valores de Retorno

Conceito	Implementação	Propósito
Estado	Union discriminada	Representa todos os estados possíveis com dados associados
Evento	Union de `{ type: string; ... }`	Todas as entradas possíveis que acionam transições
Reducer	`(state, event) => state`	Função pura definindo a lógica da máquina de estado
Dispatch	`send(event)`	Aciona uma transição de estado

Variações

Condições de guarda - permitem transições apenas quando as condições são atendidas:

case "details":
  if (event.type === "NEXT") {
    if (!event.fields.name || !event.fields.email) {
      return { ...state, validationError: "Todos os campos são obrigatórios" };
    }
    return { step: "plan", data: { ...state.data, ...event.fields } };
  }
  return state;

Usando XState para máquinas complexas - quando a lógica de estado excede o que useReducer lida de forma limpa:

import { useMachine } from "@xstate/react";
import { createMachine, assign } from "xstate";
 
const toggleMachine = createMachine({
  id: "toggle",
  initial: "inactive",
  context: { count: 0 },
  states: {
    inactive: {
      on: {
        TOGGLE: {
          target: "active",
          actions: assign({ count: ({ context }) => context.count + 1 }),
        },
      },
    },
    active: {
      on: { TOGGLE: "inactive" },
    },
  },
});
 
function Toggle() {
  const [state, send] = useMachine(toggleMachine);
  return (
    <button onClick={() => send({ type: "TOGGLE" })}>
      {state.value} (alternado {state.context.count} vezes)
    </button>
  );
}

Notas de TypeScript

Use unions discriminadas (unions com tag) para tipos de estado. O discriminante (por exemplo, step, status) permite o estreitamento de tipo.
Sempre torne o switch exaustivo. O TypeScript avisará se você esquecer um estado quando o tipo de retorno for especificado.
Evite campos boolean em objetos de estado - eles criam 2^n estados possíveis. Use estados nomeados explícitos em vez disso.
XState v5 tem suporte de TypeScript de primeira classe com typegen para inferência de tipos de evento.

Armadilhas

Sopa de booleanas - Usar isLoading, isError, hasData como booleanas separadas cria combinações impossíveis como isLoading && isError. Correção: Substitua por um único estado de union discriminada.
Efeitos colaterais no reducer - Reducers devem ser funções puras. Chamadas de API ou mutações de DOM dentro do reducer quebram as regras do React e causam comportamento imprevisível. Correção: Acione efeitos colaterais fora do reducer com base nas transições de estado (em handlers de evento ou effects).
Esquecer o retorno padrão - Se o reducer não tratar um evento em um determinado estado e não retornar state, o estado se torna undefined. Correção: Sempre adicione return state como o padrão para eventos não tratados em cada caso de estado.
Exagero de engenharia para estado simples - Um toggle que está ligado ou desligado não precisa de uma máquina de estado. Correção: Use useState(false) para cenários triviais de dois estados. Recorra a máquinas quando você tiver 3+ estados ou transições complexas.

Alternativas

Abordagem	Trade-off
Máquina de estado `useReducer`	Nativo, sem dependências; lógica de transição manual
XState	Poderoso, ferramentas visuais; dependência extra, curva de aprendizado
Múltiplas booleanas `useState`	Simples para 1-2 estados; estados impossíveis se tornam possíveis
Zustand com campo de estado	Bom para máquinas de estado globais; não específico do React
`useActionState` (React 19)	Projetado para fluxos de submissão de formulário; limitado a ações de formulário

FAQs

O que é uma máquina de estado no contexto da lógica de UI do React?

Uma máquina de estado define um conjunto finito de estados e um conjunto finito de transições válidas entre eles.
Cada estado determina quais eventos são aceitos. Eventos inválidos são ignorados.
useReducer é o primitivo nativo do React para implementar máquinas de estado.

Por que tipos de union discriminada são importantes para máquinas de estado?

type FetchState =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "success"; data: unknown }
  | { status: "error"; error: Error };

Cada estado carrega exatamente os dados que necessita (por exemplo, data só existe em success).
O TypeScript estreita o tipo quando você usa switch no discriminante (status), prevenindo o acesso a campos inválidos.
Estados impossíveis como isLoading && isError tornam-se irrepresentáveis.

Quando você deve usar uma máquina de estado em vez de múltiplas booleanas `useState`?

Quando você tem 3 ou mais estados com transições restritas.
Quando gerenciar booleanas como isLoading, isError, isSuccess cria combinações impossíveis.
Um simples toggle de dois estados não precisa de uma máquina de estado; useState(false) é suficiente.

Como a função reducer atua como a máquina de estado?

O switch externo em state.step (ou state.status) define em qual estado você está.
Verificações if aninhadas em event.type definem quais transições são válidas nesse estado.
O return state padrão ignora eventos que não são válidos para o estado atual.

Armadilha: Por que reducers devem ser funções puras?

O React pode chamar reducers múltiplas vezes durante a renderização (modo estrito, recursos concorrentes).
Efeitos colaterais como chamadas de API ou mutações de DOM dentro do reducer quebram as regras do React e causam comportamento imprevisível.
Correção: acione efeitos colaterais em handlers de evento ou useEffect com base nas transições de estado.

O que acontece se o reducer esquecer de retornar `state` para eventos não tratados?

O estado se torna undefined, o que pode travar o componente ou causar bugs silenciosos.
Sempre adicione return state como o caso padrão para cada estado na instrução switch.
O TypeScript pode ajudar a capturar isso com um tipo de retorno explícito no reducer.

Como adicionar condições de guarda a transições de estado?

case "details":
  if (event.type === "NEXT") {
    if (!event.fields.name || !event.fields.email) {
      return { ...state, validationError: "Todos os campos são obrigatórios" };
    }
    return { step: "plan", data: { ...state.data, ...event.fields } };
  }
  return state;

Verifique as condições antes de realizar a transição.
Retorne um estado atual modificado (por exemplo, com um erro) se a guarda falhar.

Como fazer o TypeScript impor o tratamento exaustivo de estado?

Especifique explicitamente o tipo de retorno da função reducer.
O TypeScript avisará se você esquecer um caso na instrução switch.
Use uma verificação never no caso padrão para capturar estados não tratados em tempo de compilação.

Quando usar XState em vez de `useReducer`?

Use XState para máquinas complexas com estados paralelos, estados hierárquicos ou transições atrasadas.
XState fornece ferramentas visuais (editor de diagrama de estados) e suporte de TypeScript de primeira classe.
Para fluxos lineares simples, useReducer é suficiente e não tem dependências.

Por que evitar campos booleanos em objetos de estado?

n campos booleanos criam 2^n combinações possíveis, a maioria das quais são inválidas.
Exemplo: { isLoading: true, isError: true } é um estado impossível que booleanas permitem.
Correção: use uma única union discriminada com estados nomeados como "idle" | "loading" | "error" | "success".

Como lidar com efeitos colaterais como chamadas de API acionadas por transições de estado?

Realize a chamada de API no handler de evento ou em um useEffect que observe o estado.
Dispare eventos como SUCCESS ou FAIL com base na resposta da API.
Mantenha o reducer puro; ele apenas calcula o próximo estado.

Relacionados

Controlado vs Não Controlado - Padrões de propriedade de estado que essas máquinas geralmente gerenciam
Error Boundaries - Estados de erro na árvore de componentes
Suspense - Máquina de estado de carregamento nativa do React

Receita

// Máquina de estado simples com useReducer
type FetchState =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "success"; data: unknown }
  | { status: "error"; error: Error };
 
type FetchEvent =
  | { type: "FETCH" }
  | { type: "RESOLVE"; data: unknown }
  | { type: "REJECT"; error: Error }
  | { type: "RESET" };
 
function fetchReducer(state: FetchState, event: FetchEvent): FetchState {
  switch (state.status) {
    case "idle":
      if (event.type === "FETCH") return { status: "loading" };
      return state;
    case "loading":
      if (event.type === "RESOLVE") return { status: "success", data: event.data };
      if (event.type === "REJECT") return { status: "error", error: event.error };
      return state;
    case "error":
      if (event.type === "FETCH") return { status: "loading" };
      if (event.type === "RESET") return { status: "idle" };
      return state;
    case "success":
      if (event.type === "FETCH") return { status: "loading" };
      if (event.type === "RESET") return { status: "idle" };
      return state;
  }
}
 
const [state, send] = useReducer(fetchReducer, { status: "idle" });

Exemplo de Trabalho

import { useReducer, useCallback, type ReactNode } from "react";
 
// --- Máquina de estado de formulário de várias etapas ---
 
interface FormData {
  name: string;
  email: string;
  plan: string;
}
 
type FormState =
  | { step: "details"; data: Partial<FormData> }
  | { step: "plan"; data: Partial<FormData> }
  | { step: "review"; data: FormData }
  | { step: "submitting"; data: FormData }
  | { step: "complete"; data: FormData }
  | { step: "error"; data: FormData; error: string };
 
type FormEvent =
  | { type: "NEXT"; fields: Partial<FormData> }
  | { type: "BACK" }
  | { type: "SUBMIT" }
  | { type: "SUCCESS" }
  | { type: "FAIL"; error: string }
  | { type: "RETRY" };
 
function formReducer(state: FormState, event: FormEvent): FormState {
  switch (state.step) {
    case "details":
      if (event.type === "NEXT") {
        return { step: "plan", data: { ...state.data, ...event.fields } };
      }
      return state;
 
    case "plan":
      if (event.type === "NEXT") {
        const data = { ...state.data, ...event.fields } as FormData;
        return { step: "review", data };
      }
      if (event.type === "BACK") return { step: "details", data: state.data };
      return state;
 
    case "review":
      if (event.type === "SUBMIT") return { step: "submitting", data: state.data };
      if (event.type === "BACK") return { step: "plan", data: state.data };
      return state;
 
    case "submitting":
      if (event.type === "SUCCESS") return { step: "complete", data: state.data };
      if (event.type === "FAIL") {
        return { step: "error", data: state.data, error: event.error };
      }
      return state;
 
    case "error":
      if (event.type === "RETRY") return { step: "submitting", data: state.data };
      if (event.type === "BACK") return { step: "review", data: state.data };
      return state;
 
    case "complete":
      return state; // Estado terminal
  }
}
 
function SignupWizard() {
  const [state, send] = useReducer(formReducer, {
    step: "details",
    data: {},
  });
 
  const handleSubmit = useCallback(async () => {
    send({ type: "SUBMIT" });
    try {
      await fetch("/api/signup", {
        method: "POST",
        body: JSON.stringify(state.step === "review" ? state.data : null),
      });
      send({ type: "SUCCESS" });
    } catch (err) {
      send({ type: "FAIL", error: (err as Error).message });
    }
  }, [state]);
 
  switch (state.step) {
    case "details":
      return (
        <DetailsStep
          data={state.data}
          onNext={(fields) => send({ type: "NEXT", fields })}
        />
      );
    case "plan":
      return (
        <PlanStep
          data={state.data}
          onNext={(fields) => send({ type: "NEXT", fields })}
          onBack={() => send({ type: "BACK" })}
        />
      );
    case "review":
      return (
        <ReviewStep
          data={state.data}
          onSubmit={handleSubmit}
          onBack={() => send({ type: "BACK" })}
        />
      );
    case "submitting":
      return <LoadingSpinner message="Criando sua conta..." />;
    case "error":
      return (
        <ErrorDisplay
          error={state.error}
          onRetry={() => send({ type: "RETRY" })}
          onBack={() => send({ type: "BACK" })}
        />
      );
    case "complete":
      return <SuccessMessage data={state.data} />;
  }
}

O que isso demonstra:

Tipos de union discriminada para estados - cada etapa carrega exatamente os dados que necessita
Guardas de transição explícitas - eventos só têm efeito no estado correto
Estados impossíveis são irrepresentáveis - sem confusão isLoading && isError
Efeitos colaterais (chamada de API) acionados por transições de estado, não espalhados por effects

Mergulho Profundo

Como Funciona

Uma máquina de estado define um conjunto finito de estados e um conjunto finito de eventos (transições) entre eles.
Cada estado determina quais eventos são válidos. Eventos inválidos são ignorados (ou podem gerar erro em desenvolvimento).
useReducer é o primitivo nativo do React para estados. A função reducer É a máquina de estado.
Tipos de union discriminada em TypeScript tornam a forma de cada estado explícita e permitem que o compilador imponha o tratamento exaustivo.
O switch em state.step (ou state.status) atua como o diagrama de estados; verificações if aninhadas em event.type definem transições válidas.

Parâmetros e Valores de Retorno

Conceito	Implementação	Propósito
Estado	Union discriminada	Representa todos os estados possíveis com dados associados
Evento	Union de `{ type: string; ... }`	Todas as entradas possíveis que acionam transições
Reducer	`(state, event) => state`	Função pura definindo a lógica da máquina de estado
Dispatch	`send(event)`	Aciona uma transição de estado

Variações

Condições de guarda - permitem transições apenas quando as condições são atendidas:

case "details":
  if (event.type === "NEXT") {
    if (!event.fields.name || !event.fields.email) {
      return { ...state, validationError: "Todos os campos são obrigatórios" };
    }
    return { step: "plan", data: { ...state.data, ...event.fields } };
  }
  return state;

Usando XState para máquinas complexas - quando a lógica de estado excede o que useReducer lida de forma limpa:

import { useMachine } from "@xstate/react";
import { createMachine, assign } from "xstate";
 
const toggleMachine = createMachine({
  id: "toggle",
  initial: "inactive",
  context: { count: 0 },
  states: {
    inactive: {
      on: {
        TOGGLE: {
          target: "active",
          actions: assign({ count: ({ context }) => context.count + 1 }),
        },
      },
    },
    active: {
      on: { TOGGLE: "inactive" },
    },
  },
});
 
function Toggle() {
  const [state, send] = useMachine(toggleMachine);
  return (
    <button onClick={() => send({ type: "TOGGLE" })}>
      {state.value} (alternado {state.context.count} vezes)
    </button>
  );
}

Notas de TypeScript

Use unions discriminadas (unions com tag) para tipos de estado. O discriminante (por exemplo, step, status) permite o estreitamento de tipo.
Sempre torne o switch exaustivo. O TypeScript avisará se você esquecer um estado quando o tipo de retorno for especificado.
Evite campos boolean em objetos de estado - eles criam 2^n estados possíveis. Use estados nomeados explícitos em vez disso.
XState v5 tem suporte de TypeScript de primeira classe com typegen para inferência de tipos de evento.

Armadilhas

Sopa de booleanas - Usar isLoading, isError, hasData como booleanas separadas cria combinações impossíveis como isLoading && isError. Correção: Substitua por um único estado de union discriminada.
Efeitos colaterais no reducer - Reducers devem ser funções puras. Chamadas de API ou mutações de DOM dentro do reducer quebram as regras do React e causam comportamento imprevisível. Correção: Acione efeitos colaterais fora do reducer com base nas transições de estado (em handlers de evento ou effects).
Esquecer o retorno padrão - Se o reducer não tratar um evento em um determinado estado e não retornar state, o estado se torna undefined. Correção: Sempre adicione return state como o padrão para eventos não tratados em cada caso de estado.
Exagero de engenharia para estado simples - Um toggle que está ligado ou desligado não precisa de uma máquina de estado. Correção: Use useState(false) para cenários triviais de dois estados. Recorra a máquinas quando você tiver 3+ estados ou transições complexas.

Alternativas

Abordagem	Trade-off
Máquina de estado `useReducer`	Nativo, sem dependências; lógica de transição manual
XState	Poderoso, ferramentas visuais; dependência extra, curva de aprendizado
Múltiplas booleanas `useState`	Simples para 1-2 estados; estados impossíveis se tornam possíveis
Zustand com campo de estado	Bom para máquinas de estado globais; não específico do React
`useActionState` (React 19)	Projetado para fluxos de submissão de formulário; limitado a ações de formulário

FAQs

O que é uma máquina de estado no contexto da lógica de UI do React?

Uma máquina de estado define um conjunto finito de estados e um conjunto finito de transições válidas entre eles.
Cada estado determina quais eventos são aceitos. Eventos inválidos são ignorados.
useReducer é o primitivo nativo do React para implementar máquinas de estado.

Por que tipos de union discriminada são importantes para máquinas de estado?

type FetchState =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "success"; data: unknown }
  | { status: "error"; error: Error };

Cada estado carrega exatamente os dados que necessita (por exemplo, data só existe em success).
O TypeScript estreita o tipo quando você usa switch no discriminante (status), prevenindo o acesso a campos inválidos.
Estados impossíveis como isLoading && isError tornam-se irrepresentáveis.

Quando você deve usar uma máquina de estado em vez de múltiplas booleanas `useState`?

Quando você tem 3 ou mais estados com transições restritas.
Quando gerenciar booleanas como isLoading, isError, isSuccess cria combinações impossíveis.
Um simples toggle de dois estados não precisa de uma máquina de estado; useState(false) é suficiente.

Como a função reducer atua como a máquina de estado?

O switch externo em state.step (ou state.status) define em qual estado você está.
Verificações if aninhadas em event.type definem quais transições são válidas nesse estado.
O return state padrão ignora eventos que não são válidos para o estado atual.

Armadilha: Por que reducers devem ser funções puras?

O React pode chamar reducers múltiplas vezes durante a renderização (modo estrito, recursos concorrentes).
Efeitos colaterais como chamadas de API ou mutações de DOM dentro do reducer quebram as regras do React e causam comportamento imprevisível.
Correção: acione efeitos colaterais em handlers de evento ou useEffect com base nas transições de estado.

O que acontece se o reducer esquecer de retornar `state` para eventos não tratados?

O estado se torna undefined, o que pode travar o componente ou causar bugs silenciosos.
Sempre adicione return state como o caso padrão para cada estado na instrução switch.
O TypeScript pode ajudar a capturar isso com um tipo de retorno explícito no reducer.

Como adicionar condições de guarda a transições de estado?

case "details":
  if (event.type === "NEXT") {
    if (!event.fields.name || !event.fields.email) {
      return { ...state, validationError: "Todos os campos são obrigatórios" };
    }
    return { step: "plan", data: { ...state.data, ...event.fields } };
  }
  return state;

Verifique as condições antes de realizar a transição.
Retorne um estado atual modificado (por exemplo, com um erro) se a guarda falhar.

Como fazer o TypeScript impor o tratamento exaustivo de estado?

Especifique explicitamente o tipo de retorno da função reducer.
O TypeScript avisará se você esquecer um caso na instrução switch.
Use uma verificação never no caso padrão para capturar estados não tratados em tempo de compilação.

Quando usar XState em vez de `useReducer`?

Use XState para máquinas complexas com estados paralelos, estados hierárquicos ou transições atrasadas.
XState fornece ferramentas visuais (editor de diagrama de estados) e suporte de TypeScript de primeira classe.
Para fluxos lineares simples, useReducer é suficiente e não tem dependências.

Por que evitar campos booleanos em objetos de estado?

n campos booleanos criam 2^n combinações possíveis, a maioria das quais são inválidas.
Exemplo: { isLoading: true, isError: true } é um estado impossível que booleanas permitem.
Correção: use uma única union discriminada com estados nomeados como "idle" | "loading" | "error" | "success".

Como lidar com efeitos colaterais como chamadas de API acionadas por transições de estado?

Realize a chamada de API no handler de evento ou em um useEffect que observe o estado.
Dispare eventos como SUCCESS ou FAIL com base na resposta da API.
Mantenha o reducer puro; ele apenas calcula o próximo estado.

Relacionados

Controlado vs Não Controlado - Padrões de propriedade de estado que essas máquinas geralmente gerenciam
Error Boundaries - Estados de erro na árvore de componentes
Suspense - Máquina de estado de carregamento nativa do React

Máquinas de Estado para Lógica de UI - Modele estados complexos de UI como transições de estado finitas e explícitas

Buscar na documentação

Máquinas de Estado para Lógica de UI - Modele estados complexos de UI como transições de estado finitas e explícitas