is it possible to define a API dependency?

[kahirokunn]

In RTK Query, is it possible to define a dependency such that API A is executed and then API B is executed?

[phryneas]

That would be https://rtk-query-docs.netlify.app/concepts/conditional-fetching

Essentially: useQuery2(..., {skip: query1.isLoading})

[kahirokunn]

Thx a lot! can I define that outside hooks? :eyes:

[msutkowski]

Thx a lot! can I define that outside hooks? 👀

Do you have an example or description of what you're trying to do? If you're not using hooks, you can manually dispatch things as shown in the svelte example - so implementing skip on your own is really simple. If you wanted to control the subscription behavior and rerendering like the skip option does, you can still do this in any framework with a little code.

[kahirokunn]

For example, when you call API A, you may want to call API B to record what parameters you passed to it or Dispatch some Action.

For example, you may want to save what was searched in the session storage.

It may be easy to support this with your own custom hooks instead of RTK Query, but this may lead to omissions in future modifications and extensions, and some teams may not share information enough and use hooks generated from RTK Query instead of the custom hooks they created.

You can define the relationship between APIs using the createApi function in RTK Query, or functions such as defineApiDependencies, which is not currently available.

defineApiDependencies(createApi({...}), {...})

I thought it would be great if we could define them like this.

Maybe we want to be able to use the same code for this kind of behavior in multiple frameworks.

[kahirokunn]

For example, if you successfully POST to /posts, you may want to GET to /posts again. This can also be achieved with useEffect, but it would be great if it could be achieved with a core part or something that is highly portable, what do you think?

[msutkowski]

@kahirokunn You can do this already with entity invalidation. It won't work across multiple API instances, but for your given example, that is handled.

If you really wanted this behavior between different APIs, you could do this in the onSuccess of a mutation, and dispatch an action with forceRefetch to a separate API.

const api = createApi({
  baseQuery,
  endpoints: (build) => ({
    updatePost: build.mutation({
      query: ({ id, ...body}) => ({ url: `post/${id}`, method: 'PATCH', body }),
      onSuccess({ id }, { dispatch}, result) {
          dispatch(otherApi.endpoints.getThings.initiate(arg, { forceRefetch: true}))
       }, 
      invalidates: ['Post'],
    }),
  }),
});

[kahirokunn]

I'm sorry, I've seen this document before, but I wasn't sure about the invalidation.

But I'm interested in that feature.

Is invalidates a common feature?

Why is it called invalidates, and what does it do?

Are there any similar features in other ecosystems such as Apollo?

[phryneas]

It's essentially the cache invalidation mechanism of urql, taken one step further: https://formidable.com/open-source/urql/docs/basics/document-caching/

I'm explaining it a bit further in these youtube videos: https://www.youtube.com/watch?v=OCcGvg2I5E8 and https://www.youtube.com/watch?v=Iul-hHJtCQ8&t=31s

[kahirokunn]

Thank you!

I've probably figured out provides/invalidates. There is a query cache key, which can provide multiple identifiers from a particular query, and the relevance is as follows

When a change is made to this identifier, the provider of the query cache key reacts and dispatches the query again.

So, just by specifying the identifier provides by the providers in the invalidates, the query will be dispatched again.

The flows and relationships are as follows.

Is this understanding correct?

I'm sorry that I'm only asking a lot.

[kahirokunn]

I want to use onStart at the build.query. How about this one? 👀 https://github.com/rtk-incubator/rtk-query/pull/130

[phryneas]

@kahirokunn yup, that's essentially how it works, with the little detail that the "provides" keys are not really cache keys (the name of your endpoint & the argument you pass in are the cache keys), but just some extra thing that's just there to identify what should be re-fetched.

[kahirokunn]

I see. Thank you!