Make SSR hydration work with 2nd level nested queries

[LiamMartens]

Is it possible to make the SSR cache hydration work with "nested' usage of useQuery?

For demonstration purposes of the "issue" I created a repo

When running the project as is - the list of launches will be pre-rendered making use of the cache, but the launch site info will appear delayed because the data will be fetched from the API on the client side. However when you comment in the lines here the launchpad cache does get populated and thus the data is immediately available.

I'm not sure if this would even be possible in the current state of gqty - but I am hopeful 😊

[PabloSzx]

I agree that only doing a single pass for GQty in SSR limits, but just as I mentioned in #276, it's not the best in GQty usage putting data requirements behind conditionals, the example can be easily fixed pre-doing the expected data requirements, there are helpers like "prepass" that make it easier to do it https://gqty.dev/docs/client/helper-functions#prepass.

Something to mention is that what you mention as "second-level nested queries", in client-side also divides the query into 2 different queries, which makes the website "cascade" and make 2+ different queries when all the queries could've been a single network request to the API

[LiamMartens]

@PabloSzx I definitely understand your points (I actually tried to pass the query down to deeper nested components). I do see a use case for having the data be more individually composable on component level as it would be much easier to detach the responsibilities of data from the top level. An example of this would be using this to fetch data from a headless CMS with custom blocks. At the page level we don't know what data will be required by the blocks so it forces the loading of all data beforehand regardless of the actual content.

Just some thoughts

[theodesp]

@PabloSzx I definitely understand your points (I actually tried to pass the query down to deeper nested components). I do see a use case for having the data be more individually composable on component level as it would be much easier to detach the responsibilities of data from the top level. An example of this would be using this to fetch data from a headless CMS with custom blocks. At the page level we don't know what data will be required by the blocks so it forces the loading of all data beforehand regardless of the actual content.

Just some thoughts

See #558. The listed repo contains this exact use case. However it suffers from a bug currently.