Guia de gerenciamento de estado no Next.js: Zustand vs Jotai na prática

A mensagem de erro apareceu de novo — já era a 17ª alteração no action creator do Redux. O projeto só tinha um carrinho, mas já contava com três arquivos de configuração.

Por que tudo precisava ser tão complicado? Redux parecia usar um canhão para matar uma mosca em um projeto pequeno. Tentei trocar para a Context API, mas uma única atualização de estado fazia metade da página renderizar novamente. Aquele painel de desempenho todo vermelho já dava dor de cabeça.

É por isso que Zustand e Jotai ganharam tanta popularidade nos últimos dois anos: ambos prometem leveza e alto desempenho. Mas qual escolher? Neste artigo, vamos ver:

• Por que Redux e Context podem ser difíceis de usar na prática
• Qual é a diferença essencial entre Zustand e Jotai
• Em que cenário escolher cada um, com uma árvore de decisão
• Como usá-los no Next.js App Router e quais armadilhas evitar

Por que não usar Redux e Context?

O que torna o Redux tão “pesado”?

Comecemos pelo Redux. Ele não é ruim; apenas é exagerado para muitos projetos.

Você precisa escrever action types, action creators e reducers, além de configurar a store. Um recurso simples como “adicionar ao carrinho” pode exigir alterações em três ou quatro arquivos. Depois de algum tempo, tanto código repetitivo realmente cansa.

Mais importante: se houver iniciantes na equipe, a curva de aprendizado do Redux é considerável. O que é dispatch? Por que usar pure functions? Para que serve um middleware? É preciso dedicar tempo a esses conceitos.

Em um projeto pequeno, como uma lista de tarefas ou um blog pessoal, Redux é como ir de tanque ao mercado: funciona, mas não é necessário.

A armadilha de desempenho da Context API

E o Context? Ele é simples, vem com o React e não exige a instalação de nenhuma biblioteca.

Mas há um grande problema: o desempenho.

O Context funciona assim: quando o value do Provider muda, todos os componentes que consomem aquele Context são renderizados novamente. Mesmo que um componente use apenas um dos campos, ele ainda passa por todo o processo de renderização.

Uma vez, usei Context para gerenciar os campos de um formulário. O onChange de um único input fez os 20 componentes da página renderizarem de novo. O flame chart do Chrome DevTools era doloroso de ver.

É possível otimizar com memo, useMemo e a divisão do Context. Mas, sinceramente, depois dessas otimizações, o código já não fica muito mais simples do que Redux.

O apelo das soluções leves

É por isso que Zustand e Jotai são tão populares.

A promessa é bem clara:

• API simples e adoção rápida — dá para aprender Zustand em 10 minutos
• Otimização de desempenho integrada, sem trabalho manual
• Bundle pequeno — Zustand tem apenas 1 KB e fica ainda menor após gzip

Os dados também apontam nessa direção. Segundo estatísticas de 2025, o uso do Zustand cresceu 150% no período de um ano. Cada vez mais desenvolvedores abandonam Redux e migram para soluções leves.

Isso traz uma nova pergunta: Zustand ou Jotai?

Principais diferenças entre Zustand e Jotai

À primeira vista, as duas bibliotecas oferecem “gerenciamento de estado leve”, mas suas ideias fundamentais são completamente diferentes.

Modelo de estado: uma loja única vs pequenos átomos

A documentação oficial resume bem: “Zustand is like Redux. Jotai is like Recoil.”

Zustand é, em essência, uma versão simplificada do Redux. Você tem uma store com todo o estado dentro dela, como um shopping que concentra todos os produtos.

// Zustand: uma grande store
const useStore = create((set) => ({
  user: null,
  cart: [],
  theme: 'light',
  // Todo o estado fica aqui
}))

Jotai segue um modelo atômico. Cada estado é um atom independente, como pequenas barracas que funcionam separadamente.

// Jotai: atoms independentes
const userAtom = atom(null)
const cartAtom = atom([])
const themeAtom = atom('light')

Essa diferença de design determina diretamente os cenários mais adequados para cada biblioteca.

Local de armazenamento: fora do módulo vs dentro da árvore de componentes

A store do Zustand fica no nível do módulo, fora do React. Você pode importá-la e atualizá-la em qualquer lugar, sem precisar de Provider.

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

Os atoms do Jotai vivem na árvore de componentes e dependem de Context. Para compartilhar o estado entre componentes, é preciso envolver a raiz com um Provider.

O que isso significa?

Se você precisa atualizar o estado fora de componentes React — em uma função utilitária ou no callback de um WebSocket, por exemplo — Zustand é muito mais conveniente. Jotai também permite isso, mas o caminho é menos direto.

Desempenho: otimização manual vs granularidade automática

As duas bibliotecas adotam estratégias diferentes de desempenho.

Com as inscrições atômicas do Jotai, o comportamento padrão já é otimizado. Um componente assina apenas os atoms que usa, e mudanças em outros atoms não disparam nova renderização.

No Zustand, você precisa usar um selector para otimizar:

// Não recomendado: assina toda a store
const store = useStore()

// Recomendado: usa um selector para assinar apenas o necessário
const user = useStore(state => state.user)

Por outro lado, escrever selectors no Zustand não é difícil e o resultado é intuitivo. Você só precisa lembrar de usá-los para não cair nessa armadilha.

Resumo em uma frase

• Zustand: uma única store, fora do React, com selectors manuais
• Jotai: atoms independentes, dentro do React, com otimização automática de desempenho

A escolha depende das características do projeto.

Quando escolher Zustand?

Comecemos pelo Zustand. Se o projeto tiver as características abaixo, ele provavelmente será a melhor opção.

Aplicações pequenas ou médias, sem complexidade desnecessária

Na prática, a maioria dos projetos não precisa de um gerenciamento de estado complexo.

Em um e-commerce, por exemplo, o estado global costuma se resumir aos dados do usuário, ao carrinho e às preferências de tema. Zustand se encaixa muito bem nesse cenário.

A API é tão simples que quase não exige estudo. Veja um exemplo completo:

// store.js
import create from 'zustand'

const useStore = create((set) => ({
  cart: [],
  addToCart: (item) => set((state) => ({
    cart: [...state.cart, item]
  })),
  removeFromCart: (id) => set((state) => ({
    cart: state.cart.filter(item => item.id !== id)
  })),
}))

// CartButton.jsx
function CartButton() {
  const addToCart = useStore(state => state.addToCart)
  return <button onClick={() => addToCart(item)}>Adicionar ao carrinho</button>
}

// CartCount.jsx
function CartCount() {
  const count = useStore(state => state.cart.length)
  return <span>{count}</span>
}

Percebeu? Não há Provider, action types nem reducer. Você define o estado e os métodos e já pode usá-los.

Um integrante novo da equipe entende esse código em 10 minutos.

Quando é preciso atualizar o estado fora do React

Essa é uma vantagem particular do Zustand.

Imagine uma conexão WebSocket que precisa atualizar o estado ao receber uma mensagem:

// websocket.js
import { useStore } from './store'

socket.on('message', (data) => {
  // Chama o método da store diretamente, fora de um componente
  useStore.getState().updateMessages(data)
})

Ou uma função utilitária que toma uma decisão com base no estado atual:

// utils.js
import { useStore } from './store'

export function checkPermission() {
  const user = useStore.getState().user
  return user?.role === 'admin'
}

Jotai é menos conveniente nesse cenário. Como os atoms estão vinculados à árvore de componentes, o acesso externo exige mais trabalho.

Boa integração com SSR no Next.js

O suporte do Zustand ao Next.js é muito bem desenvolvido.

A documentação oficial tem uma seção dedicada à integração com Next.js e apresenta boas práticas para o App Router. Além disso, há muita experiência compartilhada pela comunidade, então costuma ser fácil encontrar soluções para problemas comuns.

Se você usa o App Router do Next.js 13 ou posterior, Zustand é atualmente uma das opções mais estáveis. Mais adiante veremos a configuração em detalhes.

Quando Zustand não é a melhor opção?

Há um cenário em que Zustand talvez não seja ideal: quando existem relações derivadas complexas entre os estados.

Imagine um filtro com dez critérios, em que as opções de cada critério dependem dos valores atuais dos demais. Nesse caso, o código em Zustand pode ficar difícil de acompanhar.

É aí que o design atômico do Jotai se destaca.

Quando escolher Jotai?

O design atômico do Jotai é extremamente útil em determinados cenários.

Relações complexas entre estados

Essa é a especialidade do Jotai.

Imagine um filtro de produtos:

• Há critérios como “marca”, “faixa de preço” e “avaliação”
• A lista de marcas disponíveis depende da faixa de preço atual
• A lista final de produtos depende de todos os critérios

Com Zustand, é preciso gerenciar essas dependências manualmente, e o código pode ficar confuso.

Em Jotai, a implementação fica bem clara:

// Atoms básicos
const brandAtom = atom([])
const priceRangeAtom = atom([0, 1000])
const ratingAtom = atom(0)

// Atom derivado: marcas disponíveis (depende da faixa de preço)
const availableBrandsAtom = atom((get) => {
  const priceRange = get(priceRangeAtom)
  return fetchBrands(priceRange) // Reage automaticamente às mudanças em priceRange
})

// Atom derivado: produtos filtrados (depende de todos os critérios)
const filteredProductsAtom = atom((get) => {
  const brands = get(brandAtom)
  const priceRange = get(priceRangeAtom)
  const rating = get(ratingAtom)
  return products.filter(/* Lógica de filtragem */)
})

Cada atom se preocupa apenas com os atoms dos quais depende, e o Jotai rastreia as dependências automaticamente. Quando algo muda, os atoms relacionados são atualizados.

O uso no componente também é simples:

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

function FilterPanel() {
  const [brands, setBrands] = useAtom(brandAtom)
  const availableBrands = useAtomValue(availableBrandsAtom)
  // Quando brands muda, availableBrands é recalculado automaticamente
}

Nesse cenário, o código em Jotai fica muito mais claro do que em Zustand.

Cenários com exigência máxima de desempenho

As inscrições atômicas do Jotai realmente oferecem bom desempenho.

Imagine um dashboard em tempo real com 50 componentes, cada um exibindo um indicador diferente. Com Context ou Zustand sem otimização, uma atualização pode fazer muitos componentes renderizarem novamente.

Isso não acontece no Jotai. Cada componente assina apenas o próprio atom, e as atualizações dos demais não o afetam.

A documentação oficial é clara: “This is the most performant by default.” Um componente só renderiza novamente quando o atom específico que ele assina muda.

Aplicações grandes que precisam de code splitting

Os atoms do Jotai podem ser carregados sob demanda.

Você pode distribuir os atoms em arquivos diferentes e importá-los apenas quando forem usados. Isso ajuda no carregamento inicial de aplicações grandes.

A store do Zustand costuma ser um bloco único. Também é possível dividi-la, mas o processo não é tão natural quanto em Jotai.

Projetos que usam Suspense intensivamente

Se o projeto usa muito React Suspense, por exemplo para carregar dados assíncronos, Jotai oferece suporte nativo.

É muito simples criar um atom assíncrono:

const userAtom = atom(async () => {
  const res = await fetch('/api/user')
  return res.json()
})

function UserProfile() {
  const user = useAtomValue(userAtom)
  // Suspense automático: renderiza depois que os dados carregam
  return <div>{user.name}</div>
}

Zustand também pode trabalhar com Suspense, mas exige uma camada adicional, enquanto Jotai oferece uma integração mais natural.

A curva de aprendizado do Jotai

Por outro lado, os conceitos do Jotai são um pouco mais difíceis do que os do Zustand.

Leitura e escrita de atoms, atoms derivados e atoms assíncronos exigem algum tempo de aprendizado. Se a equipe tiver iniciantes, a adoção será mais lenta do que com Zustand.

Além disso, para ser sincero, a documentação do Jotai não é tão amigável quanto a do Zustand. Pode ser necessário reler algumas seções para entender bem as APIs.

Boas práticas no Next.js App Router

Depois da teoria, vamos à prática. Ao usar essas bibliotecas no App Router do Next.js 13 ou posterior, há algumas armadilhas importantes.

A forma correta de usar Zustand no Next.js

Grande armadilha: não use uma store global

Muita gente, inclusive eu no começo, escreve assim:

// ❌ Incorreto: store global
import create from 'zustand'

const useStore = create((set) => ({
  user: null,
  setUser: (user) => set({ user })
}))

Isso funciona na renderização do cliente, mas, no ambiente SSR do Next.js, a store pode ser compartilhada entre requisições. Os dados do usuário A podem acabar visíveis para o usuário B, o que representa um risco de segurança.

A abordagem recomendada oficialmente é o padrão Store Factory:

// lib/store.js
import { createStore } from 'zustand/vanilla'

export function createUserStore(initialState) {
  return createStore((set) => ({
    user: initialState?.user || null,
    setUser: (user) => set({ user })
  }))
}

Em seguida, crie um Provider em um componente cliente:

// components/StoreProvider.jsx
'use client'

import { createContext, useContext, useRef } from 'react'
import { useStore } from 'zustand'
import { createUserStore } from '@/lib/store'

const StoreContext = createContext(null)

export function StoreProvider({ children, initialState }) {
  const storeRef = useRef()
  if (!storeRef.current) {
    storeRef.current = createUserStore(initialState)
  }

  return (
    <StoreContext.Provider value={storeRef.current}>
      {children}
    </StoreContext.Provider>
  )
}

export function useUserStore(selector) {
  const store = useContext(StoreContext)
  return useStore(store, selector)
}

Use-o no layout raiz:

// app/layout.jsx
import { StoreProvider } from '@/components/StoreProvider'

export default function RootLayout({ children }) {
  // Os dados podem ser buscados previamente aqui
  const initialState = { user: null }

  return (
    <html>
      <body>
        <StoreProvider initialState={initialState}>
          {children}
        </StoreProvider>
      </body>
    </html>
  )
}

Assim, cada requisição tem sua própria store e os dados não se misturam.

Pontos de atenção:

• Server Components não podem ler nem escrever diretamente na store
• Busque os dados no servidor e passe-os ao cliente por initialState
• Não faça uma busca bloqueante de dados no layout raiz, pois isso prejudica o desempenho

O problema de hydration do Jotai em SSR

A maior armadilha do Jotai no Next.js são os erros de hydration.

Crie um Provider independente para cada requisição:

// app/providers.jsx
'use client'

import { Provider } from 'jotai'

export function Providers({ children }) {
  return <Provider>{children}</Provider>
}

// app/layout.jsx
import { Providers } from './providers'

export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        <Providers>{children}</Providers>
      </body>
    </html>
  )
}

Como lidar com dados do servidor:

Para injetar dados do servidor nos atoms, use useHydrateAtoms:

'use client'

import { useHydrateAtoms } from 'jotai/utils'
import { userAtom } from '@/atoms'

export function HydrateAtoms({ initialUser, children }) {
  useHydrateAtoms([[userAtom, initialUser]])
  return children
}

Mas há uma armadilha: useHydrateAtoms só tem efeito na primeira renderização. Se você navegar com router.push no App Router, uma segunda visita ao mesmo atom não fará uma nova hydration.

Soluções:

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

1. Colocar o Provider em template.tsx, e não em layout.tsx, para recriá-lo a cada rota
2. Usar um Provider no nível da página, em vez de um Provider global

Erro de hydration com atomWithStorage:

Ao usar atomWithStorage para guardar dados de formulário, pode haver uma diferença entre a renderização do servidor e a hydration no cliente:

• Servidor: o formulário está vazio
• Cliente: os dados são lidos de localStorage e o formulário está preenchido
• Resultado: erro de React hydration mismatch

Solução: preencha o formulário dentro de useEffect ou use useHydrateAtoms com useSyncExternalStore.

Princípios gerais para as duas bibliotecas

1. Server Components não podem usar gerenciamento de estado

   • Server Components não têm hooks e não podem usar useStore nem useAtom
   • Componentes que precisam de estado devem ser marcados com 'use client'

2. A posição do Provider é importante

   • Quanto mais profundo ele estiver, melhor o Next.js poderá otimizar as partes estáticas
   • Ele ainda precisa estar acessível a todos os componentes que usam o estado

3. Evite bloquear o layout raiz

   • Não use await fetch() no root layout para buscar os dados do usuário
   • Isso anula vantagens de desempenho do streaming e dos Server Components
   • Use um componente cliente dedicado à obtenção e à inicialização dos dados

Eu já caí em todas essas armadilhas. Lembrar desses princípios economiza muito tempo de depuração.

Minha recomendação de escolha

Depois de tudo isso, talvez você ainda pergunte: qual dos dois escolher?

Sinceramente, não há uma resposta universal. Mas posso oferecer uma árvore de decisão.

Árvore de decisão rápida

Se o seu projeto for…

1. Projeto pessoal simples ou aplicação pequena
   → Comece com Context API; se for suficiente, não troque
   → Se surgirem problemas de desempenho, adote Zustand

2. Aplicação SaaS média ou e-commerce
   → Comece diretamente com Zustand
   → É simples, estável e fácil para a equipe aprender

3. Dashboard complexo ou aplicação em tempo real
   → Considere Jotai
   → Quando as dependências entre estados são complexas, Jotai fica mais claro

4. Equipe grande ou requisitos rígidos de padronização
   → Redux Toolkit pode ser mais adequado
   → Ele oferece mais restrições e boas práticas

5. Necessidade de atualizar o estado fora do React
   → Zustand é a primeira escolha
   → Jotai também consegue, mas de forma menos natural

6. Uso intensivo de Suspense
   → Jotai oferece uma experiência melhor
   → Atoms assíncronos têm suporte nativo

Estratégia gradual

Eu recomendo uma escolha gradual:

1. Primeira etapa: Context API

   • O projeto está começando e ainda tem pouco estado: use Context
   • Se for suficiente, não migre; evite otimização prematura

2. Segunda etapa: Zustand

   • O desempenho do Context começou a causar problemas
   • Ou o estado global ficou mais complexo
   • Zustand resolve 80% dos cenários

3. Terceira etapa: Jotai ou continuar com Zustand

   • Dependências entre estados muito complexas → Jotai
   • Caso contrário, continue com Zustand
   • Não escolha tecnologia apenas pela tecnologia

É possível usar os dois juntos?

Sim!

Zustand e Jotai não entram em conflito. Já vi projetos que:

• Usavam Zustand para configurações globais, como usuário e tema
• Usavam Jotai para estados complexos de formulário

Não há problema nisso. Escolha a ferramenta mais adequada para resolver cada problema concreto.

Minha experiência prática

Estas são as escolhas que faço:

• Blog pessoal: sem biblioteca de estado; Server Components + estado na URL são suficientes
• Sistemas administrativos: Zustand, junto com React Query para o estado do servidor
• Dashboard em tempo real: Jotai, porque as dependências de estado são complexas demais e ficam difíceis em Zustand

O ponto principal é não ficar preso à escolha tecnológica logo no começo. Use primeiro a solução mais simples e evolua quando encontrar um problema real.

Em muitos projetos, Context API é suficiente. Não a subestime.

Conclusão

Voltando às perguntas do início.

Redux é pesado demais? Sim, para muitos projetos ele é um canhão para matar uma mosca.

Context tem desempenho ruim? Sem otimização, novas renderizações realmente podem se tornar um gargalo.

Zustand ou Jotai? Depende do cenário:

• Na maioria dos casos, Zustand é suficiente, simples e estável
• Para dependências de estado complexas, Jotai é mais elegante
• Está em dúvida? Comece com Zustand e só mude se ele realmente não atender

Como usar no Next.js App Router? Lembre de três pontos:

• Não use uma store global
• Use um Provider independente por requisição
• Não use gerenciamento de estado em Server Components

Uma última observação.

Não existe resposta universal para escolhas tecnológicas. Não siga cegamente comparações da internet, nem mesmo esta. O mais importante é escolher uma solução com a qual você e sua equipe trabalhem bem e que resolva o problema real.

Se ainda estiver em dúvida, escolha uma opção, crie um demo e experimente. Dez minutos de prática ensinam mais do que dez artigos.

Espero que você encontre a ferramenta certa.