-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Field extensions: spec edits #1196
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
base: main
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for graphql-spec-draft ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
martinbonnin
left a comment
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.
Thanks for looking into this! Few comments below
benjie
left a comment
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.
A little editorial
| #### Field Extensions | ||
|
|
||
| Field extensions are used to represent a field which has been extended from some |
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.
Nit: move this before the Type Validation and do not mention "Field extensions"?
Instead make a part of "type extension"?
| 2. The default argument definitions may not be changed or removed. | ||
| 3. The description may be added if none exists, or must match the existing | ||
| description exactly |
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.
Can we either:
- allow both descriptions and defaultValues if they match exactly.
or - forbid both descriptions and defaultValues in object extensions.
Slight preference for 1. because it's consistent with what we do for checking the type. But I can see how 2. is maybe simpler to implement.
| 4. The deprecation reason may be added if none exists, or must match the | ||
| existing reason exactly | ||
| 5. Directives may be added but cannot conflict with existing non-repeatable | ||
| directives |
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.
I think we should remove 4. as a sub-case of 5. @deprecated is not repeatable so it's not valid to add @deprecated from a type extension, even if it's the exact same deprecation reason.
| In this example, we can deprecate the field `field` on type `Query` by using a | ||
| field extension: |
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.
Same here. I'd phrase that as a "type extension that adds deprecation to the type fields":
| In this example, we can deprecate the field `field` on type `Query` by using a | |
| field extension: | |
| In this example, we can deprecate the field `field` on type `Query` by adding a `@deprecated` directive through a type extension: |
Uh oh!
There was an error while loading. Please reload this page.