Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Better Flow type defs for field resolvers #574

Closed
1 of 5 tasks
leebyron opened this issue Nov 15, 2016 · 8 comments
Closed
1 of 5 tasks

Better Flow type defs for field resolvers #574

leebyron opened this issue Nov 15, 2016 · 8 comments
Labels
enhancement

Comments

@leebyron
Copy link
Contributor

leebyron commented Nov 15, 2016 •
edited
Loading

When writing resolvers for GraphQL types in a flow-typed environment, the Flow types should aid as much as possible.

  • Do not require casting through (: any) for typical behavior.
  • Proper typing of context
  • Proper typing of source
  • Proper typing of return
  • Proper typing of arguments
@leebyron leebyron mentioned this issue Nov 15, 2016
Merged
@leebyron
Copy link
Contributor Author

This was originally inspired by discussion in #554.

leebyron added a commit that referenced this issue Nov 15, 2016
@leebyron
Add TContext to type resolvers
6dbc12e 
Part of #574
@leebyron leebyron mentioned this issue Nov 15, 2016
Merged
leebyron added a commit that referenced this issue Nov 15, 2016
@leebyron
RFC: Add type params to Scalars.
ca6c284 
This incrementally adds to #574, however a broader solution is needed to create a mirroring between graphql type definitions and internal flow types.
@leebyron leebyron mentioned this issue Nov 15, 2016
Closed
leebyron added a commit that referenced this issue Nov 15, 2016
@leebyron
Type field arg values as "any"
9f06828 
This changes the flow types from an object of mixed values to an object of any values. This is explicitly less type safe, however is way more ergonomic and better matches the previous behavior before flow types were exported.

This was suggested in #554 and partially implements #574
@leebyron leebyron mentioned this issue Nov 15, 2016
Merged
@leebyron leebyron self-assigned this Nov 16, 2016
@jamiehodge jamiehodge mentioned this issue Nov 23, 2016
Closed
@jamiehodge
Copy link

@leebyron is there any progress on this meta issue? It would really helpful to get end-to-end typing of the graph and the possibility of leveraging that in the client.

@jamiehodge
Copy link

@leebyron are you still working on this issue? Is there something I or others could help with?

@corydeppen
Copy link

Has there been any additional consideration for what it will take to move forward with the remainder of the typings for resolvers?

@corydeppen corydeppen mentioned this issue Nov 8, 2017
Closed
leebyron added a commit that referenced this issue Dec 6, 2017
@leebyron
RFC: Add type params to Scalars.
7c95784 
This incrementally adds to #574, however a broader solution is needed to create a mirroring between graphql type definitions and internal flow types.
leebyron added a commit that referenced this issue Dec 6, 2017
@leebyron
RFC: Add type params to Scalars.
b52da62 
This incrementally adds to #574, however a broader solution is needed to create a mirroring between graphql type definitions and internal flow types.
@ryan0319-zz ryan0319-zz mentioned this issue Mar 25, 2018
Open
@sibelius
Copy link

@gtkatakura is using conditional mapped types to improve types: gtkatakura/fullstack-challenge@36cc105

@gtkatakura-bysoft
Copy link

gtkatakura-bysoft commented Jul 25, 2018 •
edited
Loading

If it helps... proper typing of return (only for GraphQLScalarType) in TypeScript

gtkatakura/fullstack-challenge@bc01861

@sibelius
Copy link

typing for GraphQLScalarType #1522

@sibelius sibelius mentioned this issue Sep 14, 2018
Closed
@IvanGoncharov IvanGoncharov added this to the v15.0.0 milestone Jan 30, 2019
@IvanGoncharov IvanGoncharov removed this from the v15.x.x milestone Aug 13, 2020
@saihaj
Copy link
Member

saihaj commented Jun 27, 2022

we no longer support Flow #2860

@saihaj saihaj closed this as completed Jun 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@leebyron @corydeppen @jamiehodge @sibelius @IvanGoncharov @gtkatakura-bysoft @saihaj