Updating a cache entry without knowing the original params that generated it

[uraniumanchor]

I have a situation where I want a mutation to optimistically update all entries in the query cache that contain an object matching the ID, but I don't want to have to pass the original query arguments that fetched in the first place, for a variety of reasons. I came up with the following as a quick proof of concept but it feels really gross.

      async onQueryStarted(id, api) {
        const state = api.getState();
        const patchResults: { undo: () => void }[] = [];
        Object.entries(state.api.queries)
          .forEach(([k, v]) => {
            const [_, s] = /^models\((.*)\)$/.exec(k) || [];
            if (s != null && (v?.data as Model[]).find(b => b.id === id)) {
              patchResults.push(
                api.dispatch(
                  // this also complains about the result of JSON.parse not matching the type of the queryArgs, even though it ultimately works since it results in the same key
                  apiSlice.util.updateQueryData('models', JSON.parse(s), draft => {
                    const d = draft.find(m => m.id === id);
                    if (d) {
                      // modify state here
                    }
                  }),
                ),
              );
            }
          });
        try {
          await api.queryFulfilled;
        } catch {
          patchResults.forEach(p => p.undo());
        }
      },

I thought maybe adding a hook in onCacheEntryAdded might also help, but the api passed to that function doesn't seem to
have access to the generated key, and trying to just use defaultSerializeQueryArgs to recreate it asked for an argument that seems entirely superfluous, since it doesn't get used, far as I can tell, though rather trivial to generate once I figured out what it was asking for. Plus this still ultimately has to match the query cache keys as above, this just maintains an explicit list rather than scanning -all- the queries for the right pattern.

      async onCacheEntryAdded(args, api) {
        await api.cacheDataLoaded;
        const key = defaultSerializeQueryArgs({
          queryArgs: args,
          endpointDefinition: {
            queryFn: emptyRequest,
            type: DefinitionType.mutation,
          },
          endpointName: 'models',
        });
        // theoretical
        api.dispatch(cacheKeys.actions.addCacheKey(key));
        await api.cacheEntryRemoved;
        // also theoretical
        api.dispatch(cacheKeys.actions.removeCacheKey(key));
      },

This really feels like an abuse of the query cache system on a lot of levels but I:

• don't want to have to pass the original query arguments into the mutation just for this
• want to make sure any and all instances of the query that include the original model get optimistically updated by the mutation
• don't want to refetch by invalidating tags

What other options might I have here? It really feels like the "optimistic update" system suggested in the docs very quickly runs afoul of anything but the simplest, known-ahead-of-time queries.

[phryneas]

You've seen selectInvalidatedBy? https://redux-toolkit.js.org/rtk-query/api/created-api/api-slice-utils#selectinvalidatedby

[uraniumanchor]

Yes, I'm not using tags, so that doesn't address my issue. I don't want it to refetch anything. I should have clarified that in my initial post.

Edit: Though right next to it is selectCachedArgsForQuery which might be a lot closer to what I need.

[uraniumanchor]

I was under the impression that tags were mostly for triggering automated refetches when you know that something is invalidated by a mutation. So far none of the mutations I'm writing are complicated enough that I wouldn't rather just handle optimistically updating the cache myself, but if there's some other use case for tags that I'm misunderstanding, could you elaborate a little? Are you suggesting I use tags anyway in case I run across a case later that doesn't optimistically update, or something else?

I will say that after some experimentation, selectCachedArgsForQuery and then looping over them all does what I want. Not sure how I missed it before, but you the link above helped me find it, so thank you. I'm not sure how to mark a proper answer here since I ended up stumbling across it while reading the documentation for your prior suggestion.

[phryneas]

Tags are just markers to show what is inside a specific cache entry. We use them for invalidation, but you can slap them on pretty much everything for any reason you want - even if you just intend to call selectInvalidatedBy and not invalidate.

[markerikson]

@uraniumanchor for posterity / curiosity, what does your working solution actually look like?

[uraniumanchor]

Here's a simplified version of the function I'm using to update the cache, since the precise mutation will depend on which model I'm dealing with and the operation in question:

function stateMutation(newState: ModelState): TypedMutationOnQueryStarted<Model, number, EmptyBaseQuery> {
  return async (id: number, api) => {
    const patchResults: { undo: () => void }[] = [];
    const flatArgs = modelApi.util.selectCachedArgsForQuery(api.getState(), 'models');
    flatArgs.forEach(p => {
      patchResults.push(
        api.dispatch(
          modelApi.util.updateQueryData('models', p, draft => {
            const d = draft.find(m => m.id === id);
            if (d) {
              d.state = newState;
            }
          }),
        ),
      );
    });
    try {
      await api.queryFulfilled;
    } catch {
      patchResults.forEach(p => p.undo());
    }
  };
}

I then pass it into onQueryStarted like so:

createApi({
  // etc
  endpoints: build => ({
    // etc
    approveModel: build.mutation<Model, number>({
      // etc
      onQueryStarted: stateMutation('approve'),
    }),
  }),
});

I'm sure by the time I'm done it'll be more clean and generic, but that's my first pass at it.