Future planning: RTK 2.0?

[markerikson]

UPDATE 2023-12-05 We're live! https://github.com/reduxjs/redux-toolkit/releases/tag/v2.0.0

## UPDATE 2022-10-15: THIS IS NOW MUCH LESS HYPOTHETICAL AND HOPEFULLY HAPPENING SOON-ER THAN LATER!

## THIS IS HYPOTHETICAL AND WE ARE NOT GOING TO BE RELEASING RTK 2.0 ANY TIME SOON PLEASE DON'T PANIC

Okay, with that disclaimer out of the way: what would an RTK 2.0 look like? What "breaking" changes would we want? When should we actually consider doing that?

The most obvious ones I can think of would involve changing back-compat publishing stuff. In particular, dropping the default enableES5() plugin call for Immer, and dropping publishing IE11-compatible syntax from our published build artifacts.

Related Twitter thread:

• https://twitter.com/acemarke/status/1376381894279987209
• https://twitter.com/acemarke/status/1376385867699326977
• https://twitter.com/acemarke/status/1376386257434071041

I suppose the hypothetical Redux 5.0 with potentially altered TS types might fit in there, but I truly have no idea if we're ever going to get around to releasing that.

Right now we're planning to put RTK Query out in RTK 1.6. It's additive, so it's not breaking.

The ESBuild PR in #957 is problematic for IE11 compat out of the box, but it's likely we could down-compile the ESBuild output to resolve that.

Any further ideas?

[crutchcorn]

Just curious; what would be the blocker for Redux 5.0? I apologize, I missed that discussion and thought it would be useful to include it as something to track in this discussion

[markerikson]

So if you look over in https://github.com/reduxjs/redux on master, the Redux core was actually converted to TS almost two years ago.

And it's just sat there ever since, unreleased.

Sorta related to that, there's some changes to the redux-thunk typings that have been sitting around unreleased for a very long time.

There's a couple different potential things here:

• @timdorr was overseeing both of those changes, and he's been extremely busy with his day job for a while now
• A major release of any lib is always a big deal, and there's a lot of Redux-related packages that might need to get updated to say they work with 5.x
• For TS specifically, there's almost definitely some breaking changes in the Redux core TS types, either because something got "fixed" during the TS conversion, or something accidentally got broken

Meanwhile, Redux 4.x works just fine, both code and types.

So, basically it's about no one prioritizing the effort, combined with concern about breaking the ecosystem (and potentially for not much real benefit).

I am planning to put out a new Redux 4.1.0 release in the near-ish future that would extract our error messages to "error codes" to shave down prod size, tweak a couple error messages, and remove the remaining deps like `symbol-observable. I want to get that into RTK 1.6 too.

But at this point, we have no real plans to actually get Redux 5.0 out the door.

[phryneas]

So my thought is that RTK-Query would actually be a "big enough addition" to actually "sell" a 2.0, compared to a tooling change.

As for the bigger changes I'd include:

• RTK-Query
• entityAdapter indices
• add ESM "modern" build targeting transpilation/bundlers
• add ESM build targeting browsers
• keep CJS build, pretranspiled with a target for all modern browsers
• add a new CJS entry point .../compat for every entry point that would also target IE11 (only this build would contain enableES5)

[markerikson]

My inclination at the moment would be to actually do most of that in RTK 1.6 or 1.7.

Most of that is additive - either new APIs or new build artifacts. Agreed that major version numbers can also be used to indicate "big new features", but I see this as more of a parallel to React Hooks coming out in a 16.8 minor, and 17.0 being used for just compat and cleanup.

I think that doing it as a minor build would make it a bit easier for folks who are using RTK to get the new RTK Query functionality more automatically.

[rocon4]

Any further integration of RTK Query into Redux Toolkit would be awesome. I've been switching a lot of simple fetch/ mutation requests that were originally in slices over to it (new to React/ Redux in general so I was placing a bit too much in Redux Toolkit). My code has slimmed down quite a bit already, however occasionally I want to update a piece of global state in redux through extraReducers from an RTK Query mutation. I'm not sure if this is currently possible or even advised too if it is (can't find in the docs). Cheers!

[markerikson]

@rocon4 yep, and that's why we're planning to merge the RTK Query functionality back into the RTK package itself - to have it all right there and accessible without needing to install other packages (which, in some cases, may ease corporate approval processes and such).

Usage questions probably oughta go over to a Discussion thread or Reactiflux, but off the top of my head, I think you could import the thunks that are auto-generated by createApi into your other slice files and handle those actions there as well, just as if you'd called createAsyncThunk yourself and were wanting to handle that in a slice.

[msutkowski]

Any further integration of RTK Query into Redux Toolkit would be awesome. I've been switching a lot of simple fetch/ mutation requests that were originally in slices over to it (new to React/ Redux in general so I was placing a bit too much in Redux Toolkit). My code has slimmed down quite a bit already, however occasionally I want to update a piece of global state in redux through extraReducers from an RTK Query mutation. I'm not sure if this is currently possible or even advised too if it is (can't find in the docs). Cheers!

@rocon You for sure can. All endpoints have matcher properties on them.

extraReducers: (builder) => {
    builder
      .addMatcher(
        api.endpoints.yourEndpoint.matchFulfilled,
        (state, { payload: { result } }) => {
              // do things with the result
        }
      );
  },

Feel free to jump on reactiflux or file an issue in the rtkq repo before it gets merged in if you have any issues. It's on my list to update in the examples as more focus will be on integrating with RTK specifically in the near future.

[markerikson]

Here's my thoughts atm:

• We just merged in the big TDX->ESBuild conversion over in chore(build): move tsdx to esbuild #957 . The build artifacts we're generating should effectively match what we've had so far: ES5 syntax and IE11 compat for CJS/ESM/UMD, plus a new set of "modern" artifacts that target bundlers and browsers. So, in theory, none of the build changes should be breaking yet.
• I want to get the RTKQ stuff out in a minor build to help increase the initial uptake on that. Plus, it's all additive APIs, much like React released hooks in a 16.8 minor. (I can also see an argument for only releasing those in a 2.0 as a carrot to get people to upgrade, so I'm willing to listen to debate on this point.)
• It sounds as if including an exports field in package.json is effectively a breaking change due to Node compat concerns, so we can't do that yet
• I'd notionally assumed that RTK 2.0 would include Redux 5.0 whenever that happened, but we still have no concrete plans to release Redux 5.0 any time soon
• However, Tim recently mentioned to me that he might have some time to look at the Redux 5.0 work in the semi-near-ish future.

So. My plan atm is to go ahead and continue with this next release as RTK 1.6, including the build tooling changes and RTKQ. We'll keep IE11/ES5 compat for now. That minimizes changes and gives more people a chance to adopt RTKQ out of the box.

We'll hold off on a 2.0 release for now. When it's time to do that, we'll drop IE11 compat and probably the UMD builds. It would be nice if we had a Redux 5.0 release ready to go so that we can sort out all the potential TypeScript issues that are likely to occur as part of that.

[markerikson]

I suppose another set of questions is, what about our actual APIs would we want to drop or change that would be breaking?

I'll toss one out: the object syntax for createReducer and createSlice.extraReducers. Might be a bit controversial, especially given that it was a bit of a selling point for RTK early on, but given that we strongly emphasize the builder syntax at this point I think it's justifiable.

Any other suggestions?

[Shrugsy]

A couple others that could potentially be dropped:

• getDefaultMiddleware export - The callback notation for the middleware property is superior in the high majority of cases given that it will be pre-typed (note that I've opened 🗑 📝 Deprecate getDefaultMiddleware export #1258 to deprecate it already)
• unwrapResult export - Now that the dispatched thunk from cAT has an unwrap property directly, I don't think there are many use cases for using unwrapResult explicitly. However, given that it can be called on the action rather than the promise that resolves to the action, it theoretically enables alternate use-cases

[grumpyTofu]

How about state persistence for offline support?

[markerikson]

@grumpyTofu Not sure what you're suggesting there. File a separate issue / discussion thread to provide details?

[grumpyTofu]

@markerikson based on the previous discussion, it looks like you are looking for ideas that could be really cool and significant enough to substantiate a '2.0' release, right? RTK Query already solves caching, so what about making everything else persistent? Or maybe adding some online/offline listeners to api slices so that a query could detect if the user is offline and manage the state of whatever a user would do while offline and subsequently make necessary api calls once the connection is restored?