[2.1 beta]: Query enhancement request

[serle]

I would like to be able to pass multiple named queries to the query component as opposed to just one and get back multiple result objects for use in my render function. I would like the array of queries to be batched and for the query component to render only once all the queries have returned.

[kandros]

Isn’t a composition of HOCs more appropriate for this usecase?

[rosskevin]

The goal is for Query to be singular in purpose. As @kandros said, there are multiple ways to compose queries.

For the purposes of batching, you might consider batching with apollo-link: https://github.com/apollographql/apollo-link/tree/master/packages/apollo-link-batch-http

[serle]

I find the Query component is far clearer than using the HOC approach. I don't have a strong opinion on the singular nature of the Query component, only that my use-case requires multiple queries to return successfully before I start to render. This requires some sort of execute queries in parallel component.

It would be even better to think in terms of query chaining of both parallel query pipelines and serial query pipelines where a serial query pipeline occurs when the result data from one query is used as a parameter to the next query in the chain. Composing parallel and serial query chains with a secondary loading and error render props would clarify a lot of my code. i.e. let the child render prop render the success case and relegate the common loading and error rendering to two alternate props.

[kandros]

Don’t get me wrong but this looks like what graphql is trying to avoid in the first place.

[serle]

Yes one could say make a special complex API for the parallel query case, but in some of my cases the data being called is independent fact data.

An example is when we have a UI to capture a three way relationship between independent fact entities. Here one could have three select fields rendered by the component each consuming one of the query result. It makes sense to only start rendering when all 3 queries return and all the option data is available to capture the relationship.

The other design would be to create one composite API call for all the options but then the schema gets bloated very quickly with very specific UI cases. I'd rather take advantage of Apollo normalization and the ability to batch multiple Queries.