[RTK Query] api.util.upsertQueryData not work correctly when has transformResponse

[hieuvuvan]

for example

// http GET /admin/post.json
// response json: {"post": {"id": 123, "title": "the post"}}


type Post = {
  id: number;
  title: string;
}

type PostResponse = {
  post: Post
}

export const api = createApi({
  reducerPath: "api",
  baseQuery: fetchBaseQuery(),
  endpoints: (builder) => ({
    getPost: builder.query<Post, void>({
      query: () => `/admin/post.json`,
      transformResponse: (response: PostResponse) => response.post,
      providesTags: ["post"],
    })
  })
})

// Some where in the app

const updatedPost = {
  id: 123,
  title: "My Post"
}

dispatch(api.util.upsertQueryData("getPost", updatedPost)); // this not work, undefined body dispatch

I see it is breaking change from version 2.6.0, i also comment on the commit

[MrZipper7]

Was coming here to document more or less the same thing. What I found in my case is that if you dispatch an object correctly typed as the response type, then it will run the transformResponse on it and dispatch it correctly to the store.

However, typescript will claim that the object is not typed correctly (i.e. that it needs to be typed as the final type rather than the initial response type.

So in OP's case, this would work correctly:

const updatedPost = {
  "post": {
    "id": 123, 
    "title": "the post"
  }
}

dispatch(api.util.upsertQueryData("getPost", updatedPost));

but there would be a present typescript error of something like:

dispatch(api.util.upsertQueryData("getPost", updatedPost));
                                             ~~~~~~~~~~~
Argument of type [etc] is not assignable to parameter of type 'Post'.

So I guess what I'm not clear on is whether the upserted data is supposed to be the final type and the transformResponse is skipped, or if it should be the response type with the expectation that it will be transformed. Either way, something isn't working correctly.

Based on the code the OP shared, it seems like the intent was for the transformResponse to run, in which case, the main issue is the incorrect expected typing (in addition to the undocumented breaking change).

[nick-lvov-dev]

Having the same issue, I don't know exactly when the transformResponse behavior was changed because I'm sure it didn't use to run before on upsertQueryData. Please fix the types!

[codingedgar]

My workaround for this issue has been

  transformResponse: (response, meta) => {
        if (meta) {
          return Schema.parse(response);
        }
        // seems like transformResponse runs even when query is not triggered
        return response as Schema;
      },

I do a few upsertQueryData, but only in one place transformResponse runs, which throws.

[markerikson]

I'm not clear what the actual issue report is. Is this a types problem, or a runtime problem? Can someone provide a reproduction?

[codingedgar]

I'm not clear what the actual issue report is. Is this a types problem, or a runtime problem? Can someone provide a reproduction?

When dispatching a upsertQueryData if the endpoint has transformResponse then it runs, which crashes because upsertQueryData expects transformed response

i'll make a reproduction

[nick-lvov-dev]

@markerikson It's a types problem, if transformResponse is used on a query it's not reflected in the type of upsertQueryData, the types expect you to provide the formatted value, but the function runs transformResponse on that value which of course throws an error. The behavior used to be that transformResponse didn't run on upsertQueryData, now it does but it still expects you to provide the final type instead of the initial type.

[EskiMojo14]

it's a runtime problem - in the vast majority of cases we do not have the initial type (and until recently it was impossible) so we should just expect the transformed value and not run transformResponse on it. I believe this is also how it used to work, so something must have caused a regression.

[markerikson]

It's most likely from me restructuring the query thunk logic in the infinite query PR:

• RTKQ Infinite Query integration #4738

[codingedgar]

https://codesandbox.io/p/devbox/musing-water-x6nqxx?from-embed=&workspaceId=ws_9fP6D7Gfvn6vWMjTUCVr1K

import { createApi, fetchBaseQuery } from "@reduxjs/toolkit/query/react";

export const pokemonApi = createApi({
  baseQuery: fetchBaseQuery({ baseUrl: "https://pokeapi.co/api/v2/" }),
  tagTypes: [],
  endpoints: (build) => ({
    getPokemonByName: build.query({
      query: (name: string) => `pokemon/${name}`,
      transformResponse: (response, meta) => {
        console.log("transformResponse running", response, meta);
        // worksaround fix
        if (meta) {
          return response;
        } else {
          throw Error("Running due to upsert");
        }
      },
    }),
    upsertDate: build.query({
      queryFn: () => ({ data: "ok" }),
      onQueryStarted(_, { dispatch }) {
        console.log("onQueryStarted");
        dispatch(
          pokemonApi.util.upsertQueryData(
            "getPokemonByName",
            "pikachu",
            "This will make getPokemonByName.transformResponse run"
          )
        );
      },
    }),
  }),
});

// Export hooks for usage in functional components
export const { useGetPokemonByNameQuery, useUpsertDateQuery } = pokemonApi;

Here, getPokemonByName.transformResponse runs even when getPokemonByName.query never runs.

// App.tsx
import "./styles.css";
import { useUpsertDateQuery } from "./services/pokemon";

export default function App() {
  const { data, error, isLoading } = useUpsertDateQuery(undefined);

  return (
    <div className="App">
      {error ? (
        <>Oh no, there was an error</>
      ) : isLoading ? (
        <>Loading...</>
      ) : data ? (
        <>ok</>
      ) : null}
    </div>
  );
}

[markerikson]

Okay, I think I've tracked down the cause.

Up through 2.5.0, the relevant logic here was:

      if (forceQueryFn) {
        result = forceQueryFn()
      } else if (endpointDefinition.query) {
        result = await baseQuery(
          endpointDefinition.query(arg.originalArgs),
          baseQueryApi,
          endpointDefinition.extraOptions as any,
        )

        if (endpointDefinition.transformResponse) {
          transformResponse = endpointDefinition.transformResponse
        }
      } else {
        result = await endpointDefinition.queryFn(
          arg.originalArgs,
          baseQueryApi,
          endpointDefinition.extraOptions as any,
          (arg) =>
            baseQuery(
              arg,
              baseQueryApi,
              endpointDefinition.extraOptions as any,
            ),
        )
      }

Note that we only override the default transformResponse reference if we actually ran the query method for that endpoint.

When I refactored the logic to support infinite queries, I removed that clause and changed the definition of the default transformResponse method to be:

  const getTransformCallbackForEndpoint = (
    endpointDefinition: EndpointDefinition<any, any, any, any>,
    transformFieldName: 'transformResponse' | 'transformErrorResponse',
  ): TransformCallback => {
    return endpointDefinition.query && endpointDefinition[transformFieldName]
      ? (endpointDefinition[transformFieldName]! as TransformCallback)
      : defaultTransformResponse
  }

// later
      let transformResponse = getTransformCallbackForEndpoint(
        endpointDefinition,
        'transformResponse',
      )

In other words, now it's always using the transformResponse method for an endpoint if it's defined, regardless of whether it's a forced upsert, a query, or a queryFn. That's a bug - it should only be happening when there's a query usage.

[nick-lvov-dev]

Ok so when is this going to be released?