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

score 3 · Accepted Answer · answered May 31 '22 at 10:58

3

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

answered May 31 '22 at 10:58

phry

35,762
5
67
81

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 – flaky May 31 '22 at 12:30
2

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. – phry May 31 '22 at 16:26
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 ‍♂️ – flaky Jun 01 '22 at 07:45
1

that would lock you out of accessing any result - I don't really see how that would be useful here? – phry Jun 01 '22 at 07:53
4

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. @phry did I misunderstood your answer ? – lucataglia Aug 31 '22 at 21:08
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. – nizmow May 01 '23 at 03:30
@nizmow 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. – phry May 01 '23 at 06:59

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

1 Answers1

Linked