Skip to main content

Redux Toolkit / RTK Query

What is Redux Toolkit​

Redux Toolkit (RTK) is the official, opinionated toolset for modern Redux development. RTK Query is its built-in data-fetching and caching layer. It is MIT licensed, currently at version 2.x, with ~10M weekly npm downloads. RTK is Redux today — legacy patterns (manual action types, hand-written reducers, connect()) are officially deprecated.

caution

Advanced, situational option. Our default stack is Zustand + TanStack Query. Reach for RTK only when the specific advantages below are critical to your project.

When RTK / RTK Query shines​

  • Automatic tag-based cache invalidation — mutations automatically refetch affected queries via providesTags / invalidatesTags. No manual invalidateQueries calls needed.
  • Unified store — client state and server cache live in one Redux store with one DevTools instance.
  • Official OpenAPI codegen — @rtk-query/codegen-openapi generates a fully typed API slice from an OpenAPI spec.
  • Streaming / WebSocket cache updates — the onCacheEntryAdded lifecycle enables real-time cache patches without refetching.
  • Complex cross-cutting state logic — undo/redo, time-travel debugging, and middleware-driven side effects are natural fits for Redux's architecture.

Why it's not our default​

  • Higher complexity and more boilerplate — slices, store setup, Provider, typed hooks, and API definitions add up.
  • Steeper learning curve — middleware, thunks, entity adapters, and normalized cache concepts require upfront investment.
  • Larger bundle — RTK + RTK Query adds ~21 kB min+gzip vs ~14 kB for Zustand + TanStack Query combined.
  • No built-in infinite query primitive — TanStack Query's useInfiniteQuery handles paginated/infinite scroll out of the box.
  • Zustand + TanStack Query covers 95% of use cases with less ceremony and faster onboarding.

When to use​

  • The project already has an OpenAPI spec and you want fully generated, type-safe API hooks.
  • You need automatic tag-based cache invalidation across many interconnected resources.
  • Real-time WebSocket-driven cache updates are a core requirement.
  • Complex cross-cutting state logic (undo/redo, collaborative editing, command patterns) justifies a single unified store.
  • You're migrating an existing Redux codebase and want to modernize incrementally.

When NOT to use​

  • Greenfield projects with standard CRUD APIs — use Zustand + TanStack Query.
  • Simple client state needs — Zustand is lighter and faster to set up.
  • Teams unfamiliar with Redux concepts — the learning curve slows delivery without proportional benefit.
  • Apps with heavy infinite-scroll / paginated UIs — TanStack Query handles this better natively.

RTK Query vs TanStack Query​

For detailed feature-by-feature comparisons, see the official pages from both projects:

tip

If inheriting a legacy Redux codebase, migrating to RTK is strongly recommended over staying on manual Redux patterns. See why legacy Redux is discouraged.

Resources​