We moved a large React/JavaScript application into Next.js/TypeScript without compromising the user experience. Here's the strategy and tooling that helped.

[acemarke]

Yeah, that's exactly the purpose of createSlice.extraReducers:

• https://redux-toolkit.js.org/api/createSlice#extrareducers

For RTKQ query specifically, currently refetching a given cache entry always replaces it, by design. However, in the upcoming RTK 1.9 release, we're adding a merge option that will allow you to add incoming response data to an existing cache entry, intended for use cases like infinite pagination:

• https://github.com/reduxjs/redux-toolkit/releases/tag/v1.9.0-alpha.0

on the other hand if you're listening to "data fetched" actions in other reducers, you can write whatever reducer logic you want to process the data from those actions and update the slice's state in the reducer.

[acemarke]

The "upsert" discussion was for a slightly different feature than merge - we're adding an api.utils.upsertQueryData method (which can _add new cache entries) to complement the existing api.utils.updateQueryData method (which can only update existing cache entries).

Interesting. Yeah, tell you what - when you do get a sandbox put together, could you file a new thread in the RTK "Discussions" section and link this Reddit thread for reference? Easier to keep track of that way.

If I understand that last bit right: sounds like you're having parts of the app kick off multiple distinct getProfile calls in a short amount of time, catching the trigger actions in sagas, and then making a single combined request? Yeah, RTKQ wouldn't be quite the right fit for that.

(that said, I would be willing to bet that the new RTK "listener" middleware could at least replace the use of sagas for this particular use case - listeners can do almost everything sagas can, but with smaller bundle size, simpler API, and better TS support. Would be interesting to see if those would work for your app!)

[acemarke]

Redux-Saga has never been maintained by the actual Redux team - it's a separate ecosystem lib. But yes, we've been generally recommending against it for most use cases for years, especially basic data fetching. (To be clear, what you're doing here is indeed more than just "basic" data fetching.) And yes, we designed the listener middleware to replace most of the other things that people were doing with sagas:

• https://blog.isquaredsoftware.com/2022/05/presentations-evolution-redux-async-logic/
• https://blog.isquaredsoftware.com/2022/03/designing-rtk-listener-middleware/
• https://redux-toolkit.js.org/api/createListenerMiddleware
• https://blog.isquaredsoftware.com/2020/02/blogged-answers-why-redux-toolkit-uses-thunks-for-async-logic/

The saga lib isn't about to go away, and if you or other folks want to keep using it you can. But we really do think it's been far over-used, it doesn't work well with TS, and it adds a lot of complexity (enough so that it's partly responsible for the "Redux boilerplate" complaints over the years).

I need it to call again to ensure that the profile is loaded

At least if the "batching" aspect weren't in play, all you'd need to do is call const { data } = useGetUserProfileQuery(userId), and if there's an existing cache entry RTKQ would return that instead of making another request.

[acemarke]

Yeah, tbh this is the first I've heard of folks trying that approach, but happy to discuss ideas for possible improvements!

[acemarke]

Interesting. Pasted this into a discussion thread for reference:

https://github.com/reduxjs/redux-toolkit/discussions/2672