rtkQuery lifecycle hook to invalidate cache from side-effects

[schadenn]

Hi everyone,

I am currently experiencing a use-case that seems like it is not treated at all at the moment:
I have a query that may have its results invalidated by a side effect that is not within my control (as in: I can't call the invalidate function when the side effect happens).
Now I'm thinking it would be great to have something like a onQueryInitiated lifecycle event which will be triggered before the reject action would be triggered and therefore provide an integration point to check if the mentioned side effects happened in the meantime and if yes - call the invalidateTags function.

At the moment the only way to do this would be to wrap the autogenerated hook, which feels a little cumbersome.

Wdyt? I'd try implementing this if it is considered to be a good idea.

[markerikson]

Sorry, not sure I'm following the described scenario here. Can you give some concrete examples, and maybe show what the imaginary code for this feature might look like?

[schadenn]

Okay so let's say you're working on a big application together with some other teams. You're managing a section that shows blog posts and there is another team that owns an admin section somewhere else. You're able to edit blog posts from the admin section.
You wouldn't really want to export your invalidateTags functionality for the other team to use, because it's not their scope/functionality and will cause dependencies.
So what you'd maybe want to do instead would be:

createApi({
  [...],
  endpoints: {
    getPosts: build.query<any,any>({
      query: ...something/getPosts...,
      providesTags: ['Posts'],
      async onQueryInitiated(...args) {
        // this will trigger before onQueryStarted
        if (await adminSection.hasChangedPosts()) {
          blogStore.invalidatesTags(['Posts']) // invalidate this endpoints cache
        }
      }
    })
  }
})

Now you have the same dependency the other way around, but it might make more sense for the admin section to export their checkers, then to maintain a list of callbacks to trigger in case the changes happen.
Imo invalidating before rejecting would be something valuable to support.

[markerikson]

Hmm. Is the https://redux-toolkit.js.org/rtk-query/api/createApi#onquerystarted basically what you're looking for, or is there some difference in behavior / timing from that function?

[schadenn]

onQueryStarted will only trigger whenever the actual backend query would be triggered. So if there is a cached result already, that function won't be triggered at all.
The intention of my proposed functionality would be to have an integration point before rtkQuery makes the decision if the api/executeQuery/rejected action will be dispatched. Tbh I'm not sure if triggering invalidateTags at that time would cause any issues in the usual redux action flow. But maybe there are other ways to force rtkQuery to do the request instead of rejecting it.