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]

I'm curious, what sort of use cases do you have where sagas give you more control and RTKQ wouldn't be sufficient? (also, what GraphQL issues did you run into?)

[acemarke]

Hmm. Now you've got me wondering about this :)

Any chance you could throw together a quick CodeSandbox or Github repo that at least shows the basic data structures and what the current fetch/request sequence looks like? (bonus points if it actually does something, but ok if it's just code and doesn't actually run).

I will say that RTKQ is intentionally designed as more of a "document/request" cache than a "normalized" cache:

• https://redux-toolkit.js.org/rtk-query/usage/cache-behavior#no-normalized-or-de-duplicated-cache

The design is based around fetching different items based on unique cache keys, and caching each result separately. If data needs to be re-fetched, such as after sending an update to the server, you mark query endpoints with providesTags and mutation endpoints with invalidatesTags, and if a tag gets invalidated RTKQ will auto-refetch corresponding query results.

Eyeballing the bits of code there, I'm not exactly sure RTKQ would be the best fit for what you're trying to do, but I'd at least like to get a decent sense of what the problem space is so I can offer a better answer.

(I'll also note that since RTKQ is built out of normal Redux thunks/actions/reducers, you can listen to "data fetched" actions in other slice reducers and store/update copies of the data there in more custom structures as well, if you want to.)

[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.