v1.9.0-alpha.0

[markerikson]

This feature preview release adds new options and improves behavior for RTK Query, adds a runtime deprecation for the "object" form of createReducer/createSlice.extraReducers, adds the ability to define a "pre-typed" version of createAsyncThunk, improves TS inference of store enhancers, and exports additional TS types.

We hope to add a couple additional RTKQ options as part of the final 1.9 release, including an upsertQueryData util. See the RTK 1.9 milestone for remaining items. No hard ETA yet, but ideally we'd like to publish 1.9 within the next couple weeks if we can wrap things up.

Notable Changes

Some highlights for this alpha:

RTKQ merge Option

RTKQ was built around the assumption that the server is the source of truth, and every refetch replaces the cached data on the client. There are use cases when it would be useful to merge an incoming response into the existing cached data instead, such as pagination or APIs that return varying results over time.

Query endpoints can now accept a merge(cachedData, responseData) callback that lets you do Immer-powered "mutations" to update the existing cached data instead of replacing it entirely.

Object Reducer Deprecation Warning

RTK's createReducer API was originally designed to accept a lookup table of action type strings to case reducers, like { "ADD_TODO" : (state, action) => {} }. We later added the "builder callback" form to allow more flexibility in adding "matchers" and a default handler, and did the same for createSlice.extraReducers.

We intend to remove the "object" form for both createReducer and createSlice.extraReducers in RTK 2.0. The builder callback form is effectively the same number of lines of code, and works much better with TypeScript.

Starting with this release, RTK will print a one-time runtime warning for both createReducer and createSlice.extraReducers if you pass in an object argument.

As an example, this:

const todoAdded = createAction('todos/todoAdded');

createReducer(initialState, {
  [todoAdded]: (state, action) => {}
})

createSlice({
  name,
  initialState,
  reducers: {/* case reducers here */},
  extraReducers: {
    [todoAdded]: (state, action) => {}
  }
})

should be migrated to:

createReducer(initialState, builder => {
  builder.addCase(todoAdded, (state, action) => {})
})

createSlice({
  name,
  initialState,
  reducers: {/* case reducers here */},
  extraReducers: builder => {
    builder.addCase(todoAdded, (state, action) => {})
  }
})

We have initial codemods in the repo that will help rewrite the object form to the builder form, and we'll publish those with instructions alongside 1.9 when it goes final.

RTKQ Internal Improvements

When query hooks mount, they dispatch actions to subscribe to the relevant data. The first hook to do so will dispatch a "subscription/fulfilled" action, and all further hooks asking for the same cache key will dispatch "subscription/rejected" actions. Both cause the reducer logic to add another entry to the subscription tracking.

The dispatching of individual "subscription/rejected" actions was causing perf issues when many components mounted at once, due to the number of extra dispatches. RTKQ now batches those into a single combined action per event loop tick, which improves perf for some many-component use cases noticeably.

TS Types

configureStore now correctly infers changes to the store shape from any store enhancers.

There's now a createAsyncThunk.withTypes() method that can be used to create a "pre-typed" version of createAsyncThunk with types like {state, dispatch, extra} baked in.

What's Changed

• Add isJsonContentType predicate to fetchBaseQuery by @msutkowski in Add isJsonContentType predicate to fetchBaseQuery #2331
• Add jsonContentType to fetchBaseQuery options by @msutkowski in Add jsonContentType to fetchBaseQuery options #2403
• Add ThunkMiddleware to the re-exported types from redux-thunk by @orta in Add ThunkMiddleware to the re-exported types from redux-thunk #2451
• add timeout option to fetchBaseQuery by @phryneas in add timeout option to fetchBaseQuery #2143
• createSlice: use template literal types for action type by @phryneas in createSlice: use template literal types for action type #2250
• add types for manually typing hook results in userland code by @phryneas in add types for manually typing hook results in userland code #2276
• Add 'content-type' ResponseHandler by @taylorkline in Add 'content-type' ResponseHandler #2363
• feature : endpoint-specific args serializers by @michal-kurz in feature : endpoint-specific args serializers #2493
• RFC: add "merge" functionality by @phryneas in RFC: add "merge" functionality #1059
• Add runtime deprecation warning for reducer object notation by @markerikson in Add runtime deprecation warning for reducer object notation #2591
• feat: Add the ability to type StoreEnhancers by @fostyfost in feat: Add the ability to type StoreEnhancers #2550
• Batch RTKQ "subscribe on reject" actions, and improve cache collection timer handling by @markerikson in Batch RTKQ "subscribe on reject" actions, and improve cache collection timer handling #2599
• add transformErrorReponse to rtkq endpoints by @dreyks in add transformErrorReponse to rtkq endpoints #1841
• Fix manually initiate()d rtk-query promises by @wesen in Fix manually initiate()d rtk-query promises #2187
• Implement codemods for createReducer and createSlice builder by @markerikson in Implement codemods for createReducer and createSlice builder #2602
• RFC: Expose endpoint types by @phryneas in RFC: Expose endpoint types #1646
• add createAsyncThunk.withTypes by @phryneas in add createAsyncThunk.withTypes #2604

Full Changelog: v1.8.5...v1.9.0-alpha.0

---

This discussion was created from the release v1.9.0-alpha.0.

[gordon-eliel]

Hey @markerikson I am playing with the new merge functionality and I'm running into some issues using it for infinite pagination. If I pass in a page param, in the api slice, a new cache entry is created per page, which does not execute the merge function. I tried using a static cache key for the query but the hook does not get executed, I'm assuming its because the cache key does not change.

Question is how is this feature supposed to be used from a query perspective?

[gordon-eliel]

I guess I might be using the api wrong. What happen is, the query if executed the first time with page=1, this returns the correct result saved into the store, but when the page param changes, the query never gets executed again. I have setup serializeQueryArgs to the endpointName. This is basically what I have for the query:

  const [pageNumber, setPageNumber] = useState(1);
  const {
    data,
    isFetching,
    isLoading,
    refetch,
  } = useListTransactionsQuery(
    { pageNumber },
    {
      pollingInterval: 3000,
      refetchOnMountOrArgChange: true,
      skip: false,
    }
  );

And for the endpoint I have for serializing the args:

serializeQueryArgs: ({ endpointName }) => {
     return endpointName;
},

The query never gets executed when pageNumber changes

[markerikson]

Hmm. It's certainly possible that we're not re-fetching because the serializeQueryArgs result hasn't changed. I wasn't entirely sure what the actual behavior here would be.

Could you put together a CodeSandbox that shows this happening? This is why we have alphas :)

[gordon-eliel]

Here is a sandbox that demonstrates the issues:

https://codesandbox.io/s/merge-query-sandbox-4fmws8?file=/src/Pokemons.tsx

[gordon-eliel]

I think this line may be the issue:

redux-toolkit/packages/toolkit/src/query/react/buildHooks.ts

Line 614 in 3de00f4

if (

I'll take a look at some possible solutions, this is my first time looking into the codebase so I might be making some assumptions here

[markerikson]

Okay, found what's going on.

Made a replay , and if you open up https://app.replay.io/recording/rtk-190-alpha-merge-pagination-not-refetching--13800b41-6680-402f-a564-a80a280a74d7?point=9735556619499725871884967098715939&time=4275&hasFrames=false , you can see that what's happening:

• The query hook does see a new stableArg value, and dispatches initiate() again
• This does execute queryThunk...
• but the condition check inside of queryThunk ends up retrieving the existing cache entry for the same cache key, sees that it's already in a "fulfilled" status, and bails out without trying to fetch the data.

That makes sense, conceptually. The question is what to do about it.

Here's the current condition logic for reference:

    condition(arg, { getState }) {
      const state = getState()
      const requestState = state[reducerPath]?.queries?.[arg.queryCacheKey]
      const fulfilledVal = requestState?.fulfilledTimeStamp

      // Order of these checks matters.
      // In order for `upsertQueryData` to successfully run while an existing request is in flight,
      /// we have to check for that first, otherwise `queryThunk` will bail out and not run at all.
      if (isUpsertQuery(arg)) return true

      // Don't retry a request that's currently in-flight
      if (requestState?.status === 'pending') return false

      // if this is forced, continue
      if (isForcedQuery(arg, state)) return true

      // Pull from the cache unless we explicitly force refetch or qualify based on time
      if (fulfilledVal)
        // Value is cached and we didn't specify to refresh, skip it.
        return false

      return true
    },

Filed #2684 so we can track this separately - let's continue any discussion over there.