RTK Query sustain `isLoading` for auto-refetching after cache invalidation

Question

Having a hard time finding a good answer/ solution for this problem.

I have a POSTS list component that allows to delete individual POST rows.

I'm using a run of the mill queryMutation for deletion purposes:

IMPLEMENTATION

deletePostById: build.mutation<{ success: boolean; id: number }, number>({
  query(id) {
    return {
      url: `post/${id}`,
      method: 'DELETE',
    }
  },
  invalidatesTags: (result, error, id) => [{ type: 'Posts', id }],
})

USAGE

  const [deletePost, { isLoading: isDeleting, error: deletionError }] = useDeletePostByIdMutation();

PROBLEM DESCRIPTION
Within the list component the individual row has an icon to delete that Post - while isDeleting I'm showing a spinner, which is also showing just fine - however, when the Post is deleted the auto-refetching of RTKQ kicks in to get the now updated Posts from the server - isDeleting is no longer true though. This leaves a small time window in which the Post row is not showing any spinner but also is not removed yet from the Posts list.

Once the refetched data of all Posts has successfully returned the deleted Post row gets removed from the list.

How can I sustain the spinner animation from deleting the individual Post till the removal after the automatic refetching of RTKQ has finished?

Thanks

Matheny

Answer 1

You can use isFetching on the list query instead of isLoading, which is only true for the initial request, not refetches.

Highkey

hmm, sorry, maybe I didn't word it correctly (or I don't understand your reply 😅) It's not about the isLoading (or isFetching) of the list per se. I just want to piggy back on the fact, that the list is loading and hitch the isFetching of the deleteQuery on it to sustain the linked animation when deleting that row. can I keep isFetching of the deleteQuery true based on the lists isFetching query? that's what I meant with sustaining. Thanks – Matheny

the fetching of the list happens after the mutation is finished and it's just a side effect - they are not related to each other. all you can do is look at isFetching of the list itself. – Highkey

oh, ok then - I guess I thought I could use something like skipToken - I guess that does only work for actively initiating the calls myself? Thanks for the replies 🙇🏽‍♂️ – Matheny

that would lock you out of accessing any result - I don't really see how that would be useful here? – Highkey

I'm having the same problem i.e. I'd like to keep the UI feedback till the re-fetch is done. I'm struggling in getting the responses here. Using the isFetching helps in not have the spinner for the whole list but does not help in having the spinner for the single row I'm deleting till the delete is done. @Highkey did I misunderstood your answer ? – Matthews

It isn't useful to brush this problem off with "cache refetches are just a side effect". There are many legitimate reasons why you'd want to show a contextual busy indicator until the operation has completed and the UI has updated to indicate. Deleting an item from a list is a good one. The answer given doesn't really fit the problem at all. – Tweed

@Tweed it is not brushing it off, it is a technical statement here. It happens technically as a side effect in a different part of the code base, and there is no way to trace a loading statement to a mutation or the other way round. It starts, as a side effect from a Redux middleware, after the original mutation has already finished and cannot be traced back to the mutation. Source: I wrote that "side effect" code. – Highkey