React-Redux Roadmap: version 8.x, React 18, and TypeScript

I want to start sketching out the likely direction for React-Redux version 8. (I’ll refer to it as “v8” for shorthand - please note that I’m referring to our next major version, and not the JS engine 😃 )

Unlike our giant v7 effort captured in the v7 roadmap issue and the many v7.1 hooks issues, I expect that v8 will be simpler in terms of conceptual changes and design work. On the other hand, it’s also possible it might end up involving a significant amount of total effort.

For now, I just want to list what I think are the big-ticket items for a v8 major version.

Planned Major Changes

React 18 and Concurrent Compatibility

We have numerous prior threads discussing how React-Redux will work with React’s eventual Concurrent features. A lot of that has involved speculation and hypotheticals because of the long drawn-out development process for Suspense and Concurrent React. Now that React 18 alpha has been announced, it looks like A) the new behaviors are finally about to become reality, B) we have some more concrete ideas of what APIs exist and what the potential issues are, and C) the React team is trying to share info and prepare the ecosystem over in the React 18 Working Group.

While we don’t have a final concrete plan for what will happen, most likely React-Redux v8 will:

• Keep the exact same primary public APIs we have now (useSelector and connect)
• Update the internals to be built around useMutableSource as an integration layer to provide better compatibility with Concurrent rendering. (It’s also possible that we could look at context-based approaches again if React finalizes a “context selectors” API and makes that available.)

TypeScript

The three major Redux libraries have all followed different paths for TS usage and development:

• The Redux core is plain JS, with TS typedefs maintained in the repo
• React-Redux is plain JS, but with the typedefs maintained by the community in DefinitelyTyped
• Redux Toolkit is entirely written in TS

We do have a still-unreleased conversion of the Redux core lib sitting in its master branch. It’s been there for a while, and tbh we still don’t have specific plans to release that any time soon. There’s a bunch of factors around ecosystem compat and churn we’d need to consider first.

The React-Redux typedefs are incredibly complex, and I’d like to give kudos to everyone who’s built them up over the years. In particular, the handling of the various connect overloads is really complicated, which isn’t surprising when you consider the number of optional parameters and overloads it has.

But, if we’re going to be doing a major version, we ought to go ahead and rewrite the React-Redux source in TS, so that we can stop having to deal with separate typedefs.

Code Cleanup

The primary breaking change here will be the planned removal of the connectAdvanced API. It was part of the original v5 implementation, largely because the author of v5 wanted more flexibility than the existing connect API offered. A few other folks used it, but ultimately it saw very little use. In addition, our hooks API has effectively addressed those use cases.

We announced it would be deprecated a couple years ago. While we never formally slapped a // @deprecated tag on it, the description’s been there for a while. Consolidating the logic for connect and connectAdvanced will probably simplify things a bit.

We’ll see what else we can clean up in the process.

Other Changes?

I don’t immediately have anything else specific intended for v8 off the top of my head. I still like the idea of some Proxy-based selector handling ala #1653 , but it seems like that should be addressed more as a general Redux usage thing than building something directly into React-Redux

Timeline

No idea! 😃

Okay, so we’re sorta inching towards that now. I’m participating in the React 18 Working Group discussions, and they’ve emphasized that they want to help the ecosystem improve compat leading up to a live React 18 release. So, this is coming, but no hard dates.

Meanwhile, I’ve requested help from the community in migrating the current codebase to TS, as a foundation before we do any attempted compat changes - that way we’re not trying to tackle both at once.

So, I could at least foresee that we might be trying to pull something together fully near the end of 2021, maybe early into next year, but this is also largely dependent on the React team’s own timeline for React 18.

Requests for Help

As always, we welcome anyone who’d like to help contribute! The biggest immediate needs are:

React 18 alpha compat testing

We’ve already got an issue at #1732 asking people to try out React-Redux v7 with the React 18 alphas, and try to come up with actual examples of bugs and places where things break. That would give us things to try testing against as we work on Concurrent compat.

Related to this, Daishi Kato has put together a testbed that checks whether libraries potentially get along with Concurrent rendering, at https://github.com/dai-shi/will-this-react-global-state-work-in-concurrent-rendering . That will likely be a useful starting point.

If folks really want to dig in, I know that there’s been a couple experiments with trying to modify React-Redux to use useMutableSource already, and it would be interesting to see some PRs to get an idea of how much code churn that involves.

We’re also going to want to freshen up the https://github.com/reduxjs/react-redux-benchmarks repo so that we can do perf benchmarks on new versions.

Finally, both the benchmarks repo and our tests will need updating to actually use React 18’s new APIs, and we’ll need new test scenarios that leverage those to have meaningful behavior checks.

TypeScript Conversion

Per #1737 , we’ve got the first couple steps going on porting the codebase to TS (just some first build tweaks so far). We’d love to have more folks get involved here, especially since we maintainers don’t have time to seriously work on that part right now.

[markerikson]

Talked about this with the React team today, and they advised to go ahead and use the shim by default. So, in the next couple days I’m going to ship a new React-Redux v8 beta that flips the current setup:

• The primary entry point will depend on the useSyncExternalStore shim
• There will be some alternate entry point that directly imports useSyncExternalStore from React (entry point name TBD, suggestions welcome!)

This has a few implications:

• React-Redux v8 will now work with React 16.8 and higher by default, rather than hard-requiring React 18
• Users will be able to upgrade to React-Redux v8 immediately, even if they have no plans to update to React 18 any time soon
• v8 will also continue to work with React Native apps even though the “new RN architecture” and React 18 support isn’t out yet
• The shim will add about 1K min to the bundle size. However, useSelector itself did get smaller because we ripped out its own subscription logic. (I’ll try to do a comparison and see how much the final size changes.) We’ll offer a suggestion that people can alias the “direct import” entry point instead if they want to strip out the extra size in their own apps.

[markerikson]

I’d originally planned that v8 would have a hard dependency on React 18, even though the useSyncExternalStore shim works all the way back to React 16.9, and as of https://github.com/reduxjs/react-redux/releases/tag/v8.0.0-alpha.1 I dropped use of the shim. This is partly to save the size of the shim itself (which looks to be about 750b), and also because it seemed like it would simplify things overall.

Earlier today someone suggested that we could try adding a 'react-redux/compat' entry point that would use the shim. I think this is doable. We’re already doing basically the same thing with 'react-redux/alternate-renderers', which changes what batching technique is used to support non-ReactDOM/RN renderers. We could do the same with uSES as well.

This would also have the benefit of keeping React-Redux potentially working with Preact, since I don’t think they’ve tried to implement uSES at all.