useDerivedRTKQuery as createSelector counterpart

[bartosz-k]

I'm using RTK with msw to mock responses in tests suite. Everything works well until there's a selector in some component trying to select data from redux store before there was a query made which was not mocked yet.
It's very brittle and unergonomic to manually force query to be made before test is run so the selector used already filled in data.
So far there was used jest test runner with mocks for selectors which I'd like to avoid and go with msw exclusively.
Selectors are actually a derived queries in my view, selectors depend on some previous state which should be established beforehand. That's why I think createDerivedRTKQuery helper would be desirable, see an example:

const useProductNames = createDerivedRTKQuery(
   useCategoriesQuery,
   useProductsQuery,
   (categories, products) => (...some logic here))

// in component
function Products(){
   const {data} = useProductNames(/** optionally pass array of arguments for each of the subqueries **/);
   console.log(data) // result based on logic above
}

Implementation of createDerivedRTKQuery is quite simple, it's basically running hooks in the for loop with applied arguments and conforming to type of query so hooks created with createDerivedRTKQuery can be deeply composed. Running hooks in for loop is totally safe assuming there is constant number of iterations - we have it here.

Is this idea well grouned, do you suggest other solutions instead?

[phryneas]

Why not write a custom hook with two useQuery calls and selectFromResult?

[bartosz-k]

Why not write a custom hook with two useQuery calls and selectFromResult?

Of course that's first naive (=easy) approach which I've already implemented.
But at scale and long term it doesn't cut because it doesn't solve composability problem with proper errors propagation, resolving strategy (all, all settled etc) and fetching state. Query-of-query is unavoidable requirement once your app grows. Even SQL allows to create subqueries, not mention languages like Prolog, LogiQL.

[phryneas]

Even SQL allows to create subqueries, not mention languages like Prolog, LogiQL.

These languages are languages for data processing and a lot closer to the underlying data, though. RTK Query is a document fetching library and doesn't care about data structure at all.

We'd have to deal with too many completely different servers, api structures and response formats for it to find an "easy, common" way of doing that.

I think providing something that would work for a single project, but finding a way of doing that that worked for 80-90% of APIs out there would be a herulean effort - especially when adding good TypeScript support on top.
I think it might be easier here that you write those helpers geared towards your own project. It might prove to be less userland code than having us implement such a tool, because for it to work "everywhere", you'd probably write more code on top of it than doing a targeted solution from the start.