Zustand vs Redux Toolkit

Contexto

Reducers, actions com type string, um Provider obrigatório: o boilerplate clássico do Redux moldou boa parte do ecossistema de gerenciamento de estado em React — inclusive as duas respostas comparadas aqui, cada uma reagindo a esse boilerplate à sua maneira. Zustand é a resposta minimalista — uma função create() que devolve um hook, sem Provider obrigatório, sem actions/reducers separados. RTK é a resposta oficial do time do Redux ao próprio boilerplate do Redux clássico: mantém a arquitetura de reducers puros, actions e um único store imutável, mas embrulha tudo em createSlice(), gera as actions automaticamente e usa Immer por baixo dos panos para permitir "mutação" direta dentro do reducer.

A comparação não é Zustand vs Redux clássico — seria injusta, RTK já resolveu boa parte do boilerplate que tornou o Redux famoso por sua verbosidade. A pergunta real é se vale a pena manter o modelo de reducers/actions/store único do Redux (agora com muito menos cerimônia) ou trocar por uma store direta como a do Zustand.

Quando escolher Zustand

Zustand funciona bem quando a equipe quer o caminho mais curto entre "preciso de estado compartilhado" e "estado compartilhado funcionando". Não há reducers, não há actions com type string, não há Provider: a store é um hook comum.

import { create } from "zustand";

const useCart = create<{ items: string[]; add: (id: string) => void }>((set) => ({
  items: [],
  add: (id) => set((s) => ({ items: [...s.items, id] })),
}));

Não existe um passo de "despachar uma action que um reducer intercepta" — a função add já modifica o estado diretamente via set. Isso reduz a quantidade de arquivos e de indireção para times pequenos ou para partes da aplicação onde o estado é simples. A contrapartida é que Zustand não impõe nenhuma estrutura: conforme o número de stores cresce, cabe ao time decidir convenções de organização, e não há um equivalente pronto ao RTK Query para cache de dados de servidor — isso fica por conta de outra biblioteca (como TanStack Query).

Quando escolher Redux Toolkit

RTK compensa quando o projeto se beneficia da disciplina que o Redux sempre impôs — reducers puros, um único fluxo de atualização, e um histórico de actions rastreável — mas sem pagar o preço de escrever switch de actions manualmente. createSlice() gera as actions e o reducer a partir de um objeto de funções que parecem mutar o estado diretamente, graças ao Immer embutido:

import { createSlice, configureStore } from "@reduxjs/toolkit";

const cart = createSlice({
  name: "cart",
  initialState: { items: [] as string[] },
  reducers: {
    add: (state, action: { payload: string }) => {
      state.items.push(action.payload); // "mutação" segura via Immer
    },
  },
});

export const store = configureStore({ reducer: { cart: cart.reducer } });

Esse state.items.push(...) não muta o estado de verdade — o Immer intercepta e produz um novo objeto imutável por trás. O ganho real de RTK sobre Zustand aparece em dois pontos: integração nativa com Redux DevTools (time-travel debugging, inspeção de todo o histórico de actions) e RTK Query, um data layer completo para chamadas de API com cache, invalidação automática e hooks gerados — algo que Zustand não tenta resolver. O custo é estrutural: RTK ainda pede um configureStore, um Provider envolvendo a árvore, e a convenção de organizar o estado em slices por domínio, o que é mais cerimônia do que a store única do Zustand.

Veredito

Nenhum dos dois é a escolha exótica aqui — Zustand e Redux Toolkit são, cada um a seu modo, a opção madura dentro da filosofia que representam; o que muda é quanta infraestrutura o projeto já precisa em torno do estado. Se o time quer o mínimo de peças entre "estado" e "componente", sem depender de um ecossistema de data fetching embutido, Zustand entrega isso com menos conceitos novos para aprender. Se o projeto já é (ou vai crescer para ser) um Redux — com necessidade de DevTools avançadas, rastreabilidade de actions e um data layer de servidor integrado — Redux Toolkit é hoje a forma recomendada de usar Redux, sem o boilerplate do modelo clássico.

Vale perguntar não só o que o projeto precisa hoje, mas o que ele provavelmente vai precisar daqui a alguns meses: se um data layer de servidor para chamadas de API já está no radar, adotar RTK Query desde o início poupa uma migração de ferramenta depois. Se esse cenário nunca chega, Zustand evita pagar antecipadamente por uma complexidade que o projeto talvez nunca precise carregar.