GAP-0002 Add Field Extensions Spec#4
Conversation
So is the idea to compile this out of the SDL before passing to a GraphQL server? |
Yes |
|
I think this would benefit then from being layered on top of the soon-to-be-proposed language in the spec to clarify the difference between "human written"(?) schemas and "runtime" schemas. Not required for this to merge, but worth following along! @benjie wdyt about a dedicated 2xxx range for "language and syntax extensions"? side note, not directly relevant to this proposal but:
|
mjmahone
left a comment
mjmahone
left a comment
There was a problem hiding this comment.
Ugh as a GAP proposal figuring out the difference between a field extension and an original field definition inside an extension is tough, because I think we must have some kind of syntax, or at least a special directive.
I ran into a bunch of bugs before getting an internal representation where fields can be pure extensions, and I still have unresolvable bugs in going from SDL => SchemaSet (then do work on that set) => SDL. It's very frustrating.
| extend type Query { | ||
| id: ID @deprecated(reason: "Use globalId instead") | ||
| } |
There was a problem hiding this comment.
I actually think it would be cleaner to do:
| extend type Query { | |
| id: ID @deprecated(reason: "Use globalId instead") | |
| } | |
| extend type Query { | |
| extend id: ID @deprecated(reason: "Use globalId instead") | |
| } |
Basically you're being explicit that this field DOES already exist but you're adding more to it.
I have this exact situation and have an internal representation that we actually see that I can't do a round trip into the SDL and back into SchemaSet in https://github.com/facebook/relay/blob/main/compiler/crates/schema-set/src/set_exclude.rs#L413
3 participants
Copied from graphql/graphql-spec#1196 and graphql/graphql-spec#1162