Se tem um tema que divide front-end sênior, é esse. Estado. Todo projeto começa simples:

um useState aqui
um contexto ali
um fetch direto no componente

E quando você percebe… 👉 tem estado duplicado 👉 dados inconsistentes 👉 bugs que só aparecem em produção Bem-vindo ao caos moderno.

O erro raiz: tratar tudo como o mesmo tipo de estado

Esse é o ponto que quase ninguém explica direito. Nem todo estado é igual. E misturar tudo é o começo do problema.

Server State vs Client State

Essa distinção muda completamente sua arquitetura.

Server State

Dados que vêm do backend:

lista de usuários
pedidos
dados de API

Características:

assíncrono
pode ficar desatualizado
precisa de cache
pode ser compartilhado entre telas

Client State

Estado local da aplicação:

modal aberto/fechado
tema
inputs de formulário

Características:

síncrono
controlado pela UI
não precisa de persistência remota

O erro clássico

function Users() {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    fetch('/api/users')
      .then(res => res.json())
      .then(setUsers);
  }, []);

  return <UserList users={users} />;
}

Parece simples. Mas agora você precisa:

refetch automático
cache
loading global
erro
sincronização entre telas

👉 Esse código não escala.

Server State do jeito certo

Aqui entram libs como React Query.

Exemplo real com React Query

// api/users.ts
export async function fetchUsers() {
  const res = await fetch('/api/users');

  if (!res.ok) {
    throw new Error('Erro ao buscar usuários');
  }

  return res.json();
}

// hooks/useUsers.ts
import { useQuery } from '@tanstack/react-query';
import { fetchUsers } from '../api/users';

export function useUsers() {
  return useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
    staleTime: 1000 * 60, // 1 min
  });
}

// Users.tsx
export function Users() {
  const { data, isLoading, error } = useUsers();

  if (isLoading) return <p>Carregando...</p>;
  if (error) return <p>Erro ao carregar</p>;

  return (
    <ul>
      {data.map(user => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

O que você ganhou aqui

cache automático
revalidação
controle de loading e erro
sincronização entre componentes

👉 Isso é nível produção.

Quando NÃO usar Redux

Vamos falar a real. Redux foi essencial por muito tempo. Mas hoje… 👉 na maioria dos casos, é overkill.

Exemplo clássico de exagero

// store/usersSlice.ts
const usersSlice = createSlice({
  name: 'users',
  initialState: {
    data: [],
    loading: false,
  },
  reducers: {
    setUsers(state, action) {
      state.data = action.payload;
    },
  },
});

Tudo isso… pra armazenar dado de API. 👉 que já deveria estar no server state.

Quando Redux ainda faz sentido

regras de negócio complexas e compartilhadas
fluxos altamente previsíveis
necessidade forte de rastreabilidade

Se não for isso… 👉 provavelmente você não precisa.

Estado global leve: alternativas modernas

Hoje o jogo mudou. Você não precisa de um canhão pra matar uma formiga.

Zustand: simples e direto

Zustand é provavelmente o mais pragmático hoje.

Exemplo completo

// store/useCartStore.ts
import { create } from 'zustand';

type CartItem = {
  id: number;
  name: string;
  price: number;
};

type CartStore = {
  items: CartItem[];
  addItem: (item: CartItem) => void;
  removeItem: (id: number) => void;
};

export const useCartStore = create<CartStore>((set) => ({
  items: [],

  addItem: (item) =>
    set((state) => ({
      items: [...state.items, item],
    })),

  removeItem: (id) =>
    set((state) => ({
      items: state.items.filter(item => item.id !== id),
    })),
}));

// Cart.tsx
import { useCartStore } from './store/useCartStore';

export function Cart() {
  const { items, removeItem } = useCartStore();

  return (
    <div>
      {items.map(item => (
        <div key={item.id}>
          {item.name}
          <button onClick={() => removeItem(item.id)}>
            Remover
          </button>
        </div>
      ))}
    </div>
  );
}

Jotai: estado atômico

Jotai trabalha com “átomos” de estado.

Exemplo

// atoms/cartAtom.ts
import { atom } from 'jotai';

export const cartAtom = atom([]);

// Cart.tsx
import { useAtom } from 'jotai';
import { cartAtom } from './atoms/cartAtom';

export function Cart() {
  const [cart, setCart] = useAtom(cartAtom);

  function addItem(item) {
    setCart(prev => [...prev, item]);
  }

  return (
    <div>
      <button onClick={() => addItem({ id: 1, name: 'Item' })}>
        Adicionar
      </button>

      {cart.map(item => (
        <div key={item.id}>{item.name}</div>
      ))}
    </div>
  );
}

Signals: o futuro (talvez)

Signals estão ganhando espaço. A ideia: 👉 reatividade mais granular 👉 menos re-render

Exemplo conceitual

import { signal } from '@preact/signals-react';

const count = signal(0);

export function Counter() {
  return (
    <div>
      <p>{count.value}</p>
      <button onClick={() => count.value++}>
        Incrementar
      </button>
    </div>
  );
}

Cache e sincronização: onde tudo quebra

Esse é o verdadeiro desafio.

Problema real

Você tem:

lista de usuários
tela de edição
outra tela usando os mesmos dados

Se você não sincroniza: 👉 dados ficam inconsistentes 👉 UI mostra informação antiga

Exemplo com invalidação de cache

import { useMutation, useQueryClient } from '@tanstack/react-query';

function useUpdateUser() {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: async (user) => {
      await fetch(`/api/users/${user.id}`, {
        method: 'PUT',
        body: JSON.stringify(user),
      });
    },
    onSuccess: () => {
      queryClient.invalidateQueries(['users']);
    },
  });
}

Resultado

lista atualiza automaticamente
estado consistente
menos bugs

O padrão que funciona em escala

Se você quiser algo sólido:

Server state → React Query
Client state simples → useState / context
Global leve → Zustand
Evitar Redux sem necessidade

O erro mais comum em times

Não é escolher ferramenta errada. É misturar tudo.

fetch no componente
estado global pra tudo
duplicação de dados

👉 Resultado: impossível de debugar

Conclusão: menos ferramenta, mais estratégia

Gestão de estado não é sobre biblioteca. É sobre decisão. Se você separar bem:

o que vem do servidor
o que pertence à UI

Você já resolveu 80% do problema. O resto é ferramenta. No fim… 👉 júnior escolhe biblioteca 👉 sênior escolhe modelo mental E isso muda tudo.

Bruno Oliveira