RTKQ: Mass rejected queries

I’ve noticed many rejected queries in console log

action api/executeQuery/rejected
[Log]  action     – {type: "api/executeQuery/rejected", payload: undefined, meta: Object, …} (main.js, line 136707)
{type: "api/executeQuery/rejected", payload: undefined, meta: Object, error: {name: "ConditionError", message: "Aborted due to condition callback returning false."}}Object

Since I cannot use selectors with RTK Query(#1182) I subscribe each small component to same query with selectFromResult option to retrieve my data slice. To be more specific I load all job applications with one query(GET /applications?campaignId=123) then I have long datatable with each application as a row. Each row contains few micro forms eg. candidate name to enter name and push enter to post data. So each microform subscribed to the same GET /applications?campaignId=123 request then it finds application by id and reads one field(name) from searched application item. Because of it I see 1400 rejected requests in console and everything becomes unresponsive. I think even if I turn logger off it still gonna overload redux state with thousands of dispatched actions.

Seems like I need to find another way to select data from API queries or pass query results from root element to child over and over again.

Could it be a bottleneck if I subscribe each list item to query hook?

[markerikson]

Both are true.

It’s true that every line of code that runs, including adding a useSelector call, has a cost. Having 1500 subscribers is more expensive than having 10 subscribers, in that there’s now 1500 functions that will run after every dispatch. (Which is why we encourage selectors to be as fast as possible.)

But it’s also true that having more components connected, at lower portions in the tree, generally results in fewer React components re-rendering per UI update. And in general, the cost of re-rendering N React components is more expensive than the cost of having N store subscriber functions.

So, there is no one single answer, but as a general rule, more connected components results in less total re-rendering cost overall.

All that said: part of the issue here seems to be with how RTK Query manages finding cached state and dispatching that “rejected” action. I’m sure Lenz had a good reason for doing that, but tbh I’m not sure that’s really what we want to have happening, and it may be worth rethinking how we handle that.

[phryneas]

They are not “internal”, just not super-exposed 😃 We do not expose those not-so-often-used hooks on the api object itself, but just on api.endpoints.endpointName to not totally clutter the api object with hooks.

As for the TS: yeah, it’s a tradeoff. I think we show it in the svelte example, but we could add it there somewhere…