RTK 1.8 and 1.9 planning

[markerikson]

This was originally "1.8 planning", but 1.8 ended up just having the listener middleware. So, keeping the issue around for both.

1.8:

• TS fixes for configureStore and getDefaultMiddleware
• Merge in the listener middleware

Initial notional items for 1.9:

• Drop support for TS < 4.1
• Actual string literal types for createSlice

What else would we want to get in?

Existing milestone: https://github.com/reduxjs/redux-toolkit/milestone/7

Looking through the issues, other candidates:

• Could go in a 1.8.x:
  • Using updateMany in adapter with custom sortComparer ignores several updates with same id  #1853 / Fix #1853 - updateMany on sorted entity adapter #1860
• Probably 1.9:
  • Add upsertQueryData functionality #1720
  • RTK Query - query level customization/normalization of cache key #1668
  • RTKQ feature proposal: Add transformError property to the endpoints #1139
  • Add inferred action creator types #975
  • RFC: add "merge" functionality #1059

For the record, I think this probably ought to be the last feature release before we look at doing RTK 2.0 and dropping IE11 compat ( ref: #958 )

[phryneas]

maybe a cAT.pinTypes/typeFactory thing?

[markerikson]

Unrelated but as a note for later: we should link the RTKQ "Essentials" tutorial pages from the RTKQ "Overview" page:

https://www.reddit.com/r/webdev/comments/sc6eoc/redux_toolkit_query_is_no_one_using_it/

[lindapaiste]

Another docs suggestion (possibly for me to implement): add more info/examples about dealing with errors. In particular, explaining the difference between a fetch error and serialized JavaScript error. https://stackoverflow.com/questions/70899492/redux-toolkit-do-not-send-request-when-query-param-is-invalid/71002555?noredirect=1#comment125554343_71002555

[phryneas]

@lindapaiste that would be a very welcome contribution!

[markerikson]

Throwing this here for lack of anywhere better:

https://www.reddit.com/r/reactjs/comments/q6lit4/thoughts_about_redux_reactquery_together/i0s3f27/

One thing i found that it needs extra config is SSR, if you are planning on doing SSR with something like Next for example, then you need to setup next-redux-wrapper and split your state, and combining reducers with the apiSlice while also supporting a global HYDRATE action to sync up server state with client state was a bit of a pain, we had to set a reducer case for HYDRATE for each slice, which can get big.

RTK Query looks promising but SSR is certainly a bit more painful compared to the "initialData" approach of react-query, one thing i do like is that you can still use endpoints defined within your apiSlice on the server instead of custom fetch functions.

Also a quick note about that, if you are working with a custom api fetch library that handles all your endpoint calls, its a bit hard to integrate that with query builders in RTK Query, RTK Query seems like a great option if you are using axios or fetch to build your data fetching side of the app from the ground. If you have something custom built already around some fetching library to handle your endpoint calls, then you will probably need to work some sort of integration between RTK Query and your library, react-query is a bit more detached from what you end up using as a fetcher.

[phryneas]

We should also deprecate the object notation of extraReducers and createReducer so we can remove it in 2.0.

I did some experiments - while removing is not a problem, deprecating the extraReducers object notation seems impossible. It would require adding a second overload to createSlice and that breaks half the inference (seems to be a TS quirk). So I would suggest deprecating it with a runtime warning in dev instead.

[markerikson]

If @FaberVitale can pull off the Suspense support in #2245 , that would presumably be 1.9 as well.

[FaberVitale]

If @FaberVitale can pull off the Suspense support in #2245 , that would presumably be 1.9 as well.

We need to upgrade react, react-redux, react-dom & @types/react to react 18 versions:

redux-toolkit/package.json

Line 43 in 0050738

"react": "npm:17.0.2",

Are there features in the codebase that need useSyncExternalStore?

IIRC there was an issue with ApiProvider:

redux-toolkit/packages/toolkit/src/query/react/ApiProvider.tsx

Line 48 in 0050738

setupListeners(store.dispatch, props.setupListeners)

[markerikson]

Hmm. That is going to make versioning interesting :)

Given that the rest of RTKQ's features work with any version of React that has hooks... maybe we accept a React peer range of 16.8+, but have a runtime dev check in the suspense functionality that throws an error if it isn't a high enough React version?

Also we may need to update all of our examples and tests to work under React 18 as well.

And yeah, that line in ApiProvider should really be in an effect

[phryneas]

I opened a PR for that ApiProvider bug.