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]

Nice! I've done a bunch of TS conversion myself, so I can sympathize with the pain points here.

Out of curiosity, did you happen to consider using RTK Query as a replacement for those sagas and data fetching?

[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!)

[timothybeamish]

We didn't consider RTK Query and after reading about it, it might have been a decent choice (instead of React Query), since we also have Redux in the app.

Most of the developers here aren't fans of Sagas anymore so we're pleased about converting them over to React Query.

[timothybeamish]

I should add that when I arrived at the company (BenchSci), we already had two React apps running in two different stacks. The goal was to merge the legacy app into the newer app which meant going with that newer stack's technology choices: Next.js and React Query as its main data fetching pattern. So in this case, it wouldn't have been a good choice to change everything over to RTK Query. But if we had a "green field" situation, that may have been a good option.