Context vs Zustand

Q: Como migrar um componente de Context para Zustand?

Remova o wrapper Provider e mude as chamadas useContext para useStore(selector).

Q: Armadilha: Envolver o valor do Context em useMemo resolve o problema de re-renderização?

useMemo reduz re-renderizações causadas pela re-renderização do provider. Mas não resolve o problema central: qualquer mudança em qualquer propriedade do valor re-renderiza todos os consumidores.

Q: Como escopar um store Zustand para uma subárvore (como o Context faz naturalmente)?

Use createStore (vanilla) + Context + useStore para instâncias por subárvore.

Receita

Decida quando usar React Context e quando usar Zustand. Context funciona para estado de baixa frequência, semelhante a temas. Zustand se destaca para estado de alta frequência e com múltiplos consumidores que necessita de re-renderização seletiva.

// Context: Bom para estado raramente mutável, com escopo de provider
const ThemeContext = createContext<"light" | "dark">("light");
 
// Zustand: Bom para estado global frequentemente mutável com muitos consumidores
const useCartStore = create<CartStore>((set) => ({
  items: [],
  addItem: (item) => set((s) => ({ items: [...s.items, item] })),
}));

Exemplo de Trabalho

// ANTES: Estado baseado em Context (causa re-renderizações em todos os consumidores)
// context/app-context.tsx
"use client";
 
import { createContext, useContext, useState, useCallback, ReactNode } from "react";
 
interface AppState {
  user: { name: string } | null;
  theme: "light" | "dark";
  notifications: string[];
  sidebarOpen: boolean;
}
 
interface AppContextValue extends AppState {
  setUser: (user: AppState["user"]) => void;
  toggleTheme: () => void;
  addNotification: (msg: string) => void;
  toggleSidebar: () => void;
}
 
const AppContext = createContext<AppContextValue | null>(null);
 
export function AppProvider({ children }: { children: ReactNode }) {
  const [user, setUser] = useState<AppState["user"]>(null);
  const [theme, setTheme] = useState<AppState["theme"]>("light");
  const [notifications, setNotifications] = useState<string[]>([]);
  const [sidebarOpen, setSidebarOpen] = useState(true);
 
  const toggleTheme = useCallback(() => {
    setTheme((t) => (t === "light" ? "dark" : "light"));
  }, []);
 
  const addNotification = useCallback((msg: string) => {
    setNotifications((n) => [...n, msg]);
  }, []);
 
  const toggleSidebar = useCallback(() => {
    setSidebarOpen((s) => !s);
  }, []);
 
  // Problema: novo objeto a cada renderização -> todos os consumidores re-renderizam
  return (
    <AppContext.Provider
      value={{
        user, theme, notifications, sidebarOpen,
        setUser, toggleTheme, addNotification, toggleSidebar,
      }}
    >
      {children}
    </AppContext.Provider>
  );
}
 
export const useApp = () => {
  const ctx = useContext(AppContext);
  if (!ctx) throw new Error("useApp deve estar dentro de AppProvider");
  return ctx;
};

// DEPOIS: Store Zustand (re-renderizações seletivas, sem necessidade de provider)
// stores/app-store.ts
import { create } from "zustand";
 
interface AppStore {
  user: { name: string } | null;
  theme: "light" | "dark";
  notifications: string[];
  sidebarOpen: boolean;
  setUser: (user: AppStore["user"]) => void;
  toggleTheme: () => void;
  addNotification: (msg: string) => void;
  toggleSidebar: () => void;
}
 
export const useAppStore = create<AppStore>((set) => ({
  user: null,
  theme: "light",
  notifications: [],
  sidebarOpen: true,
 
  setUser: (user) => set({ user }),
  toggleTheme: () => set((s) => ({ theme: s.theme === "light" ? "dark" : "light" })),
  addNotification: (msg) => set((s) => ({ notifications: [...s.notifications, msg] })),
  toggleSidebar: () => set((s) => ({ sidebarOpen: !s.sidebarOpen })),
}));

// Migração de componente
// ANTES:
function Header() {
  const { user, theme, toggleTheme } = useApp();
  // Re-renderiza quando notifications ou sidebarOpen também mudam
  return <header>...</header>;
}
 
// DEPOIS:
function Header() {
  const user = useAppStore((s) => s.user);
  const theme = useAppStore((s) => s.theme);
  const toggleTheme = useAppStore((s) => s.toggleTheme);
  // Só re-renderiza quando user ou theme realmente mudam
  return <header>...</header>;
}

Análise Detalhada

Como Funciona

React Context re-renderiza todo consumidor sempre que o valor do provider muda. Mesmo que um consumidor use apenas theme, ele re-renderiza quando notifications muda.
Zustand usa assinaturas internas com seletores. Cada componente assina fatias de estado específicas e só re-renderiza quando essa fatia muda.
Context requer um componente Provider na árvore. Stores Zustand são singletons em nível de módulo acessíveis de qualquer lugar.
Context naturalmente escopa o estado para uma subárvore. Zustand é global por padrão, mas pode ser escopado usando createStore + useStore com um Context.
Atualizações de estado do Zustand são síncronas e agrupadas pelo React 18+. Atualizações de estado do Context passam pelo mecanismo setState do React.

Variações

Quando Context ainda é a escolha certa:

// Tema, localidade ou status de autenticação que raramente mudam
// e naturalmente se escopam para uma subárvore
const ThemeContext = createContext<"light" | "dark">("light");
 
// Feature flags por segmento de rota
const FeatureFlagContext = createContext<Record<string, boolean>>({});
 
// Estado de formulário escopado para um único formulário
const FormContext = createContext<FormState | null>(null);

Zustand com Context para escopo SSR:

import { createStore, useStore } from "zustand";
import { createContext, useContext, useRef } from "react";
 
type CounterStore = ReturnType<typeof createCounterStore>;
 
const createCounterStore = (initialCount = 0) =>
  createStore<{ count: number; increment: () => void }>((set) => ({
    count: initialCount,
    increment: () => set((s) => ({ count: s.count + 1 })),
  }));
 
const CounterContext = createContext<CounterStore | null>(null);
 
export function CounterProvider({
  children,
  initialCount,
}: {
  children: React.ReactNode;
  initialCount?: number;
}) {
  const storeRef = useRef<CounterStore>();
  if (!storeRef.current) {
    storeRef.current = createCounterStore(initialCount);
  }
  return (
    <CounterContext.Provider value={storeRef.current}>
      {children}
    </CounterContext.Provider>
  );
}
 
export function useCounterStore<T>(selector: (s: { count: number; increment: () => void }) => T) {
  const store = useContext(CounterContext);
  if (!store) throw new Error("Missing CounterProvider");
  return useStore(store, selector);
}

Notas TypeScript

Tipos de Context exigem tipos de valor e ação separados ou uma interface combinada.
Tipos Zustand são mais simples, pois estado e ações vivem na mesma interface.
Ambas as abordagens funcionam com TypeScript. O padrão de seletor do Zustand fornece melhor inferência de tipo.

Armadilhas

Context não é "lento". É apropriado para estado de baixa frequência. O problema de performance só aparece com muitos consumidores e atualizações frequentes.
Dividir Context em múltiplos providers (um para estado, um para ações) pode reduzir re-renderizações desnecessárias, mas adiciona complexidade.
Stores Zustand são singletons. Em SSR, todas as requisições compartilham o mesmo store, a menos que você use o padrão Context + createStore.
Migrar de Context para Zustand requer remover o wrapper Provider e mudar chamadas useContext para chamadas useStore(selector). Faça isso incrementalmente.
useMemo no valor do Context ajuda, mas não resolve o problema fundamental de re-renderização quando qualquer valor muda.
Zustand não se integra nativamente com React DevTools (use Redux DevTools via middleware devtools). O estado do Context aparece no React DevTools.

Alternativas

Abordagem	Prós	Contras
React Context	Embutido, sem dependências, escopo de árvore	Re-renderiza todos os consumidores a cada mudança
Zustand	Re-renderizações seletivas, sem provider, API simples	Singleton global, considerações de SSR
Jotai	Modelo atômico, provider opcional	Modelo mental diferente
Redux Toolkit	Maduro, ótimas DevTools	Boilerplate, curva de aprendizado íngreme
use(Context) + useMemo	Reduz algumas re-renderizações	Não resolve o problema central

FAQs

Por que o React Context re-renderiza todos os consumidores quando qualquer valor muda?

Context fornece um único objeto de valor para todos os consumidores.
Quando qualquer propriedade nesse objeto muda, o React re-renderiza cada componente que chama useContext nele.
Não há um mecanismo de seletor embutido para assinar campos específicos.

Como o Zustand evita o problema de re-renderização que o Context tem?

Zustand usa assinaturas internas com funções seletoras.
Cada componente assina uma fatia de estado específica e só re-renderiza quando essa fatia muda.
Isso é fundamentalmente diferente da abordagem "tudo ou nada" do Context.

Quando o React Context ainda é a escolha certa em vez do Zustand?

Para estado de baixa frequência e raramente mutável: tema, localidade, status de autenticação.
Quando o estado naturalmente se escopa para uma subárvore (por exemplo, estado de formulário dentro de um formulário).
Quando você quer zero dependências externas.

O Zustand requer um componente Provider?

Não. Stores Zustand são singletons em nível de módulo acessíveis de qualquer lugar.
Exceção: em SSR/Next.js, use Context + createStore para escopar stores por requisição.

Como migrar um componente de Context para Zustand?

// Antes (Context):
const { user, theme } = useApp();
 
// Depois (Zustand):
const user = useAppStore((s) => s.user);
const theme = useAppStore((s) => s.theme);

Remova o wrapper Provider e mude as chamadas useContext para useStore(selector).

Armadilha: O React Context é realmente lento?

O Context em si não é lento. O problema de performance só aparece com muitos consumidores e atualizações frequentes.
Para estado que muda raramente (como tema), Context é perfeitamente aceitável.

Armadilha: Envolver o valor do Context em `useMemo` resolve o problema de re-renderização?

useMemo reduz re-renderizações causadas pela re-renderização do provider.
Mas não resolve o problema central: qualquer mudança em qualquer propriedade do valor re-renderiza todos os consumidores.

É possível dividir o Context em múltiplos providers para reduzir re-renderizações?

Sim. Um provider para estado e um para ações reduz algumas re-renderizações desnecessárias.
Mas isso adiciona complexidade e ainda não fornece assinaturas baseadas em seletores.

Como escopar um store Zustand para uma subárvore (como o Context faz naturalmente)?

const StoreContext = createContext<MyStore | null>(null);
 
function Provider({ children }) {
  const storeRef = useRef(createStore<State>((set) => ({ ... })));
  return (
    <StoreContext.Provider value={storeRef.current}>
      {children}
    </StoreContext.Provider>
  );
}

Use createStore (vanilla) + Context + useStore para instâncias por subárvore.

Como os tipos TypeScript diferem entre as abordagens Context e Zustand?

Context exige tipos de valor e ação separados, além de uma verificação de null em useContext.
Zustand combina estado e ações em uma única interface com inferência de tipo de seletor automática.
O padrão de seletor do Zustand fornece melhor inferência de tipo.

O Zustand se integra com o React DevTools?

Não diretamente. Stores Zustand não aparecem no React DevTools.
Use o middleware devtools para se conectar ao Redux DevTools em vez disso.
O estado do Context aparece no React DevTools por padrão.

Links Relacionados

Receita

// Context: Bom para estado raramente mutável, com escopo de provider
const ThemeContext = createContext<"light" | "dark">("light");
 
// Zustand: Bom para estado global frequentemente mutável com muitos consumidores
const useCartStore = create<CartStore>((set) => ({
  items: [],
  addItem: (item) => set((s) => ({ items: [...s.items, item] })),
}));

Exemplo de Trabalho

// ANTES: Estado baseado em Context (causa re-renderizações em todos os consumidores)
// context/app-context.tsx
"use client";
 
import { createContext, useContext, useState, useCallback, ReactNode } from "react";
 
interface AppState {
  user: { name: string } | null;
  theme: "light" | "dark";
  notifications: string[];
  sidebarOpen: boolean;
}
 
interface AppContextValue extends AppState {
  setUser: (user: AppState["user"]) => void;
  toggleTheme: () => void;
  addNotification: (msg: string) => void;
  toggleSidebar: () => void;
}
 
const AppContext = createContext<AppContextValue | null>(null);
 
export function AppProvider({ children }: { children: ReactNode }) {
  const [user, setUser] = useState<AppState["user"]>(null);
  const [theme, setTheme] = useState<AppState["theme"]>("light");
  const [notifications, setNotifications] = useState<string[]>([]);
  const [sidebarOpen, setSidebarOpen] = useState(true);
 
  const toggleTheme = useCallback(() => {
    setTheme((t) => (t === "light" ? "dark" : "light"));
  }, []);
 
  const addNotification = useCallback((msg: string) => {
    setNotifications((n) => [...n, msg]);
  }, []);
 
  const toggleSidebar = useCallback(() => {
    setSidebarOpen((s) => !s);
  }, []);
 
  // Problema: novo objeto a cada renderização -> todos os consumidores re-renderizam
  return (
    <AppContext.Provider
      value={{
        user, theme, notifications, sidebarOpen,
        setUser, toggleTheme, addNotification, toggleSidebar,
      }}
    >
      {children}
    </AppContext.Provider>
  );
}
 
export const useApp = () => {
  const ctx = useContext(AppContext);
  if (!ctx) throw new Error("useApp deve estar dentro de AppProvider");
  return ctx;
};

// DEPOIS: Store Zustand (re-renderizações seletivas, sem necessidade de provider)
// stores/app-store.ts
import { create } from "zustand";
 
interface AppStore {
  user: { name: string } | null;
  theme: "light" | "dark";
  notifications: string[];
  sidebarOpen: boolean;
  setUser: (user: AppStore["user"]) => void;
  toggleTheme: () => void;
  addNotification: (msg: string) => void;
  toggleSidebar: () => void;
}
 
export const useAppStore = create<AppStore>((set) => ({
  user: null,
  theme: "light",
  notifications: [],
  sidebarOpen: true,
 
  setUser: (user) => set({ user }),
  toggleTheme: () => set((s) => ({ theme: s.theme === "light" ? "dark" : "light" })),
  addNotification: (msg) => set((s) => ({ notifications: [...s.notifications, msg] })),
  toggleSidebar: () => set((s) => ({ sidebarOpen: !s.sidebarOpen })),
}));

// Migração de componente
// ANTES:
function Header() {
  const { user, theme, toggleTheme } = useApp();
  // Re-renderiza quando notifications ou sidebarOpen também mudam
  return <header>...</header>;
}
 
// DEPOIS:
function Header() {
  const user = useAppStore((s) => s.user);
  const theme = useAppStore((s) => s.theme);
  const toggleTheme = useAppStore((s) => s.toggleTheme);
  // Só re-renderiza quando user ou theme realmente mudam
  return <header>...</header>;
}

Análise Detalhada

Como Funciona

React Context re-renderiza todo consumidor sempre que o valor do provider muda. Mesmo que um consumidor use apenas theme, ele re-renderiza quando notifications muda.
Zustand usa assinaturas internas com seletores. Cada componente assina fatias de estado específicas e só re-renderiza quando essa fatia muda.
Context requer um componente Provider na árvore. Stores Zustand são singletons em nível de módulo acessíveis de qualquer lugar.
Context naturalmente escopa o estado para uma subárvore. Zustand é global por padrão, mas pode ser escopado usando createStore + useStore com um Context.
Atualizações de estado do Zustand são síncronas e agrupadas pelo React 18+. Atualizações de estado do Context passam pelo mecanismo setState do React.

Variações

Quando Context ainda é a escolha certa:

// Tema, localidade ou status de autenticação que raramente mudam
// e naturalmente se escopam para uma subárvore
const ThemeContext = createContext<"light" | "dark">("light");
 
// Feature flags por segmento de rota
const FeatureFlagContext = createContext<Record<string, boolean>>({});
 
// Estado de formulário escopado para um único formulário
const FormContext = createContext<FormState | null>(null);

Zustand com Context para escopo SSR:

import { createStore, useStore } from "zustand";
import { createContext, useContext, useRef } from "react";
 
type CounterStore = ReturnType<typeof createCounterStore>;
 
const createCounterStore = (initialCount = 0) =>
  createStore<{ count: number; increment: () => void }>((set) => ({
    count: initialCount,
    increment: () => set((s) => ({ count: s.count + 1 })),
  }));
 
const CounterContext = createContext<CounterStore | null>(null);
 
export function CounterProvider({
  children,
  initialCount,
}: {
  children: React.ReactNode;
  initialCount?: number;
}) {
  const storeRef = useRef<CounterStore>();
  if (!storeRef.current) {
    storeRef.current = createCounterStore(initialCount);
  }
  return (
    <CounterContext.Provider value={storeRef.current}>
      {children}
    </CounterContext.Provider>
  );
}
 
export function useCounterStore<T>(selector: (s: { count: number; increment: () => void }) => T) {
  const store = useContext(CounterContext);
  if (!store) throw new Error("Missing CounterProvider");
  return useStore(store, selector);
}

Notas TypeScript

Tipos de Context exigem tipos de valor e ação separados ou uma interface combinada.
Tipos Zustand são mais simples, pois estado e ações vivem na mesma interface.
Ambas as abordagens funcionam com TypeScript. O padrão de seletor do Zustand fornece melhor inferência de tipo.

Armadilhas

Context não é "lento". É apropriado para estado de baixa frequência. O problema de performance só aparece com muitos consumidores e atualizações frequentes.
Dividir Context em múltiplos providers (um para estado, um para ações) pode reduzir re-renderizações desnecessárias, mas adiciona complexidade.
Stores Zustand são singletons. Em SSR, todas as requisições compartilham o mesmo store, a menos que você use o padrão Context + createStore.
Migrar de Context para Zustand requer remover o wrapper Provider e mudar chamadas useContext para chamadas useStore(selector). Faça isso incrementalmente.
useMemo no valor do Context ajuda, mas não resolve o problema fundamental de re-renderização quando qualquer valor muda.
Zustand não se integra nativamente com React DevTools (use Redux DevTools via middleware devtools). O estado do Context aparece no React DevTools.

Alternativas

Abordagem	Prós	Contras
React Context	Embutido, sem dependências, escopo de árvore	Re-renderiza todos os consumidores a cada mudança
Zustand	Re-renderizações seletivas, sem provider, API simples	Singleton global, considerações de SSR
Jotai	Modelo atômico, provider opcional	Modelo mental diferente
Redux Toolkit	Maduro, ótimas DevTools	Boilerplate, curva de aprendizado íngreme
use(Context) + useMemo	Reduz algumas re-renderizações	Não resolve o problema central

FAQs

Por que o React Context re-renderiza todos os consumidores quando qualquer valor muda?

Context fornece um único objeto de valor para todos os consumidores.
Quando qualquer propriedade nesse objeto muda, o React re-renderiza cada componente que chama useContext nele.
Não há um mecanismo de seletor embutido para assinar campos específicos.

Como o Zustand evita o problema de re-renderização que o Context tem?

Zustand usa assinaturas internas com funções seletoras.
Cada componente assina uma fatia de estado específica e só re-renderiza quando essa fatia muda.
Isso é fundamentalmente diferente da abordagem "tudo ou nada" do Context.

Quando o React Context ainda é a escolha certa em vez do Zustand?

Para estado de baixa frequência e raramente mutável: tema, localidade, status de autenticação.
Quando o estado naturalmente se escopa para uma subárvore (por exemplo, estado de formulário dentro de um formulário).
Quando você quer zero dependências externas.

O Zustand requer um componente Provider?

Não. Stores Zustand são singletons em nível de módulo acessíveis de qualquer lugar.
Exceção: em SSR/Next.js, use Context + createStore para escopar stores por requisição.

Como migrar um componente de Context para Zustand?

// Antes (Context):
const { user, theme } = useApp();
 
// Depois (Zustand):
const user = useAppStore((s) => s.user);
const theme = useAppStore((s) => s.theme);

Remova o wrapper Provider e mude as chamadas useContext para useStore(selector).

Armadilha: O React Context é realmente lento?

O Context em si não é lento. O problema de performance só aparece com muitos consumidores e atualizações frequentes.
Para estado que muda raramente (como tema), Context é perfeitamente aceitável.

Armadilha: Envolver o valor do Context em `useMemo` resolve o problema de re-renderização?

useMemo reduz re-renderizações causadas pela re-renderização do provider.
Mas não resolve o problema central: qualquer mudança em qualquer propriedade do valor re-renderiza todos os consumidores.

É possível dividir o Context em múltiplos providers para reduzir re-renderizações?

Sim. Um provider para estado e um para ações reduz algumas re-renderizações desnecessárias.
Mas isso adiciona complexidade e ainda não fornece assinaturas baseadas em seletores.

Como escopar um store Zustand para uma subárvore (como o Context faz naturalmente)?

const StoreContext = createContext<MyStore | null>(null);
 
function Provider({ children }) {
  const storeRef = useRef(createStore<State>((set) => ({ ... })));
  return (
    <StoreContext.Provider value={storeRef.current}>
      {children}
    </StoreContext.Provider>
  );
}

Use createStore (vanilla) + Context + useStore para instâncias por subárvore.

Como os tipos TypeScript diferem entre as abordagens Context e Zustand?

Context exige tipos de valor e ação separados, além de uma verificação de null em useContext.
Zustand combina estado e ações em uma única interface com inferência de tipo de seletor automática.
O padrão de seletor do Zustand fornece melhor inferência de tipo.

O Zustand se integra com o React DevTools?

Não diretamente. Stores Zustand não aparecem no React DevTools.
Use o middleware devtools para se conectar ao Redux DevTools em vez disso.
O estado do Context aparece no React DevTools por padrão.

Context vs Zustand

Buscar na documentação

Context vs Zustand