New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GraphQL support #2823

Closed
pvolok opened this Issue Nov 16, 2016 · 11 comments

Comments

Projects
None yet
8 participants
@pvolok
Contributor

pvolok commented Nov 16, 2016

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 #2822
    • Field arguments #3051
    • Merge fields
    • Variables #3051
    • Directives
  • $GraphqlData annotation for extracting query/fragment data #3051
  • $GraphqlVars annotation for extracting query/fragment variables #3051
  • Fragment resolving
  • Fragment references (fragments for child components in Relay)
  • Fragments unifying (what happens when 2+ fragments flow into one variable?)
  • Autocomplete
    • Fields #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

  • #2822 — schema loading and basic validations.
  • #3051GraphqlData and GraphqlVars annotations, field args and variables validation.
@vkurchatkin

This comment has been minimized.

Show comment
Hide comment
@vkurchatkin

vkurchatkin Nov 16, 2016

Collaborator

Related issue: #722

Collaborator

vkurchatkin commented Nov 16, 2016

Related issue: #722

@sibelius

This comment has been minimized.

Show comment
Hide comment
@sibelius

sibelius Apr 17, 2017

any progress on this?

sibelius commented Apr 17, 2017

any progress on this?

@pvolok

This comment has been minimized.

Show comment
Hide comment
@pvolok

pvolok Apr 18, 2017

Contributor

@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.

Contributor

pvolok commented Apr 18, 2017

@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 comment has been minimized.

Show comment
Hide comment
@bstro

bstro Jul 6, 2017

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

bstro commented Jul 6, 2017

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

@ivawzh

This comment has been minimized.

Show comment
Hide comment
@ivawzh

ivawzh Jul 6, 2017

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

ivawzh commented Jul 6, 2017

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

@bgw

This comment has been minimized.

Show comment
Hide comment
@bgw

bgw Jul 7, 2017

Member

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.

Member

bgw commented Jul 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@motiz88

motiz88 Jun 16, 2018

Contributor

@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.

Contributor

motiz88 commented Jun 16, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@pvolok

pvolok Jun 21, 2018

Contributor

@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.

Contributor

pvolok commented Jun 21, 2018

@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.

@pvolok pvolok closed this Jun 21, 2018

@mrkev

This comment has been minimized.

Show comment
Hide comment
@mrkev

mrkev Jun 25, 2018

Contributor

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.

Contributor

mrkev commented Jun 25, 2018

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

This comment has been minimized.

Show comment
Hide comment
@sibelius

sibelius Jul 23, 2018

@mrkev should we reopen this issue?

sibelius commented Jul 23, 2018

@mrkev should we reopen this issue?

@mrkev

This comment has been minimized.

Show comment
Hide comment
@mrkev

mrkev Jul 24, 2018

Contributor

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).

Contributor

mrkev commented Jul 24, 2018

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment