feat(gatsby-graphiql-explorer): add support for magic fragments #28878
Conversation
gatsbot
bot
added
the
status: triage needed
| @@ -193,6 +193,15 @@ module.exports = { | |||
| } else { | |||
| graphiqlExplorer(app, { | |||
| graphqlEndpoint, | |||
| getFragments: function getFragments(): Array<FragmentDefinitionNode> { | |||
pieh
removed
the
status: triage needed
pieh
force-pushed
the
graphiql-fragments
branch
from
4458a0b
to
eecc2e6
Compare
|
awesome work! @pieh i was going to offer to keep going with this since I’ve been cleared to keep improving gatsby graphiql as I wrap up here, would that be helpful? seems like this PR is almost finished anyways! |
I just pushed what I think is required change to get this in (bump for I checked and graphiql in IE11 currently doesn't work anyway, so I'm not breaking it anymore than it already is |
|
yes, we dropped IE support in late 2019. it may be that codemirror has as well. hot updates should work using subscriptions if we supply the prop, but we may need some lifecycle tweaks |
|
One thing to consider is adding test case for magic fragments in https://github.com/gatsbyjs/gatsby/blob/master/e2e-tests/development-runtime/cypress/integration/functionality/graphql-endpoint.js - not sure if we can easily test if |
|
yes we just need to test whether the prop gets passed. we already have plenty of tests in place for these new validation and completion features related to this |
Our graphql server doesn't have subscriptions, so it would need some setup to go through it, but we can likely do something that need less lift to let our graphiql app know that it needs to refetch fragments (that's not the most performant thing ... but also not sure if it makes much sense to optimise for fragment hot reloading when it comes to time effort needed to pull it off) And lastly - I'm not sure if we need to support hot fragment updates - at least for this PR - I just wanted to mention that it's not supported to not cause confussion (be explicit about what is supported with this PR) |
|
oh yes of course. I would expect by the end of this PR, users would need to refresh to see updated plugin fragments after, say, adding or removing a plugin, or defining your own. |
There was a problem hiding this comment.
tested locally and thoroughly, and everything looks great to ship here! It all appears to work just fine as expected. Just reviewing this PR gave me a few takeaways to improve GraphiQL and Explorer!
only thing is maybe mention it in the gatsby-graphiql-explorer readme? oh and I should notify docs team as well!
acao
force-pushed
the
graphiql-fragments
branch
from
7cce615
to
2fb29b7
Compare
acao
force-pushed
the
graphiql-fragments
branch
from
2fb29b7
to
30c4eba
Compare
…han existing test
Description
This is initial integration for upcoming
graphiqlfeature where we can register fragments and they will be available in graphiql ( graphql/graphiql#1750 ). This feature was recently released, so we are able to bump it soon.All the kudos go to @acao for the work they already did on adding support for it and helping hand when working on adding support for it in gatsby
And here's sneak peek:
