Set automated invalidation in the mutation definition, but skip the invalidation for the focused query

[talatkuyuk]

I have a page that shows the Authusers in a list. RTK Query provides the data with the endpoint "getAuthusers". Each row in the table represents the record (Authuser). The page has filter form that can request the data coming from the API, using field filters and pagination (pageIndex, pageSize, pageCount) etc. So, the RTK Query caches all the queries result with the filtered arguments. So far so good.

type Authuser = {
  id: string;
  email: string;
  isEmailVerified: boolean;
  isDisabled: boolean;
  createdAt: Date;
};

I implement a user interface that each Authuser row has checkboxes for the fields isDisabled and isEmailVerified. The checkboex represents the data accordingly, checked or not. Whenever the user clicks a checkbox, an API request goes to server and update the data in the database (simply toggles the field data as true to false; or false to true), return only {success: true} response. It uses a RTK Query mutation for that process.

Now, I have two options
1. Use Automated Re-fetching with the tags: This cause that related query caches are invalidated and re-fetched. It is the most simplest approach. I implement this, and works perfectly, but cause less User Experience since even I change a small piece of data, the existing query is triggered and the whole page is refreshing.

2. The second approach is the optimistic/pessimistic update: I chose the pessimistic approach. Because I am pessimistic man :) I implemented it using onQueryStarted and updateQueryData. It worked good, but I realized that, especially for the pages having a filter form and data coming from the server with filtered and paginated, you almost never know which query cashes are effected by the mutation. Even if you use selectInvalidatedBy, it is so error-prone because you have to update the record (Authuser) in some query caches, or you have to delete the record in some query caches, or you have to add it into some query caches; and think that the query caches have different arguments, filter fields, pagination and different sorting arguments. It is almost impossible how to decide in which order you add the data for example. As a result, the optimistic/pessimistic update could be so error-prone especially for the pages having a data table with a server-side filter form.

At this point, I would like to say:

Hey RTK Query, make automatic invalidation for the queries when the mutation occurs. Invalidate all the queries according to provided tag list, but do not do for the focused query.Because I am going to deal with the focused query for myself
. Because I exactly know what to do in the current user interface related the focused query. But for the other queries invalidated, you do, because I don't want to implement optimistic/pessimistic update for the other queries, since I realized that the implementation may include so error-prone logic.

Here is my implementation for the pessimistic cache update for the focused query:

    toggleDisabilityAuthuser: builder.mutation<boolean, string>({
      query: (id) => ({
        url: `/authusers/${id}`,
        method: "PUT",
      }),
      invalidatesTags: cacher.cacheByIdArg("Authuser"),
      transformResponse: (result: { success: true }) => result.success,
      async onQueryStarted(arg, { dispatch, queryFulfilled, getState }) {
        // pesimistic cache update
        try {
          const { data: success } = await queryFulfilled;

          if (success) {
            // first find the focused query's cache key
            let focusedQueryCacheKey: string = "";
            const subscriptions = getState().api.subscriptions;

            Object.entries(subscriptions).forEach(
              ([queryCacheKey, content]) => {
                if (Object.keys(content as Object).length) {
                  focusedQueryCacheKey = queryCacheKey;
                }
              }
            );

            // get the focused query
            const queries = getState().api.queries;
            const focusedQuery = queries[focusedQueryCacheKey];

            //  mutate the cache of the focused query
            if (focusedQuery && focusedQuery.status === "fulfilled") {
              console.log(`in FocusedQuery: ${focusedQueryCacheKey}`);
              const { endpointName, originalArgs } = focusedQuery;

              if (endpointName === "getAuthuser") {
                dispatch(
                  authusersApi.util.updateQueryData(
                    endpointName,
                    originalArgs as string,
                    (draft) => {
                      if (draft.id === arg) {
                        draft.isDisabled = !draft.isDisabled;
                      }

                      return draft;
                    }
                  )
                );
              }

              if (endpointName === "getAuthusers") {
                dispatch(
                  authusersApi.util.updateQueryData(
                    endpointName,
                    originalArgs as GetAuthusersQueryParams,
                    (draft) => {
                      // first, find the authuser in the cache
                      const authuser = draft.data.find(
                        (authuser) => authuser.id === arg
                      );

                      if (authuser) {
                        console.log(`found authuser: ${authuser.id}`);

                        // if original arguments does not include isDisabled key, go ahead
                        if (
                          (originalArgs as GetAuthusersQueryParams)
                            .isDisabled === undefined
                        ) {
                          console.log("not include isDisable key");
                          authuser.isDisabled = !authuser.isDisabled;
                        }

                        // if arguments include isDisabled key; and isDisabled keys are the same, then delete the record
                        // why? the mutation changes the Authuser isDisabled field which requires not to be in the this query cache
                        else if (
                          Boolean(
                            (originalArgs as GetAuthusersQueryParams).isDisabled
                          ) === authuser.isDisabled
                        ) {
                          const index = draft.data.findIndex(
                            (authuser) => authuser.id === arg
                          );

                          if (index >= 0) {
                            // delete the record in the array
                            draft.data.splice(index, 1);
                          }
                        }

                        return draft;
                      }
                    }
                  )
                );
              }
            }

            // if I want to update the other query caches here is my implementation as well, but it is so error-prone
            // you can omit the code below !
            const invalidatedQueries = authusersApi.util.selectInvalidatedBy(
              getState(),
              [{ type: "Authuser", id: arg }]
            );

            for (const query of invalidatedQueries) {
              const { endpointName, originalArgs, queryCacheKey } = query;

              if (queryCacheKey !== focusedQueryCacheKey) {
                dispatch(
                  authusersApi.util.updateQueryData(
                    endpointName as "getAuthuser" | "getAuthusers",
                    originalArgs,
                    (draft) => {
                      // means getAuthuser
                      if ("id" in draft) {
                        draft.isDisabled = !draft.isDisabled;

                        return draft;
                      }

                      // means getAuthusers
                      if ("data" in draft) {
                          // I omitted this part since it does not matter for this discussion
                        return draft;
                      }
                    }
                  )
                );
              }
            }
          }
        } catch {}
      },
    }),

For conclusion, what I would like to do: I would like to provide both invalidatesTags (for automated re-fetching) and onQueryStarted (for the focused query) at the same time, requesting from RTK Query to not do re-fetching for the focused query and skip this.

My suggestion would be like below.

• RTK Query knows always what the latest focused query is.
• I want to add automated invalidation for the mutation, for sure !
• In the definition of the mutation endpoint, I would like to add an option (optional) for the skip automated invalidation for the focused query.

    toggleDisabilityAuthuser: builder.mutation<boolean, string>({
      query: (id) => ({
        url: `/authusers/${id}`,
        method: "PUT",
      }),
      invalidatesTags: cacher.cacheByIdArg("Authuser"),  <-----------------------  I would like to keep it!
      skipAutomatedInvalidationForFocusedQuery: true;   <-----------------------  additional option (optional)
      transformResponse: (result: { success: true }) => result.success,
      async onQueryStarted(arg, { dispatch, queryFulfilled, getState }) {
         // manual cache update implementation ...  <-----------------------  for the focused query (I will deal with myself)
      }

I suppose, the use case is so suitable for all the developers. All of us may encounter the use case that I've tried to explain above.

Is there any developer has a work-around for the use case?

[phryneas]

In short, I guess the answer for now would be a "no", just because adding something such as this is a lot of extra code and logic and I don't think the use case is actually as common.

Instead, honestly, I would focus on this part:

the whole page is refreshing

And here I have to ask: why is the whole page refreshing? Usually something like a refetch would happen pretty "unnoticed by the user" - are you intentionally making it very visible to the user due to some reason?

[talatkuyuk]

While I say the whole page is refreshing, I would mean the data table / data list is refreshing.

are you intentionally making it very visible to the user due to some reason?

Yes. There is a progress bar and text indicator that tells the user the new data is coming from the server. When the user clicks to any pagination button; or search button for the new filtered query, these indicators are being shown to the user; and stop when the new data is provided by the RTK Query. This indicators are also being shown when the existing cache is invalidated and the same query is triggered by the RTK Query.

<ProgressBar
    id="progress-bar"
    show={responseGetAuthusers.isFetching}
/>

I don't think the use case is actually as common.

Actually it is very common. Think about the favorite button for the menu; favorite button for the tweet; pin button for the product; like button for the song; upvote/downvote for the comment; disable/enable checkbox for the user etc. in a list / data table of menus, tweets, products, songs, comments, users etc..

The problem is that when you update only a field of a record in the list / table by clicking an icon-button or a checkbox, this mutation requires existing query is being re-fetched when we use automated invalidation, either you show the progress indicators to the users or not; this eventually occurs.

If you use manual cache update the user can see the changes (in the data table, or in the list) immediately, otherwise the user can see the changes after re-fetching. When you use automated invalidation and additionally if you do not show the progress indicators; the users can see the changes after a while (after re-fetching) suddenly, which may cause less user experience. That is the reason I prefer to use progress indicators.

In order to prevent the whole list / table is being re-fetched as a result of a piece of data is updated, updating the cache manually, optimistic/pessimistic update comes into play. But, as I tried to explain in my previous comment; the optimistic/pessimistic update could have error-prone logic especially for the pages having a data table / data list, which consists like button, favorite button, upvote button, clamp button, pin button etc for each record; and having a server-side filter form, (sorting, filtering and pagination parameters for the server-side query). That is why I want to keep invalidatesTags for the mutation endpoint, but skip automatic invalidation for the last-focused query only.

I guess the answer for now would be a "no", just because adding something such as this is a lot of extra code and logic

Yes, it may require a lot of extra code and logic. You are the author and you know better than us. But I think that the requested feature is so powerful for the common use cases, and is going to give a better experience for the developers who use the RTK Query package.

Thank you for the quick response.

[realsami]

We have a similar situation as explained by @talatkuyuk . Our use case is that we have a query which pulls data to display in a Grid. Inside the grid we have a star/unstar button. On pressing Star, the mutation is fired which also invalidates the tag, hence the original get query also fires up and users see loading spinner and page refresh, which we don't want.

As we are using RTK query auto generated code from our swagger, and our queries are auto generated, we don't want to manually change it every time.

Our workaround was to opt out of that particular query and override it like:

In generated code:

getBusinessUnits: build.query<GetBusinessUnitsApiResponse, GetBusinessUnitsApiArg>({
       query: (queryArg) => ({
         url: `/audit-universe/business-units`,
         params: { 'sort-by': queryArg['sort-by'], 'sort-direction': queryArg['sort-direction'] },
       }),
       providesTags: ['business units'],
}),

Override it in another file: (Just remove providesTags)

getBusinessUnits: build.query<GetBusinessUnitsApiResponse, GetBusinessUnitsApiArg>({
        query: (queryArg) => ({
          url: `/audit-universe/business-units`,
          params: { 'sort-by': queryArg['sort-by'], 'sort-direction': queryArg['sort-direction'] },
        }),
}),

Its not at all ideal, as we have to copy paste the query and remove providesTags, (we can remove it from swagger also, but it will not trigger in all cases)

Definitely this feature is required and having a flag to opt out of providesTag, something like:

useGetBusinessUnitQuery({ 'sort-by': 1 }, { skipTag: true })

and same for Mutations