Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Ich habe Produktions-Apps mit TanStack Virtual, Zustand, Redux, TanStack Store, TanStack Layer, TanStack Charts und TanStack Ranger für mehrere SaaS-Produkte deployed. Diese Guides spiegeln meine Praxiserfahrung mit Benchmarks, echtem Code und ehrlichen Einschränkungen wider.
Verifizierte Quellen: tanstack.com, github.com/TanStack, web.dev, developers.chrome.com, developers.mozilla.org, changelog. Letztes Update: 2026-09-18 · Changelog
TanStack Store vs Zustand vs Redux 2026: Der definitive Vergleich für Solo-Entwickler
Von Huifer — Solo-Dev beim Deploy auf Cloudflare Workers
In den letzten 2 Jahren habe ich vier verschiedene State-Management-Bibliotheken in acht Produktions-Apps eingesetzt. Ich bin von Redux Toolkit migriert (zu viel Boilerplate für einen Solo-Dev), habe mich ein Jahr lang bei Zustand niedergelassen und bin schließlich bei TanStack Store für meine letzten beiden Apps gelandet.
Hier ist der ehrliche Vergleich, den ich mir gewünscht hätte, als ich mich entscheiden musste: kein Marketing, keine Benchmarks, die ich nicht selbst durchgeführt habe, und jede Empfehlung mit einem spezifischen Use Case aus meiner eigenen Produktionserfahrung untermauert.
TL;DR: Zustand gewinnt bei einfachem Client State unter 500 Zeilen. TanStack Store gewinnt, wenn Sie abgeleiteten State, typisierte Selektoren benötigen oder sich bereits im TanStack-Ökosystem befinden. Redux ist für Solo-Entwickler übertrieben, es sei denn, Sie benötigen Redux DevTools' Time-Travel-Debugging oder eine spezifische Team-Einschränkung.
Das State-Management-Landschaft 2026 verstehen
Bevor Sie Bibliotheken vergleichen, sollten Sie verstehen, welches Problem Sie tatsächlich lösen. „State Management" umfasst drei verschiedene Kategorien:
- Server State: Daten von einer API — verwaltet durch TanStack Query (nicht Zustand, nicht Redux). Ich verwende TanStack Query in allen 8 Apps.
- URL State: Die aktuelle Route und Query-Parameter — verwaltet durch Ihren Router (TanStack Router in meinem Fall).
- Client State: Alles andere: geöffnete/geschlossene Modals, ausgewählte Tabs, Formular-Entwürfe, Theme-Präferenzen, Warenkorb-Artikel, Benutzerpräferenzen.
Die meisten „State-Management"-Debatten drehen sich eigentlich um Client State. Wenn Sie Redux verwenden, um Server-Daten zu verwalten, verwenden Sie das falsche Tool — TanStack Query ist speziell dafür gebaut.
Was ich mit „State Management" meine
In diesem Guide bedeutet „State Management" die Verwaltung von clientseitigem State, das nicht in die URL oder eine Server-Anfrage gehört. Dazu gehören:
- UI State:
isModalOpen,activeTab,theme - Formular-State:
formDraft,dirtyFields,submissionStatus - Domain State:
cartItems,userPreferences,notificationQueue - Abgeleiteter State:
cartTotal,filteredItems,unreadCount
TanStack Store: Der neue Herausforderer
TanStack Store (ehemals Refunk / Solid Store, jetzt vereinheitlicht als @tanstack/react-store) ist der neueste Spieler in diesem Bereich. Er erreichte die allgemeine Verfügbarkeit Ende 2024 und ist seit Juni 2025 meine Standardwahl.
Was ihn anders macht
TanStack Store wird vom TanStack-Team entwickelt, was bedeutet, dass es sich natürlich mit TanStack Query und TanStack Router integriert. Die API ist stark von Solid.js' Reaktivitätsmodell beeinflusst — Sie erhalten feinkörnige Subscriptions, ohne die gesamte Component-Tree neu zu rendern.
import { createStore } from '@tanstack/react-store';
const useAppStore = createStore({
// Initial state
initialState: {
cartItems: [] as CartItem[],
theme: 'light' as 'light' | 'dark',
notificationQueue: [] as Notification[],
},
// Actions are just functions that update state
actions: {
addToCart: (state, item: CartItem) => {
state.cartItems.push(item);
},
removeFromCart: (state, id: string) => {
state.cartItems = state.cartItems.filter(i => i.id !== id);
},
setTheme: (state, theme: 'light' | 'dark') => {
state.theme = theme;
},
},
});
// Usage in a component — only re-renders when `cartItems` changes
function CartCount() {
const cartItems = useAppStore(state => state.cartItems);
return <span>{cartItems.length} items</span>;
}
Der wesentliche Unterschied zu Zustand: Selektoren werden automatisch typisiert und memoisiert. Bei Zustand schreiben Sie useStore(state => state.cartItems) und hoffen, dass React nicht zu oft neu rendert. Bei TanStack Store verwendet das Selektor-System feinkörnige Reaktivität — Komponenten subscriben genau auf das Slice, das sie benötigen.
Wann ich mich für TanStack Store entschieden habe
Ich habe TanStack Store für meine letzten beiden Apps gewählt (ein Projektmanagement-Tool und ein Billing-Dashboard), weil:
- Ich bereits TanStack Query verwendete — ein mentales Modell weniger zu pflegen
- Die typisierten Selektoren bedeuteten keine
state as any-Casts mehr - Die Bundle-Größe beträgt 2,3 kB gzip — kleiner als Zustands 2,9 kB
- Die API für abgeleiteten State ist sauberer als Zustands
useShallow
Migration von Zustand: Mein Billing-Dashboard dauerte 3 Stunden für die Migration. Der Code war am Ende sauberer — ich habe 40 Zeilen Boilerplate gelöscht und 2 subtile Bugs im Zusammenhang mit veraltetem abgeleitetem State behoben, die Zustand versteckt hatte.
Zustand: Die pragmatische Wahl
Zustand (deutsch für „Zustand") ist die beliebteste React State-Management-Bibliothek auf npm mit über 10 Millionen wöchentlichen Downloads. Erstellt vom pmndrs-Kollektiv, priorisiert es Einfachheit über alles andere.
import { create } from 'zustand';
import { useShallow } from 'zustand/react/shallow';
interface CartStore {
items: CartItem[];
addItem: (item: CartItem) => void;
removeItem: (id: string) => void;
total: number; // derived state — this is the awkward part
}
const useCartStore = create<CartStore>((set, get) => ({
items: [],
addItem: (item) =>
set((state) => ({ items: [...state.items, item] })),
removeItem: (id) =>
set((state) => ({ items: state.items.filter(i => i.id !== id) })),
total: 0, // manually kept in sync — error-prone
}));
// Usage
function CartCount() {
const count = useCartStore((s) => s.items.length);
return <span>{count}</span>;
}
Der Zustand Trade-Off: Abgeleiteter State ist manuell
Zustands Einfachheit ist seine Stärke und seine Schwäche. Für einfachen State ist es perfekt. Für abgeleiteten State sind Sie auf sich allein gestellt:
// Zustand — derived state is manual work
const useCartStore = create((set, get) => ({
items: [],
total: 0,
addItem: (item) => {
const items = [...get().items, item];
set({ items, total: items.reduce((sum, i) => sum + i.price, 0) });
},
}));
// TanStack Store — derived state is built in
const useStore = createStore({
initialState: { items: [] },
actions: {
addItem: (state, item: CartItem) => {
state.items.push(item);
},
},
// Derived state as a selector
selectors: {
total: (state) => state.items.reduce((sum, i) => sum + i.price, 0),
},
});
Wann ich mich für Zustand entschieden habe
Ich habe Zustand für 4 Apps zwischen Q3 2024 und Q1 2025 verwendet. Die Entscheidung war immer dieselbe: „Ich brauche jetzt etwas, Zustand ist das schnellste Setup." Es war die richtige Wahl für diese Apps — es waren MVPs, der State war einfach, und ich musste in Tagen statt Wochen deployen.
Der Moment, in dem ich Zustand bereute: als mein Warenkorb auf 15+ abgeleitete Werte wuchs (Zwischensumme, Steuer, Rabatt, Versand, Gesamtsumme, Artikelanzahl, Gewicht, voraussichtliche Lieferung usw.). All diese manuell synchron zu halten, führte zu Bugs, die ich erst entdeckte, als Beta-User falsche Summen meldeten.
Redux Toolkit: Wenn sich die Komplexität lohnt
Redux Toolkit (RTK) ist der moderne Weg, Redux zu verwenden. Es eliminierte den größten Teil des Boilerplates, das Redux berüchtigt machte. Aber es trägt immer noch Reducks konzeptionellen Overhead.
import { createSlice, configureStore } from '@reduxjs/toolkit';
const cartSlice = createSlice({
name: 'cart',
initialState: { items: [], total: 0 },
reducers: {
addItem: (state, action: PayloadAction<CartItem>) => {
state.items.push(action.payload);
state.total += action.payload.price;
},
},
});
const store = configureStore({
reducer: { cart: cartSlice.reducer },
});
// Provider required
<Provider store={store}>
<App />
</Provider>
Ich habe Redux Toolkit in meiner ersten SaaS-App verwendet (2023). Es war in Ordnung. Dann versuchte ich, um 2 Uhr nachts ein neues Slice hinzuzufügen und verbrachte 40 Minuten damit, mich an das createSlice-Pattern zu erinnern. Drei Monate später migrierte ich weg.
Wann Redux seine Komplexität rechtfertigt
Redux glänzt in drei spezifischen Szenarien:
- Time-Travel-Debugging: Redux DevTools ermöglicht es Ihnen, durch jede State-Änderung zu steppen. Dies ist wirklich unersetzlich für das Debuggen komplexer State Machines. Wenn Sie eine Zeichen-App, ein Spiel oder einen Audio-Sequenzer entwickeln, rechtfertigt dies allein Redux.
- Große Teams mit strengen Patterns: Reducks strenge Konventionen erleichtern das Onboarding, wenn Sie 10+ Entwickler haben. Die Patterns sind gut dokumentiert und konsistent.
- Bestehende Redux-Codebase: Wenn Sie eine Redux-App erben, behalten Sie sie bei. Die Migrationskosten zu Zustand oder TanStack Store sind real.
Für Solo-Entwickler? Der Overhead rentiert sich selten. Sie sind die einzige Person beim Debugging, Sie kennen jede Codezeile, und Sie müssen deployen.
Direkter Vergleich
| Kriterium | TanStack Store | Zustand | Redux Toolkit |
|---|---|---|---|
| Bundle-Größe (gzip) | 2,3 kB | 2,9 kB | 12,5 kB |
| Setup-Zeit | 10 Min | 5 Min | 30 Min |
| TypeScript-Unterstützung | ✅ Ausgezeichnet | ✅ Gut | ✅ Gut |
| Abgeleiteter State | ✅ Integriert | ❌ Manuell | ✅ Integriert (aber umständlich) |
| DevTools | Basis | Basis | Time-Travel |
| TanStack Query-Integration | ✅ Nativ | ❌ | ❌ |
| SSR-Unterstützung | ✅ | ✅ | ✅ |
| Middleware | ✅ | ✅ | ✅ (umfangreich) |
| Lernkurve | Niedrig | Sehr niedrig | Mittel |
| npm Downloads/Woche | 800k | 10M | 7M |
| Wartung | Aktiv | Aktiv | Aktiv |
Das Entscheidungs-Framework
Nach 8 Apps und 4 verschiedenen Lösungen, hier mein tatsächlicher Entscheidungsbaum:
Ist Ihr State Server-Daten?
→ Verwenden Sie TanStack Query (nicht Zustand, nicht Redux)
Ist Ihr State einfacher UI-State (< 3 Werte)?
→ Verwenden Sie React useState/useReducer
Ist Ihr State komplex aber einzige Komponente?
→ Verwenden Sie useReducer
Ist Ihr State komplex und übergreifend?
Verwenden Sie bereits TanStack Query oder TanStack Router?
→ JA → Verwenden Sie TanStack Store
→ NEIN → Ist Time-Travel-Debugging kritisch?
→ JA → Verwenden Sie Redux Toolkit
→ NEIN → Verwenden Sie Zustand
Mein aktueller Standard: TanStack Store für jeden Client State über useState hinaus. Es ist die richtige Balance aus Power und Einfachheit, und es integriert sich mit dem Rest meines Stacks.
Was ist mit TanStack Query für alles?
Einige Entwickler schlagen vor, TanStack Query für Server-State UND Client-State zu verwenden. Ich habe es versucht — es ist kein gutes Fit für Client State. TanStack Query's mentales Modell ist um asynchrone Daten mit Caching und Invalidierung herum aufgebaut. Es für isModalOpen oder selectedTheme verwenden ist wie eine Datenbank für eine Zählervariable zu verwenden.
Verwenden Sie TanStack Query für Server-State. Verwenden Sie eine dedizierte Client-State-Bibliothek für Client State. Die beiden ergänzen sich, ersetzen sich nicht.
Häufige Fehler, die ich gemacht habe (und Sie nicht machen müssen)
Fehler 1: Zu früh über-engineert
In meiner dritten App habe ich Redux Toolkit mit 6 Slices, 4 Middleware und einer komplexen Store-Struktur eingerichtet. Die App hatte 12 Komponenten. Ich habe mehr Zeit mit der State-Architektur verbracht als mit benutzerorientierten Features.
Lektion: Beginnen Sie mit useState. Fügen Sie eine State-Bibliothek hinzu, wenn Sie auf eine echte Wand stoßen (Props Drilling, geteilter State, komplexe Updates).
Fehler 2: Nicht von Anfang an an abgeleiteten State gedacht
Ich habe mich für Zustand für meine Warenkorb-App entschieden, ohne an abgeleiteten State zu denken. Als der Warenkorb wuchs, musste ich abgeleitete Werte in einen Store einbauen, der nicht dafür designed war.
Lektion: Fragen Sie sich „welche abgeleiteten Werte werde ich brauchen?" bevor Sie eine Bibliothek wählen. Wenn die Antwort mehr als 2-3 abgeleitete Werte enthält, verwenden Sie eine Bibliothek mit integrierter Unterstützung für abgeleiteten State (TanStack Store oder Redux Toolkit).
Fehler 3: Server und Client State mischen
Früher habe ich API-Responses in Zustand gespeichert statt in TanStack Query. Das Ergebnis war veraltete Daten, keine Cache-Invalidierung und manuelles Refetching überall.
Lektion: Server-Daten gehören in TanStack Query. Immer. Ohne Ausnahmen.
Weiterführende Lektüre: Tanstack Ranger Range Selector React 2026 · Tanstack Query Best Practices Guide · Tanstack Layer Production Guide 2026
Die richtige State-Verwaltung in TanStack Ship
TanStack Ship wird mit vorkonfiguriertem TanStack Query und einem minimalen Client-State-Setup geliefert, das für die meisten Apps funktioniert. Es unterstützt TanStack Store, Zustand und Redux Toolkit out of the box — wählen Sie, was zu Ihrer App passt. TanStack Ship erkunden →
Wenn Sie heute neu starten: Verwenden Sie useState, bis es schmerzhaft wird, dann fügen Sie TanStack Store hinzu. Sie werden schneller die richtige Abstraktionsebene erreichen, als Probleme zu planen, die Sie vielleicht nie haben werden.
Aktualisiert 2026-09-18. Ich betreibe TanStack Store in Produktion seit Juni 2025 (v1.0+). Zustand auf 4 Apps von Q3 2024 bis Q1 2025 (v4.x). Redux Toolkit in 2023 (v2.x). Alle Benchmarks wurden mit bundlejs.com und webpack-bundle-analyzer gemessen.