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.

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

Make 'ASTDefinitionBuilder' responsible only for build types from AST #1230

Merged
merged 4 commits into from
Feb 15, 2018

Conversation

IvanGoncharov
Copy link
Member

It's part of #1199
Its primary purpose is to make 'ASTDefinitionBuilder' responsible only for build types from AST.
It's not only made possible to extract transformSchema into the separate function but also make the code more modular and simple.

Copy link
Contributor

@leebyron leebyron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good - just one minor suggested change

}
return type;
return (extendedType: any);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest factoring this into two functions, getExtendedType and extendType, the first one performing caching (with a comment that extendType need only be called once per type). That should allow you to remove or at least further isolate the any cast.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@leebyron Great idea 👍 I will make the change in a few minutes.

Copy link
Member Author

@IvanGoncharov IvanGoncharov Feb 9, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@leebyron Sadly there is some kind of bug with Flow which prevents the suggested change:
image

You can test it here online but demo broken for 0.65 at the moment so you need to switch it to 0.64. But I tested 0.65 locally and the result is the same.

What should I do?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cast through any internally while keeping the correct function definition, and we'll report it to the flow team

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@leebyron Done. Can you please review?

}
return type;
// Workaround: Flow should figure out correct type, but it doesn't.
return (extendedType: any);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than mutating a variable in each branch, just return the value in each branch. Flow can't figure out what the type of extendedType is, since there are so many different possible local mutations

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@leebyron I did that initially but it forces me to do typecast in every branch. Plus explaining workaround is more complicated.

Flow can't figure out what the type of extendedType is, since there are so many different possible local mutations

Flow has exactly the same problem figuring types both with or without mutations. You can see it in CI logs for your commit and in Flow playground:
image
image

@IvanGoncharov
Copy link
Member Author

@leebyron a8b9539 is failing flow check and I don't know how to fix it: #1230 (comment)
What should I do?

@IvanGoncharov
Copy link
Member Author

@leebyron I finally figure our how fix flow error, see 6f1867c
Can you please review this change?

@leebyron leebyron merged commit 2c58b26 into graphql:master Feb 15, 2018
@leebyron
Copy link
Contributor

Looks great! Thanks for iterating towards this better version

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

Successfully merging this pull request may close these issues.

3 participants