Summary
This should auto-attach extracted fragments to queries in graphiql:
- in
gatsby - we should push query from graphiql editor through relay-compiler to automatically attach fragments
- in
codemirror-graphql (set of graphql related extensions to codemirror editor that is used in graphiql) should transform query and attach fragments, so hints (autocomplete) and lint (red underline on unknown identifiers) make use of gatsby fragments - I opened issue in codemirror-graphql that would add support for this - https://github.com/graphql/codemirror-graphql/issues/260 , which would be nicest way forward, but if this won't be accepted we can fork it to add this feature
- (nice to have, but not necessary) adjust
graphql-language-service-interface to show fragment spread earlier so they can be discovered much easier ( https://github.com/graphql/graphql-language-service/issues/358 )
Basic example
I've made proof of concept that involved lot of monkey patching with very nice result:
(see code changes master...pieh:graphiql-explorer-fragments )
This would need to be cleaned up, ideally changes applied in upstream packages if possible, to reduce hackiness needed to implement this in Gatsby GraphiQL editor
Motivation
This is common pain point, that queries that work in page/static queries that use fragments don't work in graphiql. Goal here is to widen support for fragments and lower friction.
Summary
This should auto-attach extracted fragments to queries in graphiql:
gatsby- we should push query from graphiql editor through relay-compiler to automatically attach fragmentscodemirror-graphql(set of graphql related extensions tocodemirroreditor that is used ingraphiql) should transform query and attach fragments, so hints (autocomplete) and lint (red underline on unknown identifiers) make use of gatsby fragments - I opened issue incodemirror-graphqlthat would add support for this - https://github.com/graphql/codemirror-graphql/issues/260 , which would be nicest way forward, but if this won't be accepted we can fork it to add this featuregraphql-language-service-interfaceto show fragment spread earlier so they can be discovered much easier ( https://github.com/graphql/graphql-language-service/issues/358 )Basic example
I've made proof of concept that involved lot of monkey patching with very nice result:
(see code changes master...pieh:graphiql-explorer-fragments )
This would need to be cleaned up, ideally changes applied in upstream packages if possible, to reduce hackiness needed to implement this in Gatsby GraphiQL editor
Motivation
This is common pain point, that queries that work in page/static queries that use fragments don't work in graphiql. Goal here is to widen support for fragments and lower friction.