-
-
Notifications
You must be signed in to change notification settings - Fork 814
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
Added extend
support to schemaGenerator
#90
Added extend
support to schemaGenerator
#90
Conversation
@davidyaha: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/ |
* Changelog update
@@ -1,5 +1,8 @@ | |||
# Changelog | |||
|
|||
### v0.6.2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rename this to vNEXT (we pick the version when we publish)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do! Wasn't sure what to put here 😅
@davidyaha Thanks a lot, this looks pretty good! Can you add one test that checks that extensions also work when you define them in different files? To test that, you can just have an array with individual definitions (type strings) as elements instead of having just one long string. That will simulate importing from different files. |
Hey @helfer, thanks for the review. The first test I've added uses an array of type definitions. Would you like me to add another one with a string for the more common case? |
You're right, in that case it's fine as it is! The only remaining thing that would be nice to have is if there was a test for this line: Right now, that doesn't seem to be covered. If there's no way that line can be reached anyway, then you can remove the whole test altogether. |
… throwing an error or creating an AST document. * Also changed version on changelog to vNEXT as required
Absolutely right. There is no need for that check. |
Great, thanks for the PR! |
@davidyaha Oh, hey, can you make this PR against master? I think you made it against an already merged branch by accident. |
Holy crap, we have this feature?!?!!? why is it not documented anywhere! |
Hehe, my first PR here.. been telling people about it on slack when ever the subject poped.. but didn't think of adding it to the docs. |
This PR is meant to allow use of the following IDL syntax:
https://github.com/graphql/graphql-js/blob/9ea8196c2af97551bab5cfd57201c29e3085ee4e/src/utilities/__tests__/extendSchema.js#L127
It seems to a feature that was meant to be used for client purposes only.
But, in my opinion, while using the IDL to describe type definitions, you lose to ability to do cyclic dependencies and by that, the ability to create suite packages that will enhance and be enhanced by your own application code base.
e.g:
Consider the accounts package as the sole owner of the User type, being so, in your own schema files, you would like to use that same User type to describe relations to other types.
Lets say Post
And so you would also like to expand on the User type to allow for relations to the Post type:
Other possible solutions could be to use union types but these will not allow to get the extended User type on the queries provided by the accounts package
This PR is not harming any previous features of the schemaGenerator.
One current limitation is that after you've added an
extend
type definition, you have to provide type resolvers for all fields.TODO: