We *could* pass queries as context

[craigmulligan]

Had an idea, to make things potentially more modular and easy to use.

Currently the page component is responsible for querying the graphql data and passing those props to the child components.
However, we could require the queries which would make them ejectable.

Though that alone isn't helpful as you still need to pass the new query results to child components, so we could pass all queries data as context (context is passed to all child components). This would allow users to just eject the query and the component and not the page, and have vastly different data sent in their child components without having to eject the page.

Down side is that context is not very popular and maybe not a best practice?

[KyleAMathews]

So this isn't documented yet particularly but Gatsby uses the "Modern Relay" compiler which means we inherit their query composition model as well.

Basically components (not page ones) can declare query fragments into a global namespace which then other queries can include.

So Page A has components A1, A2, and A3, each with their own fragments. If a user ejects A3 and modifies the query, those modifications are automatically included in Page A's query and the resulting data is passed to the ejected A3. Pretty neat eh!

An example from Gatsbygram, the Avatar component query (https:/gatsbyjs/gatsby/blob/1.0/examples/gatsbygram/src/components/Avatar.js#L43) is spread into https:/gatsbyjs/gatsby/blob/1.0/examples/gatsbygram/src/pages/index.js#L205

[craigmulligan]

Woah that's awesome! It gives you so much control on from the component level. Super excited to try it.

[craigmulligan]

Hey @KyleAMathews, I tried this out but I'm not having much luck, I basically just get Relay cannot find fragment Entry_details. Please make sure the fragment exists in Entry`` which makes me think the child components queries aren't getting export? Or I have made a elementary graphql mistake, can you see anything out of place? - #27

[craigmulligan]

Side note: These pages are created by a plugin and are not required from src/pages which may have some effect?

[KyleAMathews]

These pages are created by a plugin and are not required from src/pages which may have some effect?

Hmmm that's exactly the problem. Right now the relay compiler scans for grapqhl queries and fragments for all js files in "src" as well as any page component. But non-page components like "ChangelogEntry", it has no way of knowing that it's there atm.

Hmmm this is tricky. We don't want to just scan node_modules cause it's huge. Perhaps npm Gatsby components could declare their components so our relay compiler implementation can add them to the scan list.

They'd also need to ship an es6 version so the template literals aren't compiled away.

[craigmulligan]

That sounds like the good approach, would that be apart of the bound-action-creators api? Perhaps we should move this to an issue on gatsby and see if anyone has any other ideas.

[KyleAMathews]

No I think it'd make the most sense to put this in their package.json. E.g. in a gatsby key.

Then at startup, Gatsby could scan the package.json of each dependency to see if it has a gatsby key and if it does, if it declares any components, and if so, add those component(s) to the list of files Relay Compiler scans.

[KyleAMathews]

But yeah, please create an issue on Gatsby and let's discuss some more options there. I have several generic Gatsby components in mind so this would be good to sort out.