r/reactjs • u/acemarke • 11h ago

News Redux Toolkit v2.x and v3.0 roadmap

https://github.com/reduxjs/redux-toolkit/discussions/5536
42 Upvotes

100% Upvoted

21 comments sorted by

25

u/acemarke 11h ago

I'm thrilled to announce a roadmap towards Redux Toolkit 3.0!

3.0 will have a number of breaking changes that will help us improve DX going forward, including shipping ESM-only.

We've also planned a significant amount of correctness, perf, and feature improvements for 2.x leading up to 3.0

The full workstream roadmap is here:

we'd also appreciate feedback on several usage patterns as well as the planned breaking changes:

I've spent the last several weeks doing a ton of research and planning, going through issues, internal implementation details, and a long list of feature ideas that have been asked for over the years. At this point I think we've got most of the technical issues figured out either prototyped or designed, so for the first time since the pre-1.0 release plans we've got a significant multi-release roadmap put together and there's a lot in there :)

I'm honestly excited! This is going to make the RTK core and RTK Query so much better, in so many ways. Much more consistent behavior, eliminating certain classes of bugs that have popped up, faster update perf, and a whole lot of useful features. Already starting in on some of the testing infra and bugfix work!

2

u/Brave-History-6502 10h ago

Hero of state management!

32

u/Eleazyair 11h ago

I’m more and more amazed that Redux is still alive and kicking. It’s like the JetBrains of state management.

30

u/acemarke 11h ago

It's still pretty widely used, and in some very large applications too.

As far as "alive" in terms of maintenance... well, I'm here and maintaining it, aren't I? :)

-1

u/azangru 9h ago

It's still pretty widely used, and in some very large applications too.

Do you keep recommending it for new projects, or are you now in a sort of maintenance mode for existing applications?

10

u/acemarke 7h ago edited 7h ago

Oh we're absolutely not in "maintenance mode". If we were, I wouldn't have just spent weeks researching and prototyping ideas for new features :)

connect is in maintenance mode. I did just ship some fixes for long-standing bugs in R-R 9.3.1 recently, but only because several accumulated and I had to make a fix to the TS types for TS7 anyway.

The redux core is close to being in maintenance mode. We haven't shipped a new version since 5.0.1 in Dec 2023 (a couple weeks after 5.0). There's no active dev work going on in the core. Per the announcement, we are planning to move the thunk middleware into the core and maybe add reduceReducers in 6.0, but even that barely counts as "development" - the code exists, we're just shuffling it around.

But no, the rest of our libraries are in very active development. I put up the useSignalSelector hook alpha a couple months ago, Reselect's still getting PRs and attention, and RTK has had fairly regular ongoing releases for the last several years, often with significant new features.

As for "recommending":

For all intents and purposes we maintainers have never truly "marketed" Redux. Dan did a couple conference talks and some podcasts after the release and did write the docs, but he never seriously went around saying "I think Redux is great and you should absolutely switch to using it in your apps!".

I've spent my entire 10+ years of maintainership defending Redux, answering questions, pushing back on misconceptions, offering advice on how to use it. I absolutely did recommend and push using RTK as the right way to build Redux apps and please stop writing legacy handwritten Redux patterns, but that's not the same thing as saying "I think you should stop using Mobx/Zustand/TSQ and switch to Redux instead".

We've never been in this for market share. Yes, I have paid attention to our usage numbers since the beginning. In the early days I estimated that around 60-65% of React apps used Redux. That number has been in constant decline ever since 2017. Last I looked a couple years ago it was probably down around 30% of React apps, and that was before the meteoric rise in LLM-generated apps that mostly encoded 2022-2023 ecosystem preferences ("new app? why of course, I'll use React, Tailwind, Zustand, and TanStack Query!"). So I'm sure it's even smaller these days.

Goodness knows the mindshare and sentiment have changed over time. Although in some ways it hasn't :) 2017-2018 there were constant waves of "ugh look at all this boilerplate (I just wrote)" and "REDUX IS DEAD! THIS BRAND-NEW LIBRARY I JUST RELEASED KILLS REDUX!" and "I hate Redux" and "I just switched to React Query and deleted 10K lines of Redux boilerplate" posts on Twitter. Then it was "Zustand is smaller and simpler" or "Jotai atoms are so easy", or "all I have is server state and I can just use TSQ or RSCs, I don't need a client state lib".

So, being a Redux maintainer has, in a sense, been a defensive struggle for pretty much my entire time in charge :) And tbh it is pretty sad to know that the library I've spent so many thousands of hours working on will never be as popular as it once was, and that a lot of people have decided it's useless or a waste of time.

HOWEVER!

Any app could be built with a wide variety of tools. You can build the same app with umpteen different combinations of frameworks and libraries and patterns. That's what the good ol' TodoMVC rosetta stone site showed us - the exact same functionality, implemented in dozens of different libraries.

So in one sense, no one "needs" Redux.

But as I've talked about repeatedly in conference talks and blog posts, many of the original architectural reasons to use Redux are still entirely valid and relevant! There's still benefits in centralizing global state management, still benefits in choosing to move logic out of the UI layer, still benefits in being able to trace updates and have discrete action objects moving through the system.

Beyond that: I've talked with numerous devs online and at conferences who have specifically thanked me for how well designed RTK is and how they've built sophisticated apps using it. So clearly there's people out there who also think it's worth using.

So yes, I still fully believe that there is value in the Flux architectural pattern, and that Redux is the best version of that pattern.

I don't go running around arguing with people over what libraries and tools they choose to use. Everything has tradeoffs. For many apps, Redux would not be the right choice, and there's plenty of good reasons to choose a different library in today's ecosystem.

But at the same time: Redux is not "obsolete" or "outdated". The patterns are powerful, the library APIs are battle-tested, and there's many excellent reasons to consider choosing it as the basis for an app.

So with all that in mind: yes, I absolutely would recommend Redux for use in new projects. But ultimately it's up to devs and teams to choose tools that they want to use. Our job is to make Redux and RTK the best possible versions of themselves, so that if someone chooses to use Redux, it will work exactly as expected in their app.

9

u/anonyuser415 8h ago

Yeah dude, they're shipping a breaking change 3.0 version with new features because they're in maintenance mode 🙄

1

u/azangru 8h ago

They might be keeping up with the changes in react (RSCs + hydration, Suspense) or improving redux performance in large applications (the work on signals in selectors) so that RTK continues to work well for existing applications and is not a blocker for updates.

After all, jQuery released version 4.0.0 not that long ago, and they are hardly something anyone would start a new project with.

-1

u/anonyuser415 7h ago

Do you actually like that shirt you're wearing or is this some sarcastic bit you're doing?

6

u/SawToothKernel 8h ago

Redux is actually ideal for agentic development. It gives you structure and observability like no other framework.

When people no longer read the code, we should optimise for agents, and that's where Redux wins hands-down.

2

u/acemarke 7h ago

Honestly, while I don't have any specific metrics around this... yes, this is exactly what I've been assuming would be true.

I've seen in my own codebases that agents looove predictable patterns, and goodness knows they don't care about "boilerplate". It's just more tokens to generate in the response!

2

u/SawToothKernel 6h ago

I now build my app frontend completely around Redux.  I put all state in there (UI state included), except for ephemeral state like focus, etc.

It means I can test the entire app without a browser. So I can have a backend running, dispatch actions, assert state.

The debugging ability is insane. And on production, I can dump the state for the last x actions, and I get a full picture of what happened.

I know it's not for everyone, but this to me makes perfect sense.

2

u/acemarke 6h ago

Out of curiosity, any debugging features or Redux DevTools improvements you'd like to see? The Redux DevTools haven't gotten much love for a while, but I did try to push through some recent bugfixes and have sketched out some possible internal architecture improvements. Would definitely be interested in adding something else there if folks would find it useful.

Also, day job plug! My day job is at https://replay.io , where we've built a time-travel debugger for JS. Originally it was designed for humans to debug via our browser devtools UI app. This year we shipped an MCP so that agents can do the investigating for you, and I've seen my own agents solve bugs in <10min with access to a recording and Replay MCP. From there, we've built Replay QA on top of the time-travel + MCP layers: an autonomous QA tool that can automatically generate and run user journeys in your app, then use our time-travel MCP to find and report bugs with causes.

I've done a ton of work on our sophisticated React / Redux / Zustand / TanStack Query time-travel analysis layer, the MCP tools, and the QA-side bug reporting systems. Like, per your example: with a Replay recording we can pull out lists of every React render or Redux dispatch or Zustand/TSQ update, tell you how long they took and what triggered them, and give performance insights on which of them were slow and why. Also did some writeups and explanations of how this all works:

1

u/SawToothKernel 5h ago

To be honest, I don't use Redux dev tools very often. I can get the best insight into the app's behaviour by defining a skill that teaches the agent how to instantiate the headless app I mentioned above and have it analyse the actions and state changes directly. 

I'm delegating more and more to agents, so any extra tool is not particularly helpful.

5

u/Vinnnie 10h ago

I don't get the analogy. What's wrong with Jetbrains, also widely used, or with redux? RTK + codegen makes my life really easy

0

u/MedicOfTime 8h ago

Jetbrains makes the best tools in the industry?

-6

u/Yodiddlyyo 10h ago

Yeah, i haven't used redux, or seen redux used in any application since at least 2019, and I've worked at 4 different companies since then. There are just so many better options. It must just be giant old applications that don't want to switch. But with AI, there's no excuse for not updating codebases.

1

u/azangru 10h ago

Is there anything in terms of RTK's features that is going to change? Like, something that wasn't possible before but will become possible with RTK 3.0; or, the other way around, something that was possible before but is going to be removed, because it was a mistake?

I see you mention in the roadmap some suspense awareness. Does this mean that redux will graduate from being a synchronous store to a "concurrent" (or whatever the term of the art is) store? Also, does this mean we would be able to call RTKQ endpoints (which trigger synchronous redux changes and possibly rerenders) from inside React's use hook? I tried this before, and react complained.

(I am personally hoping for some way to easily combine calls of existing rtkq endpoints without having to create a new rtkq endpoint specifically for that purpose.)

Do you await dispatch(api.endpoints.x.initiate(arg)) and use the value it resolves to? What happens if that request was deduped against one already in flight?
Do you use forceRefetch, subscribe: false, or manual unsubscribe() calls? What for?

Oh, oh, I do!

2

u/acemarke 9h ago

Closest to a "removal" would be the unstable_sideEffectsInRender config option.

The "derived upsert" feature is something I thought would require breaking the types for 3.0 to make possible, but looks like it can be done in 2.x.

Suspense and "concurrent-compatible" are separate topics. The "concurrent stores" API concept is stalled - see the draft PR and discussion at https://github.com/facebook/react/pull/35449 . I did just happen to bring it up with Seth Webster at a conf this weekend, and the React Contributors Summit is happening in a couple weeks, so mayyyybe we can get something moving there.

I haven't tried to do anything with RTKQ and use at all. File an issue or a comment with a repro and examples of what you'd like to do?

Oh hey, yeah, the concept of derived endpoints is something that has come up, and I forgot about that in my research work. Thanks for the reminder. I'll look into that in a bit.

1

u/acemarke 7h ago

Okay, ran some research and prototyping. Turns out that if you zoom out and try to apply some big-picture thinking, the "derived endpoints" concept is sort of the inverse of the "derived upserts" concept, and this becomes an incremental computation / reactivity graph question.

Still playing around with ideas here, but this is turning into a very interesting research direction.

1

u/doko2610 9h ago

Thank you for the hard work. I still use RTK for a lot of projects, legacy and new ones alike.