Is Redux still the right answer for a new React 19 app in 2026?

Decision. For itenium-ui — greenfield, React 19 + Vite SPA, REST/OpenAPI backend, no legacy store — do not use Redux. Take TanStack Query for server state [31] plus a small Zustand store for the client-state residue [23]. Redux is not dying (23.6M weekly npm downloads, shipping releases [2] [8]) — but Redux’s own FAQ tells you to “not use Redux until you have problems with vanilla React” [1], and an admin UI over a REST API does not have those problems. Reach for Redux only if you hit one of the five shapes in the When Redux still wins table below.

The honest state of Redux in 2026

Redux is not abandonware and the “Redux is dead” genre is wrong. It is shrinking in share, which is a different thing.

Zustand crossed Redux Toolkit on downloads during 2024–25 and the gap has widened since [5]. The State of React 2025 flatline on RTK is the sharper signal: RTK is not losing its installed base, it is failing to win new projects [6]. RTK Query’s own 2.x/3.x roadmap remains an open maintainer-driven discussion thread rather than a shipped plan [28] ⭐ 11.2k — the project is in maintenance-plus-increments mode, not expansion.

What the maintainers themselves say

Two separate statements, routinely conflated:

• “Use RTK, not hand-rolled Redux.” — “If you are writing any Redux logic today, you should be using Redux Toolkit” [11]. This is a how, not a whether.
• “You may well not need Redux at all.” — the official FAQ is blunt: “Not all apps need Redux… It’s not designed to be the shortest or fastest way to write code. There are more concepts to learn, and more code to write. It also adds some indirection… a trade-off between short term and long term productivity.” It then quotes Dan Abramov: “don’t use Redux until you have problems with vanilla React.” [1]

Redux’s official list of when it is useful [1]: large amounts of state needed in many places; state updated frequently; complex update logic; medium/large codebase worked on by many people; you need to see how state changed over time. Score itenium-ui (an admin console + a file-management app over a REST API) against that list honestly — it hits roughly none of them. Almost all of its “state” is a cache of server data, which is not what Redux is for.

The boilerplate reality, post-RTK

RTK’s own stated purpose is to fix “store setup is too complicated”, “too many packages”, “too much boilerplate” [10]. It genuinely did: createSlice killed action-type constants, the switch statement, and manual immutable spreading (Immer does it). Nobody writing RTK in 2026 is writing 2017 Redux.

But “less boilerplate than 2017 Redux” is not “no boilerplate”. A minimal RTK setup is still: configureStore + <Provider> + typed useAppDispatch/useAppSelector hooks + one slice file per concern; add RTK Query and you also owe a createApi slice, a baseQuery, tag types, and store-middleware wiring. Zustand’s equivalent is one create() call and no provider [23]. Bundle cost tracks the ceremony: ~12 KB gzip for RTK vs ~1.2 KB for Zustand [7] — irrelevant on its own, but it is a fair proxy for how much machinery you are opting into.

For a .NET architect the framing that lands: Redux is MediatR + an event log for the browser. Every mutation is a named, serialisable command flowing through one dispatcher, with middleware as the pipeline. That is genuinely valuable — when you have the problem it solves. Applying it to “fetch a list of users and show it in a table” is CQRS on a CRUD form.

The three moats that turned out not to be moats

1. DevTools / time-travel. This was Redux’s best differentiator and it is gone. Zustand’s devtools middleware plugs straight into the same Redux DevTools Extension: “lets you use Redux DevTools Extension without Redux and enables time-travel debugging of your store” [15]. Redux DevTools ⭐ 14k (Jul 2026) is a separate project that Redux no longer has exclusive rights to [27]. You get named actions and a state timeline in Zustand for one extra middleware wrap. (Caveat: Redux’s action log is richer by construction, because in Redux everything is an action; in Zustand you only see what you chose to name.)

2. “Pure reducers are ideal for TDD.” Redux’s own testing guide undercuts this. It says: “Prefer writing integration tests with everything working together… If needed, use basic unit tests for pure functions such as particularly complex reducers or selectors. However, in many cases, these are just implementation details that are covered by integration tests instead,” and flatly, “the Redux code can be treated as an implementation detail of the app, without requiring explicit tests for the Redux code in many circumstances” [16]. The recommended Redux test is: render the component tree with a real store and mock the network — which is exactly the test you would write for a Zustand store with Testing Library. A TDD mandate is not an argument for Redux.

3. RTK Query as the data layer. The official comparison page positions RTK Query for people who already pay for a Redux store (“already use Redux”, “need Redux DevTools integration”, “integration with the broader Redux ecosystem”), and openly concedes it “deliberately does not implement a cache that would deduplicate identical items” — normalisation is out of scope [12]. RTK Query is an excellent reason to keep Redux if Redux is already there. It is a bad reason to introduce Redux — you would be adopting a store you don’t need in order to get a cache you can have standalone. TanStack Query is the same job with 2.6× the downloads [4] and no store tax.

What React 19 actually took away — and what it didn’t

Be precise here, because most blog posts are not.

So the popular “React 19 killed Redux” argument only half applies to itenium-ui. The mutation-side ergonomics (Actions, useOptimistic) are yours for free and delete the single most common reason people historically wrote thunks. The RSC half does not apply at all — which is precisely why you still need a real server-state library, and why the answer is TanStack Query rather than “React 19 handles it”. TanStack Query’s own docs make the boundary explicit: it is “a server-state library… not a replacement for local/client state management”, and after adopting it “most of your once seemingly global state really wasn’t global at all” [31]. Practitioner estimates put server-state at 60–80% of the Redux code in a typical data-driven app [26] — delete that, and what’s left rarely justifies a store.

When Redux still genuinely wins

Not nostalgia — these are real. Each row is a bar Redux must clear that lighter tools cannot.

If a future Forge frontend is an editor rather than an admin console, revisit this. Redux is the right tool for editors.

The OpenAPI codegen question — the one real point in Redux’s favour

Itenium.Forge exposes Swagger/OpenAPI, so typed-client generation is on the table, and RTK Query has a genuine first-party answer: @rtk-query/codegen-openapi generates a fully typed API slice with hooks straight from the schema [20]. That is a real advantage — and it evaporates on inspection, because the non-Redux side has the same thing:

Orval’s built-in MSW mock generation is a direct hit on a TDD mandate: generated mocks from the same schema that generates the client. That is a better TDD story than RTK’s codegen, not a worse one.

Recommended stack for itenium-ui

1. Server state → TanStack Query [24] ⭐ 50k. Caching, dedup, retries, invalidation, use()-friendly suspense. This eats 60–80% of what people used Redux for [26].
2. Typed client → Orval or Hey API against the Forge OpenAPI spec [21] [22]. Orval if you want the generated MSW mocks for Jest/Testing Library.
3. Client state → Zustand ⭐ 59k [23], with the devtools middleware on from day one so you keep the action timeline and time-travel [15]. Expect this store to be small — theme, sidebar, selection, upload queue. If it stays that small, useState + context may even be enough.
4. Mutations → React 19 Actions + useOptimistic, not thunks [13] [14]. Pair with react-hook-form (as the shadcn-admin sibling does) and TanStack Query’s useMutation for invalidation.
5. Escape hatch: if the client store ever grows past ~a dozen interdependent slices with complex update rules, Zustand ships a redux-style middleware — you can adopt reducer/action discipline without adopting Redux. And Reselect works standalone if derived state gets heavy [18].

Community sentiment matches: “Redux isn’t dead, but in 2026, maybe we shouldn’t be using it without thinking, like opening jQuery to create a dropdown” [29].

The one caveat worth naming

Choosing against Redux means choosing a stack whose pieces are maintained by small teams too — Zustand and Jotai are both pmndrs, TanStack is Tanner Linsley’s org. You are not trading a bus-factor-of-one [9] for a bus-factor-of-many; you are trading it for a different small team with steeper adoption momentum. What you do buy is exit cost: a Zustand store is a plain hook and a few hundred lines. Ripping out Redux is a project. Ripping out Zustand is an afternoon. For a greenfield pick with genuine uncertainty about where the app lands, that asymmetry is the deciding argument.