Add `upsertQueryData` functionality

[chrisjagoda]

I have a use case where I would like to pass an additional parameter when calling an endpoint, where I do not want this additional parameter to be cached. The first parameter, args, would still be serialized as the cache key as normal.

Would it be possible to provide an additional field to pass some additional data when calling an endpoint via a hook/initiate? My use case is for calling a query endpoint with initiate.

Perhaps an additional optional parameter after options? Something likeextraArgs, noCacheArgs, or nonCacheableArgs. I don't know if it makes sense have it on the options parameter, https://redux-toolkit.js.org/rtk-query/api/created-api/endpoints#initiate, but that would work too.

[chrisjagoda]

Specifically, my use case is to cache the result from a create api call in a different cache. I can do this, but it comes at the cost of having to override serializeQueryArgs, and having to have some additional logic in the providesTags field for postById.

If I could pass the response from createPost in postsClient.endpoints.postById.initiate, I could see that I have that data in the queryFn for getById, and if so, return it, caching it, and if not, call the api and cache it as normal.

import { createApi } from "@reduxjs/toolkit/query/react";
import posts from "some-api";
import { getByIdProvidesTags, getByIdQueryFn, mapClientResponse, serializeGetByIdArgs } from "./postsHelper";

export const POSTS = "posts";
export const POST_BY_ID = "postById";

const { get: getPosts, getById: getPostById, create: createPost, update: updatePost } = posts;

const postsApi = createApi({
    reducerPath: "posts",
    tagTypes: [POSTS, POST_BY_ID],
    baseQuery: ({ args, method }) => method(...args).then(mapClientResponse),
    serializeQueryArgs: serializeGetByIdArgs(POST_BY_ID),
    endpoints: (builder) => ({
        posts: builder.query({
            query: (args) => ({ args: [args], method: getPosts }),
            providesTags: (result, error, args) => [{ type: POSTS, id: JSON.stringify(args) }],
        }),
        postById: builder.query({
            queryFn: getByIdQueryFn(getPostById),
            providesTags: getByIdProvidesTags(POST_BY_ID),
        }),
        createPost: builder.mutation({
            query: (args) => ({ args: [args], method: createPost }),
            invalidatesTags: (result, error) => (error ? [] : [{ type: POSTS }]),
            onQueryStarted: (_args, { dispatch, queryFulfilled }) =>
                queryFulfilled.then(({ data }) => dispatch(postsClient.endpoints.postById.initiate(data))),
        }),
        updatePost: builder.mutation({
            query: (args) => ({ args: [args], method: updatePost }),
            invalidatesTags: (result, error) => (error ? [] : [{ type: POSTS }]),
        }),
    }),
});

export default postsApi;
export const { usePostsQuery, usePostByIdQuery, useCreatePostMutation, useUpdatePostMutation } = postsClient;

[phryneas]

Without the code for getByIdQueryFn and serializeGetByIdArgs and maybe a bit more in-depth explanation, I really have no idea what exactly you are trying to accomplish here, sorry.

Generally, no, that is not supported, and so far I have not seen a use case valid enough to add first-class support for it, as it is very uncommon, there are ways around it (although clumsy) and would probably lead to lots of bugs and unexpected behaviour for users: the serialized arg is the base for the decision "do we make another request?" and many people would wonder why, even if they changed an argument, no additional request would be made.

[chrisjagoda]

This is what those two functions look like.

// Serialize args for getById endpoints
// Use when calling getById endpoint by either the id or the passed object to map the id from passed object to serializedKey
export const serializeGetByIdArgs =
    (getByIdEndpointName: string) =>
    ({ endpointName, queryArgs }) =>
        `${endpointName}(${
            endpointName === getByIdEndpointName && isObject(queryArgs) ? queryArgs.id : JSON.stringify(queryArgs)
        })`;

// Call getById and cache response if id passed as args, or cache getById object if object passed as args
// Use when calling getById endpoint by either the id or with an object to cache the object based off its id instead of retrieving it and then caching it
export const getByIdQueryFn =
    (method) =>
    <T>(args, _api, _extraOptions, baseQuery): MaybePromise<QueryReturnValue<T, unknown, unknown>> =>
        isObject(args) ? { data: args } : baseQuery({ args: [args], method });

// Provide id as tag id if id passed as args, or provide object id as tag id if object passed as args
// Use when calling getById endpoint by either the id or with an object to map the id from from passed object to tag
export const getByIdProvidesTags = (tagName) => (result, error, args) =>
    [{ type: tagName, id: isObject(args) ? args.id : args }];

Essentially what I'm doing with them is handling the case where instead of passing the id to postById to retrieve the post by id (the usual case), I'm passing the entire post as the arg to cache it in postById, without actually making the call to retrieve it.

If I could pass an additional parameter to an endpoint, I could avoid having to override the method serializeGetByIdArgs and not have the extra logic to handle two different types of args (the id or the post) in getByIdProvidesTags and getByIdQueryFn.

Instead in createPost I could do something like:

createPost: builder.mutation({
            query: (args) => ({ args: [args], method: createPost }),
            invalidatesTags: (result, error) => (error ? [] : [{ type: POSTS }]),
            onQueryStarted: (_args, { dispatch, queryFulfilled }) =>
                queryFulfilled.then(({ data }) => dispatch(postsClient.endpoints.postById.initiate(data.id, undefined, { data }))),
        }),

and then getByQueryFn could look like so, so that the endpoint method is only called when extraArgs.data is falsy, else we cache the data, as in my case the response returned from createPost is the same as postById.

export const getByIdQueryFn =
    (method) =>
    <T>(args, _api, _extraOptions, baseQuery, extraArgs): MaybePromise<QueryReturnValue<T, unknown, unknown>> =>
        extraArgs?.data ? { data: extraArgs.data } : baseQuery({ args: [args], method });

[chrisjagoda]

I can think of some additional cases where having a place to put args that aren't part of the cache key would be useful.

One might be if you needed to have different options when calling an endpoint. Perhaps something like having a different retry or backoff approach for an endpoint when called from one place, but not another.

These options would have to be passed to the endpoint conditionally, and to have them share a cache and do so is not easy.

[phryneas]

So in that specific use case... how should provides work? If invalidated, it would fire the same query and return the old value instead of fetching new, updated data from the server. Are you sure you don't just want to prime your cache with some data from another source?
In that case, cache management utilities might be more useful.

As for different backoffs: imagine, two component are mounted with the same cache entry - but different backoffs. Which would win? And if the components mounted in a different order, or the first one rerendered after the second one rendered, which one would win then? Would it cause a request every time?
Coordinating something like that is very complicated - even for built-in functionality like polling. Having it only on the endpoint is at least a bit more manageable.

[chrisjagoda]

Basically, there is one route to pass data to queries/mutations, that is through args. I want a backdoor to pass additional data, called extraArgs, with the difference made clear that anything passed through this backdoor will not be subject to any of the rules/side effects of args.

Provides would still behave the same, my "backdoor" cached items should behave no different than one that is normally cached.

I looked into the cache management utilities and I couldn't really find any way to provide what I want. I want the posts cached by id as args in the rtk query api endpoint, but I want to be able to freely create new cache entries, without going through the process of calling the endpoint api to retrieve the data.

Really, even more to my point and more direct/useful would be a method like

createQueryData(endpoint, args, data) // endpoint being the endpoint, same as in updateQueryData, args - the cache args, data - the data we want to cache

postsClient.util.createQueryData("postsById", data.id, { data }), that I could call instead the weirdness I'm doing calling postsClient.endpoints.postById.initiate(...), in createPost -> onQueryStarted. However, I think there may be an issue opened for something like this.

Backoffs may be more complicated on further consideration.

[phryneas]

As far as I know, people have been using patchQueryData​ with a patch in the form [ { op: "replace", path: [], value: yourNewValue ] for that.

[chrisjagoda]

That doesn't work for my use case. patchQueryData will only update query data for a cached entry. It won't create if there's not one there.

[phryneas]

Fascinating, someone was reporting they were doing this. But yeah, looking at the code, it shouldn't work.

I guess sooner or later we will need a upsertQueryData functionality. I'm not a fan of it, because it will enable a lot of patterns people could use to hurt themselves, but I guess they'll find workarounds that are even more dangerous otherwise.

[chrisjagoda]

I guess they'll find workarounds that are even more dangerous otherwise.

Indeed we will, haha. Thank you for taking the time to understand my problem.