How are simultaneous calls to useQuery handled?

[sbruinsje]

I have some questions about behaviour of simultaneous queries:

1. Lets say I have two components that use the hook useGetPeopleQuery() with the same query args. A mutation happens that invalidates the people resource. Will both of the components trigger a seperate request or will it only run once and the other is queued and thus will eventually be served the cached version once the first request finishes? I think this is the case but just want to confirm this.
2. Lets say I have only one component that uses the useGetPeopleQuery() hook and it triggers two requests with different query args in quick succession. Lets say the second triggered request finishes quicker than the first one, is the data property, once all requests are settled, guaranteed to hold the result of the last finished request or the result of the last triggered request? And what if you had 10 request, while request are finishing one by one, will the data property reflect those results while the rest is still in progress? And if so do those updates to the data property always correspond to the order in which they were triggered (e.g. at first data is the result of req nr. 1, then of req nr. 2, and so on)?

[markerikson]

1. Since both hook instances are relying on the same cache entry, they also share the same status for that cache entry. RTKQ will ensure there's only one request in progress for that cache entry.
2. data should always hold the results of the last successful request. currentData will always hold the results of the request based on the current query args.

[sbruinsje]

Thanks

I have to double check though that we mean the same thing with "last request".

Lets say I trigger 3 searches in quick succession:

1. "R"
2. "RT"
3. "RTK"
   The three requests will be running in parallel.

First request #2 succeeds and "data" corresponds to that. Then request #1 succeeds but "data" will still correspond to request #2. Then request #3 finishes and data will correspond to that.

Is this indeed how it works?

[markerikson]

I think so. To be honest the timing and internals of RTKQ are not well documented, which is a point that's bothered me for a while. Honestly I would experiment with this and see what happens :)

(And if you happen to have the time to add a couple unit tests to our codebase that validate those assumptions, that would really be appreciated!)

[phryneas]

R will resolve cache entry for R
RT will resolve cache entry for RT
RTK will resolve cache entry for RTK

meanwhile
the hook looks at the cache entry for R
the hook looks at the cache entry for RT. If the hook already had data from before switching to RT, it will keep that until new data for RT arrived
the hook looks at the cache entry for RTK. If the hook already had data from before switching to RTK, it will keep that until new data for RTK arrived

There's no real "concurrency" going on. Three different requests for three different cache entries, and a hook that only looks at one of them at a time, but might keep old results around.

[sbruinsje]

Ah perfect! That clears things up for me alot. Thanks