GraphQL support

[pvolok]

This is an issue to track the GraphQL support that I'm working on. The purpose of this feature is to bridge GraphQL and Flow type systems.

• Validation
  • Types/fields/selections correctness First step towards GraphQL support #2822
  • Field arguments [WIP] GraphQL #2: GraphqlData, GraphqlVars, args/vars validaton #3051
  • Merge fields
  • Variables [WIP] GraphQL #2: GraphqlData, GraphqlVars, args/vars validaton #3051
  • Directives
• $GraphqlData annotation for extracting query/fragment data [WIP] GraphQL #2: GraphqlData, GraphqlVars, args/vars validaton #3051
• $GraphqlVars annotation for extracting query/fragment variables [WIP] GraphQL #2: GraphqlData, GraphqlVars, args/vars validaton #3051
• Fragment resolving
• Fragment references (fragments for child components in Relay)
• Fragments unifying (what happens when 2+ fragments flow into one variable?)
• Autocomplete
  • Fields First step towards GraphQL support #2822
  • Arg names
  • Type names on fragment types
• Directives (@if, @skip, @relay(plural: true))

Goals

• Validate queries/fragments
• Infer object shapes from queries
• Validate variables supplied to the queries
• Bring GraphiQL into the editor
  • Autocomplete
  • Query validation
• Type-at-pos for queries and fragments constituents

Ideas

Just ideas of what such tool might do.

• Selected but unused fields

PRs

• First step towards GraphQL support #2822 — schema loading and basic validations.
• [WIP] GraphQL #2: GraphqlData, GraphqlVars, args/vars validaton #3051 — GraphqlData and GraphqlVars annotations, field args and variables validation.

[vkurchatkin]

Related issue: #722

[sibelius]

any progress on this?

[pvolok]

@sibelius Actually, the review hasn't started yet. And when it starts, a lot of work will have to be done to have this feature merged. And it's a low priority task for the Flow team afaik.

So I would not expect this feature to land any time soon.

[bstro]

this sounds like a pretty awesome idea. is there a reason why this isn't awesome?

[ivawzh]

this sounds like a pretty awesome idea. is there a reason why this isn't awesome? +1

[bgw]

As a heads up: If you need something like this today, I'd recommend checking out apollo-codegen or the relay compiler.

You can also write your own codegen tailored to your project's use-cases (which I've done). You can write a simple schema-only compiler (that ignores queries) in < 300 LOC using graphql.js, babel-types, and babel-generator. You can write a codegen that analyzes queries as well to support things like field aliases in a few thousand LOC, depending on the quality of the types you want to generate, and the size of the generated code you're willing to put up with.

That's not to diminish the efforts of the Flow team. It would be a better to have this functionality built into Flow.

[motiz88]

@pvolok I'd be interested in hacking on this. I'm not fluent in OCaml right now but this is a massively important, "obvious", missing piece of infrastructure for using GraphQL in JS and I want to help in any way I can.

Would you mind sharing any kind of status update on the work you've done so far? I see your PRs haven't been updated in a while.

[pvolok]

@motiz88 I stopped working on it long ago. AFAIK there are no plans to bring GraphQL into Flow.

I think the way to go now is to use codegen as the previous comment suggests.

[mrkev]

This sounded like an interesting idea, I didn't know it had been attempted. @pvolok I'd be interested to sync up and learn about the blockers/limitations you encountered and what led you to eventually abandon this project. From a quick skim of the PR Sam seemed interested to see how this change would look like too.

I recently learned about type providers in F#, and have wondered how that could look like in Flow. It'd probably be a sizable change and I'm unsure if the infrastructure to support them is there yet, but it could act as a general version to achieve something like this (aka, implement a GraphQL type provider). Sam opened a wishlist issue about this a while ago: #722.

[sibelius]

@mrkev should we reopen this issue?

[mrkev]

Direct GraphQL support is not directly planned-- I think this is better tracked as an extension to the Type providers issue (though in the future, if there's action to be taken here, it should be re-opened).