Padrões de Contexto - Divida, escopo e otimize o contexto React para evitar re-renderizações desnecessárias

Q: Como o use() no React 19 difere do useContext()?

O use() pode ser chamado condicionalmente (dentro de instruções if), ao contrário do useContext(). O use() também funciona com promessas para busca de dados baseada em Suspense. O useContext() ainda funciona no React 19, mas o use() é a alternativa mais flexível.

Q: Armadilha: Como um valor de contexto padrão pode ocultar um bug de provedor ausente?

Se você fornecer um padrão significativo para createContext(defaultValue), os componentes funcionarão sem um provedor. Isso pode mascarar um provedor ausente na árvore, levando a bugs sutis onde os componentes usam padrões desatualizados. Correção: use createContext(null) e lance um erro no hook personalizado quando o contexto for nulo.

Q: Como você tipa um contexto que requer um provedor em TypeScript?

Use | null como padrão e verifique se é nulo no hook personalizado. O tipo de retorno do hook é MyState (não nulo) após a verificação.

Q: O que é o padrão de seletor com useSyncExternalStore e quando é útil?

useSyncExternalStore assina uma loja externa e lê uma fatia selecionada do estado. Apenas o valor selecionado aciona re-renderizações, fornecendo assinatura granular sem divisão de contexto. Útil quando você precisa de leituras baseadas em seletores sem adotar uma biblioteca completa de gerenciamento de estado.

Q: Como você combina contexto com useReducer para transições de estado complexas?

Divida estado e dispatch em contextos separados. O dispatch é estável (o React garante isso), então consumidores apenas de dispatch nunca re-renderizam.

Receita

import { createContext, use, useState, useCallback, type ReactNode } from "react";
 
// Contexto dividido: separa estado de dispatch
const CountStateContext = createContext<number>(0);
const CountDispatchContext = createContext<{
  increment: () => void;
  decrement: () => void;
} | null>(null);
 
function CountProvider({ children }: { children: ReactNode }) {
  const [count, setCount] = useState(0);
  const dispatch = useMemo(() => ({
    increment: () => setCount((c) => c + 1),
    decrement: () => setCount((c) => c - 1),
  }), []);
 
  return (
    <CountStateContext value={count}>
      <CountDispatchContext value={dispatch}>
        {children}
      </CountDispatchContext>
    </CountStateContext>
  );
}

Quando usar isso: Quando você tem um contexto que causa re-renderizações em componentes que precisam apenas de parte do valor do contexto. Divida estado e ações em contextos separados, escopoe o contexto para subárvores e use seletores para ler apenas o que você precisa.

Exemplo de Trabalho

import {
  createContext,
  use,
  useState,
  useMemo,
  useCallback,
  memo,
  type ReactNode,
} from "react";
 
// --- Contexto dividido: Estado do tema vs ações ---
 
interface ThemeState {
  mode: "light" | "dark";
  accentColor: string;
  fontSize: number;
}
 
interface ThemeActions {
  toggleMode: () => void;
  setAccentColor: (color: string) => void;
  setFontSize: (size: number) => void;
}
 
const ThemeStateContext = createContext<ThemeState>({
  mode: "light",
  accentColor: "#3b82f6",
  fontSize: 16,
});
 
const ThemeActionsContext = createContext<ThemeActions | null>(null);
 
function ThemeProvider({ children }: { children: ReactNode }) {
  const [state, setState] = useState<ThemeState>({
    mode: "light",
    accentColor: "#3b82f6",
    fontSize: 16,
  });
 
  // Objeto de ações estável - nunca causa re-renderizações em consumidores apenas de ações
  const actions = useMemo<ThemeActions>(
    () => ({
      toggleMode: () =>
        setState((s) => ({
          ...s,
          mode: s.mode === "light" ? "dark" : "light",
        })),
      setAccentColor: (color) =>
        setState((s) => ({ ...s, accentColor: color })),
      setFontSize: (size) =>
        setState((s) => ({ ...s, fontSize: size })),
    }),
    []
  );
 
  return (
    <ThemeStateContext value={state}>
      <ThemeActionsContext value={actions}>
        {children}
      </ThemeActionsContext>
    </ThemeStateContext>
  );
}
 
// Hooks personalizados com verificações de segurança
function useThemeState() {
  return use(ThemeStateContext);
}
 
function useThemeActions() {
  const actions = use(ThemeActionsContext);
  if (!actions) throw new Error("useThemeActions deve estar dentro de ThemeProvider");
  return actions;
}
 
// --- Componentes demonstrando consumo seletivo ---
 
// Re-renderiza apenas quando o estado do tema muda
const ThemeIndicator = memo(function ThemeIndicator() {
  const { mode, accentColor } = useThemeState();
  console.log("ThemeIndicator rendered");
  return (
    <div className="flex items-center gap-2">
      <div
        className="w-4 h-4 rounded-full"
        style={{ backgroundColor: accentColor }}
      />
      <span>{mode} mode</span>
    </div>
  );
});
 
// Re-renderiza apenas quando o contexto de ações muda (nunca, porque é memoizado)
const ThemeToggleButton = memo(function ThemeToggleButton() {
  const { toggleMode } = useThemeActions();
  console.log("ThemeToggleButton rendered");
  return (
    <button onClick={toggleMode} className="px-3 py-1 border rounded">
      Toggle Theme
    </button>
  );
});
 
// --- Padrão de contexto com escopo ---
 
interface NotificationContextValue {
  notifications: Notification[];
  add: (message: string) => void;
  dismiss: (id: string) => void;
}
 
const NotificationContext = createContext<NotificationContextValue | null>(null);
 
function useNotifications() {
  const ctx = use(NotificationContext);
  if (!ctx) throw new Error("useNotifications deve estar dentro de NotificationProvider");
  return ctx;
}
 
interface Notification {
  id: string;
  message: string;
}
 
function NotificationProvider({ children }: { children: ReactNode }) {
  const [notifications, setNotifications] = useState<Notification[]>([]);
 
  const add = useCallback((message: string) => {
    const id = crypto.randomUUID();
    setNotifications((prev) => [...prev, { id, message }]);
    setTimeout(() => {
      setNotifications((prev) => prev.filter((n) => n.id !== id));
    }, 5000);
  }, []);
 
  const dismiss = useCallback((id: string) => {
    setNotifications((prev) => prev.filter((n) => n.id !== id));
  }, []);
 
  const value = useMemo(
    () => ({ notifications, add, dismiss }),
    [notifications, add, dismiss]
  );
 
  return (
    <NotificationContext value={value}>
      {children}
    </NotificationContext>
  );
}
 
// --- Layout completo do aplicativo ---
function App() {
  return (
    <ThemeProvider>
      <NotificationProvider>
        <header className="flex justify-between p-4 border-b">
          <ThemeIndicator />
          <ThemeToggleButton />
        </header>
        <main className="p-6">
          <ContentArea />
        </main>
      </NotificationProvider>
    </ThemeProvider>
  );
}

O que isso demonstra:

Contexto dividido: ThemeStateContext e ThemeActionsContext são separados
Ações estáveis via useMemo - consumidores apenas de ações nunca re-renderizam
memo em componentes folha para evitar re-renderizações de renderizações de componentes pai
Contexto de notificação com escopo e descarte automático
Hooks personalizados com mensagens de erro úteis para provedores ausentes

Mergulho Profundo

Como Funciona

O contexto React re-renderiza todo consumidor sempre que o valor do contexto muda (por referência).
Dividir estado e ações em contextos separados significa que consumidores apenas de ações (como botões) não re-renderizam quando o estado muda.
useMemo no objeto de ações garante que sua referência nunca mude, tornando o contexto de ações estável.
Para o contexto de estado, useMemo no objeto de valor só é útil se você tiver vários campos de estado e quiser evitar re-renderizações quando campos não relacionados mudam - mas como o objeto é recriado quando qualquer campo muda, ele é mais eficaz com contextos divididos por domínio.
O use() do React 19 pode ler contexto condicionalmente (dentro de instruções if), ao contrário do useContext.

Parâmetros e Valores de Retorno

Padrão	O Que Resolve
Dividir estado/ações	Consumidores apenas de ações (botões, formulários) não re-renderizam em mudanças de estado
Objeto de valor memoizado	Evita re-renderizações quando a referência do objeto mudaria, mas os conteúdos são os mesmos
Provedor com escopo	Contexto disponível apenas para a subárvore que precisa dele
Hook personalizado com erro	Captura bugs de provedor ausente em tempo de desenvolvimento
Valor padrão em createContext	Permite usar contexto sem um provedor (útil para padrões de tema)

Variações

Padrão de seletor com loja externa - assine apenas a parte que você precisa:

import { useSyncExternalStore } from "react";
 
// Usando useSyncExternalStore para leituras baseadas em seletores
function useStoreSelector<T, S>(store: Store<T>, selector: (state: T) => S): S {
  return useSyncExternalStore(
    store.subscribe,
    () => selector(store.getSnapshot()),
    () => selector(store.getServerSnapshot())
  );
}
 
// Re-renderiza apenas quando `user.name` muda
function UserName() {
  const name = useStoreSelector(appStore, (s) => s.user.name);
  return <span>{name}</span>;
}

Contexto com reducer - para transições de estado complexas:

const TodoDispatchContext = createContext<React.Dispatch<TodoAction> | null>(null);
const TodoStateContext = createContext<TodoState>({ items: [] });
 
function TodoProvider({ children }: { children: ReactNode }) {
  const [state, dispatch] = useReducer(todoReducer, { items: [] });
 
  return (
    <TodoStateContext value={state}>
      <TodoDispatchContext value={dispatch}>
        {children}
      </TodoDispatchContext>
    </TodoStateContext>
  );
}

Notas TypeScript

Forneça um padrão sensato para createContext<T>(defaultValue) quando o contexto puder funcionar sem um provedor.
Use createContext<T | null>(null) quando um provedor for necessário e verifique se é nulo no hook personalizado.
Digite o retorno do hook personalizado como não nulo (ThemeActions em vez de ThemeActions | null) após a verificação de nulo.
Exporte os tipos de contexto para que os consumidores possam tipar suas próprias abstrações.

Armadilhas

Contexto único com estado e ações misturados - Toda mudança de estado re-renderiza todo consumidor, mesmo aqueles que apenas chamam ações. Correção: Divida em contextos de estado e ação separados.
Valor de contexto instável - Criar uma nova literal de objeto na renderização do provedor (value={{ a, b }}) faz com que todo consumidor re-renderize. Correção: Use useMemo para estabilizar a referência do valor.
Provedor muito alto na árvore - Colocar um provedor que muda frequentemente na raiz do aplicativo re-renderiza toda a árvore de consumidores. Correção: Escope os provedores para a menor subárvore que precisa deles.
Divisão excessiva de contexto - Criar dezenas de contextos minúsculos adiciona complexidade e aninhamento de provedores. Correção: Divida por frequência de atualização (coisas que mudam juntas devem ficar juntas). Use Zustand ou Jotai para assinaturas granulares.
Valores de contexto padrão ocultando bugs - Um valor padrão significativo significa que o contexto funciona sem um provedor, o que pode mascarar um provedor ausente. Correção: Use padrão null + hook personalizado com throw para provedores necessários.

Alternativas

Abordagem	Compromisso
Contexto dividido	Zero dependências; esforço manual de divisão
Zustand	Seletores automáticos, sem provedores; dependência extra
Jotai	Estado atômico, re-renderizações granulares; modelo mental diferente
Redux + useSelector	Ecossistema maduro, depuração com viagem no tempo; boilerplate
`useSyncExternalStore`	Funciona com qualquer loja externa; API de nível inferior
Sinais (futuro)	Reatividade granular; ainda não no React

FAQs

Por que colocar estado e ações em um único contexto causa problemas de desempenho?

Toda mudança de estado re-renderiza todo consumidor, mesmo aqueles que apenas chamam ações (como botões).
Consumidores que nunca leem o estado ainda re-renderizam porque a referência do valor do contexto muda.
Correção: dividir em contextos de estado e ação separados.

Como a divisão de estado e ações em contextos separados ajuda no desempenho?

Consumidores apenas de ações (botões, formulários) assinam apenas o contexto de ações.
Como o objeto de ações é memoizado com useMemo(() => actions, []), sua referência nunca muda.
Consumidores apenas de ações nunca re-renderizam quando o estado muda.

O que o `useMemo` no objeto de ações realiza em um provedor de contexto?

const actions = useMemo<ThemeActions>(
  () => ({
    toggleMode: () => setState((s) => ({ ...s, mode: s.mode === "light" ? "dark" : "light" })),
    setAccentColor: (color) => setState((s) => ({ ...s, accentColor: color })),
  }),
  []
);

Ele cria uma referência estável que nunca muda entre as renderizações.
Consumidores do contexto de ações nunca re-renderizam porque a referência permanece a mesma.

Quando você deve escopar um provedor de contexto a uma subárvore em vez da raiz do aplicativo?

Quando apenas uma parte do aplicativo precisa do contexto (por exemplo, um sistema de notificações para uma página).
Quando o valor do contexto muda com frequência e causaria re-renderizações em componentes não relacionados.
O escopo reduz o raio de explosão das atualizações de contexto.

Como o `use()` no React 19 difere do `useContext()`?

O use() pode ser chamado condicionalmente (dentro de instruções if), ao contrário do useContext().
O use() também funciona com promessas para busca de dados baseada em Suspense.
O useContext() ainda funciona no React 19, mas o use() é a alternativa mais flexível.

Armadilha: Por que `value={{ a, b }}` em um provedor causa re-renderizações desnecessárias?

Criar uma nova literal de objeto na renderização cria uma nova referência a cada renderização.
O React verifica o valor do contexto por referência, então todo consumidor re-renderiza mesmo que a e b não tenham mudado.
Correção: memoize o valor com useMemo ou divida em contextos separados.

Armadilha: Como um valor de contexto padrão pode ocultar um bug de provedor ausente?

Se você fornecer um padrão significativo para createContext(defaultValue), os componentes funcionarão sem um provedor.
Isso pode mascarar um provedor ausente na árvore, levando a bugs sutis onde os componentes usam padrões desatualizados.
Correção: use createContext<T | null>(null) e lance um erro no hook personalizado quando o contexto for nulo.

Como você tipa um contexto que requer um provedor em TypeScript?

const MyContext = createContext<MyState | null>(null);
 
function useMyContext(): MyState {
  const ctx = use(MyContext);
  if (!ctx) throw new Error("useMyContext must be within MyProvider");
  return ctx;
}

Use | null como padrão e verifique se é nulo no hook personalizado.
O tipo de retorno do hook é MyState (não nulo) após a verificação.

O que é o padrão de seletor com `useSyncExternalStore` e quando é útil?

useSyncExternalStore assina uma loja externa e lê uma fatia selecionada do estado.
Apenas o valor selecionado aciona re-renderizações, fornecendo assinatura granular sem divisão de contexto.
Útil quando você precisa de leituras baseadas em seletores sem adotar uma biblioteca completa de gerenciamento de estado.

Como você combina contexto com `useReducer` para transições de estado complexas?

const TodoStateContext = createContext<TodoState>({ items: [] });
const TodoDispatchContext = createContext<React.Dispatch<TodoAction> | null>(null);
 
function TodoProvider({ children }: { children: ReactNode }) {
  const [state, dispatch] = useReducer(todoReducer, { items: [] });
  return (
    <TodoStateContext value={state}>
      <TodoDispatchContext value={dispatch}>{children}</TodoDispatchContext>
    </TodoStateContext>
  );
}

Divida estado e dispatch em contextos separados.
O dispatch é estável (o React garante isso), então consumidores apenas de dispatch nunca re-renderizam.

Quando você deve usar Zustand ou Jotai em vez de contexto React?

Quando você precisa de assinaturas granulares (selecionar um único campo sem re-renderizar em mudanças não relacionadas).
Quando você tem muitos valores que mudam com frequência e exigiriam divisão excessiva de contexto.
Quando você deseja uma API mais simples sem aninhamento de provedores.

Relacionado

Desempenho - Técnicas de memoização e otimização de re-renderização
Componentes Compostos - O contexto é a espinha dorsal dos componentes compostos
Composição - A composição reduz a necessidade de contexto em muitos casos

Receita

import { createContext, use, useState, useCallback, type ReactNode } from "react";
 
// Contexto dividido: separa estado de dispatch
const CountStateContext = createContext<number>(0);
const CountDispatchContext = createContext<{
  increment: () => void;
  decrement: () => void;
} | null>(null);
 
function CountProvider({ children }: { children: ReactNode }) {
  const [count, setCount] = useState(0);
  const dispatch = useMemo(() => ({
    increment: () => setCount((c) => c + 1),
    decrement: () => setCount((c) => c - 1),
  }), []);
 
  return (
    <CountStateContext value={count}>
      <CountDispatchContext value={dispatch}>
        {children}
      </CountDispatchContext>
    </CountStateContext>
  );
}

Exemplo de Trabalho

import {
  createContext,
  use,
  useState,
  useMemo,
  useCallback,
  memo,
  type ReactNode,
} from "react";
 
// --- Contexto dividido: Estado do tema vs ações ---
 
interface ThemeState {
  mode: "light" | "dark";
  accentColor: string;
  fontSize: number;
}
 
interface ThemeActions {
  toggleMode: () => void;
  setAccentColor: (color: string) => void;
  setFontSize: (size: number) => void;
}
 
const ThemeStateContext = createContext<ThemeState>({
  mode: "light",
  accentColor: "#3b82f6",
  fontSize: 16,
});
 
const ThemeActionsContext = createContext<ThemeActions | null>(null);
 
function ThemeProvider({ children }: { children: ReactNode }) {
  const [state, setState] = useState<ThemeState>({
    mode: "light",
    accentColor: "#3b82f6",
    fontSize: 16,
  });
 
  // Objeto de ações estável - nunca causa re-renderizações em consumidores apenas de ações
  const actions = useMemo<ThemeActions>(
    () => ({
      toggleMode: () =>
        setState((s) => ({
          ...s,
          mode: s.mode === "light" ? "dark" : "light",
        })),
      setAccentColor: (color) =>
        setState((s) => ({ ...s, accentColor: color })),
      setFontSize: (size) =>
        setState((s) => ({ ...s, fontSize: size })),
    }),
    []
  );
 
  return (
    <ThemeStateContext value={state}>
      <ThemeActionsContext value={actions}>
        {children}
      </ThemeActionsContext>
    </ThemeStateContext>
  );
}
 
// Hooks personalizados com verificações de segurança
function useThemeState() {
  return use(ThemeStateContext);
}
 
function useThemeActions() {
  const actions = use(ThemeActionsContext);
  if (!actions) throw new Error("useThemeActions deve estar dentro de ThemeProvider");
  return actions;
}
 
// --- Componentes demonstrando consumo seletivo ---
 
// Re-renderiza apenas quando o estado do tema muda
const ThemeIndicator = memo(function ThemeIndicator() {
  const { mode, accentColor } = useThemeState();
  console.log("ThemeIndicator rendered");
  return (
    <div className="flex items-center gap-2">
      <div
        className="w-4 h-4 rounded-full"
        style={{ backgroundColor: accentColor }}
      />
      <span>{mode} mode</span>
    </div>
  );
});
 
// Re-renderiza apenas quando o contexto de ações muda (nunca, porque é memoizado)
const ThemeToggleButton = memo(function ThemeToggleButton() {
  const { toggleMode } = useThemeActions();
  console.log("ThemeToggleButton rendered");
  return (
    <button onClick={toggleMode} className="px-3 py-1 border rounded">
      Toggle Theme
    </button>
  );
});
 
// --- Padrão de contexto com escopo ---
 
interface NotificationContextValue {
  notifications: Notification[];
  add: (message: string) => void;
  dismiss: (id: string) => void;
}
 
const NotificationContext = createContext<NotificationContextValue | null>(null);
 
function useNotifications() {
  const ctx = use(NotificationContext);
  if (!ctx) throw new Error("useNotifications deve estar dentro de NotificationProvider");
  return ctx;
}
 
interface Notification {
  id: string;
  message: string;
}
 
function NotificationProvider({ children }: { children: ReactNode }) {
  const [notifications, setNotifications] = useState<Notification[]>([]);
 
  const add = useCallback((message: string) => {
    const id = crypto.randomUUID();
    setNotifications((prev) => [...prev, { id, message }]);
    setTimeout(() => {
      setNotifications((prev) => prev.filter((n) => n.id !== id));
    }, 5000);
  }, []);
 
  const dismiss = useCallback((id: string) => {
    setNotifications((prev) => prev.filter((n) => n.id !== id));
  }, []);
 
  const value = useMemo(
    () => ({ notifications, add, dismiss }),
    [notifications, add, dismiss]
  );
 
  return (
    <NotificationContext value={value}>
      {children}
    </NotificationContext>
  );
}
 
// --- Layout completo do aplicativo ---
function App() {
  return (
    <ThemeProvider>
      <NotificationProvider>
        <header className="flex justify-between p-4 border-b">
          <ThemeIndicator />
          <ThemeToggleButton />
        </header>
        <main className="p-6">
          <ContentArea />
        </main>
      </NotificationProvider>
    </ThemeProvider>
  );
}

O que isso demonstra:

Contexto dividido: ThemeStateContext e ThemeActionsContext são separados
Ações estáveis via useMemo - consumidores apenas de ações nunca re-renderizam
memo em componentes folha para evitar re-renderizações de renderizações de componentes pai
Contexto de notificação com escopo e descarte automático
Hooks personalizados com mensagens de erro úteis para provedores ausentes

Mergulho Profundo

Como Funciona

O contexto React re-renderiza todo consumidor sempre que o valor do contexto muda (por referência).
Dividir estado e ações em contextos separados significa que consumidores apenas de ações (como botões) não re-renderizam quando o estado muda.
useMemo no objeto de ações garante que sua referência nunca mude, tornando o contexto de ações estável.
Para o contexto de estado, useMemo no objeto de valor só é útil se você tiver vários campos de estado e quiser evitar re-renderizações quando campos não relacionados mudam - mas como o objeto é recriado quando qualquer campo muda, ele é mais eficaz com contextos divididos por domínio.
O use() do React 19 pode ler contexto condicionalmente (dentro de instruções if), ao contrário do useContext.

Parâmetros e Valores de Retorno

Padrão	O Que Resolve
Dividir estado/ações	Consumidores apenas de ações (botões, formulários) não re-renderizam em mudanças de estado
Objeto de valor memoizado	Evita re-renderizações quando a referência do objeto mudaria, mas os conteúdos são os mesmos
Provedor com escopo	Contexto disponível apenas para a subárvore que precisa dele
Hook personalizado com erro	Captura bugs de provedor ausente em tempo de desenvolvimento
Valor padrão em createContext	Permite usar contexto sem um provedor (útil para padrões de tema)

Variações

Padrão de seletor com loja externa - assine apenas a parte que você precisa:

import { useSyncExternalStore } from "react";
 
// Usando useSyncExternalStore para leituras baseadas em seletores
function useStoreSelector<T, S>(store: Store<T>, selector: (state: T) => S): S {
  return useSyncExternalStore(
    store.subscribe,
    () => selector(store.getSnapshot()),
    () => selector(store.getServerSnapshot())
  );
}
 
// Re-renderiza apenas quando `user.name` muda
function UserName() {
  const name = useStoreSelector(appStore, (s) => s.user.name);
  return <span>{name}</span>;
}

Contexto com reducer - para transições de estado complexas:

const TodoDispatchContext = createContext<React.Dispatch<TodoAction> | null>(null);
const TodoStateContext = createContext<TodoState>({ items: [] });
 
function TodoProvider({ children }: { children: ReactNode }) {
  const [state, dispatch] = useReducer(todoReducer, { items: [] });
 
  return (
    <TodoStateContext value={state}>
      <TodoDispatchContext value={dispatch}>
        {children}
      </TodoDispatchContext>
    </TodoStateContext>
  );
}

Notas TypeScript

Forneça um padrão sensato para createContext<T>(defaultValue) quando o contexto puder funcionar sem um provedor.
Use createContext<T | null>(null) quando um provedor for necessário e verifique se é nulo no hook personalizado.
Digite o retorno do hook personalizado como não nulo (ThemeActions em vez de ThemeActions | null) após a verificação de nulo.
Exporte os tipos de contexto para que os consumidores possam tipar suas próprias abstrações.

Armadilhas

Contexto único com estado e ações misturados - Toda mudança de estado re-renderiza todo consumidor, mesmo aqueles que apenas chamam ações. Correção: Divida em contextos de estado e ação separados.
Valor de contexto instável - Criar uma nova literal de objeto na renderização do provedor (value={{ a, b }}) faz com que todo consumidor re-renderize. Correção: Use useMemo para estabilizar a referência do valor.
Provedor muito alto na árvore - Colocar um provedor que muda frequentemente na raiz do aplicativo re-renderiza toda a árvore de consumidores. Correção: Escope os provedores para a menor subárvore que precisa deles.
Divisão excessiva de contexto - Criar dezenas de contextos minúsculos adiciona complexidade e aninhamento de provedores. Correção: Divida por frequência de atualização (coisas que mudam juntas devem ficar juntas). Use Zustand ou Jotai para assinaturas granulares.
Valores de contexto padrão ocultando bugs - Um valor padrão significativo significa que o contexto funciona sem um provedor, o que pode mascarar um provedor ausente. Correção: Use padrão null + hook personalizado com throw para provedores necessários.

Alternativas

Abordagem	Compromisso
Contexto dividido	Zero dependências; esforço manual de divisão
Zustand	Seletores automáticos, sem provedores; dependência extra
Jotai	Estado atômico, re-renderizações granulares; modelo mental diferente
Redux + useSelector	Ecossistema maduro, depuração com viagem no tempo; boilerplate
`useSyncExternalStore`	Funciona com qualquer loja externa; API de nível inferior
Sinais (futuro)	Reatividade granular; ainda não no React

FAQs

Por que colocar estado e ações em um único contexto causa problemas de desempenho?

Toda mudança de estado re-renderiza todo consumidor, mesmo aqueles que apenas chamam ações (como botões).
Consumidores que nunca leem o estado ainda re-renderizam porque a referência do valor do contexto muda.
Correção: dividir em contextos de estado e ação separados.

Como a divisão de estado e ações em contextos separados ajuda no desempenho?

Consumidores apenas de ações (botões, formulários) assinam apenas o contexto de ações.
Como o objeto de ações é memoizado com useMemo(() => actions, []), sua referência nunca muda.
Consumidores apenas de ações nunca re-renderizam quando o estado muda.

O que o `useMemo` no objeto de ações realiza em um provedor de contexto?

const actions = useMemo<ThemeActions>(
  () => ({
    toggleMode: () => setState((s) => ({ ...s, mode: s.mode === "light" ? "dark" : "light" })),
    setAccentColor: (color) => setState((s) => ({ ...s, accentColor: color })),
  }),
  []
);

Ele cria uma referência estável que nunca muda entre as renderizações.
Consumidores do contexto de ações nunca re-renderizam porque a referência permanece a mesma.

Quando você deve escopar um provedor de contexto a uma subárvore em vez da raiz do aplicativo?

Quando apenas uma parte do aplicativo precisa do contexto (por exemplo, um sistema de notificações para uma página).
Quando o valor do contexto muda com frequência e causaria re-renderizações em componentes não relacionados.
O escopo reduz o raio de explosão das atualizações de contexto.

Como o `use()` no React 19 difere do `useContext()`?

O use() pode ser chamado condicionalmente (dentro de instruções if), ao contrário do useContext().
O use() também funciona com promessas para busca de dados baseada em Suspense.
O useContext() ainda funciona no React 19, mas o use() é a alternativa mais flexível.

Armadilha: Por que `value={{ a, b }}` em um provedor causa re-renderizações desnecessárias?

Criar uma nova literal de objeto na renderização cria uma nova referência a cada renderização.
O React verifica o valor do contexto por referência, então todo consumidor re-renderiza mesmo que a e b não tenham mudado.
Correção: memoize o valor com useMemo ou divida em contextos separados.

Armadilha: Como um valor de contexto padrão pode ocultar um bug de provedor ausente?

Se você fornecer um padrão significativo para createContext(defaultValue), os componentes funcionarão sem um provedor.
Isso pode mascarar um provedor ausente na árvore, levando a bugs sutis onde os componentes usam padrões desatualizados.
Correção: use createContext<T | null>(null) e lance um erro no hook personalizado quando o contexto for nulo.

Como você tipa um contexto que requer um provedor em TypeScript?

const MyContext = createContext<MyState | null>(null);
 
function useMyContext(): MyState {
  const ctx = use(MyContext);
  if (!ctx) throw new Error("useMyContext must be within MyProvider");
  return ctx;
}

Use | null como padrão e verifique se é nulo no hook personalizado.
O tipo de retorno do hook é MyState (não nulo) após a verificação.

O que é o padrão de seletor com `useSyncExternalStore` e quando é útil?

useSyncExternalStore assina uma loja externa e lê uma fatia selecionada do estado.
Apenas o valor selecionado aciona re-renderizações, fornecendo assinatura granular sem divisão de contexto.
Útil quando você precisa de leituras baseadas em seletores sem adotar uma biblioteca completa de gerenciamento de estado.

Como você combina contexto com `useReducer` para transições de estado complexas?

const TodoStateContext = createContext<TodoState>({ items: [] });
const TodoDispatchContext = createContext<React.Dispatch<TodoAction> | null>(null);
 
function TodoProvider({ children }: { children: ReactNode }) {
  const [state, dispatch] = useReducer(todoReducer, { items: [] });
  return (
    <TodoStateContext value={state}>
      <TodoDispatchContext value={dispatch}>{children}</TodoDispatchContext>
    </TodoStateContext>
  );
}

Divida estado e dispatch em contextos separados.
O dispatch é estável (o React garante isso), então consumidores apenas de dispatch nunca re-renderizam.

Quando você deve usar Zustand ou Jotai em vez de contexto React?

Quando você precisa de assinaturas granulares (selecionar um único campo sem re-renderizar em mudanças não relacionadas).
Quando você tem muitos valores que mudam com frequência e exigiriam divisão excessiva de contexto.
Quando você deseja uma API mais simples sem aninhamento de provedores.

Relacionado

Desempenho - Técnicas de memoização e otimização de re-renderização
Componentes Compostos - O contexto é a espinha dorsal dos componentes compostos
Composição - A composição reduz a necessidade de contexto em muitos casos

Padrões de Contexto - Divida, escopo e otimize o contexto React para evitar re-renderizações desnecessárias

Buscar na documentação

Padrões de Contexto - Divida, escopo e otimize o contexto React para evitar re-renderizações desnecessárias