-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Add coordinate field to schema element definitions #3145
base: schema-coordinates
Are you sure you want to change the base?
Conversation
b842aaa
to
42eaa34
Compare
3cec8c2
to
e688f88
Compare
10377f4
to
9d5277a
Compare
9d5277a
to
4e4d16e
Compare
c68ca9b
to
8fa8a4c
Compare
4e4d16e
to
a4c7cea
Compare
8fa8a4c
to
98e7541
Compare
* Defines a `GraphQLSchemaElement` base class which defines a `.coordinate` property and `toString`/`toJSON` methods. * Adds base class to types, fields, arguments, input fields, enum values, and directives. * Uses this in validation error printing string templates.
a4c7cea
to
b8ee9a2
Compare
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've read over this and tried to understand what's going on. Adding the GraphQLSchemaElement
base class, and having everything be a class that inherits it makes a lot of sense. I think all the elements are covered here.
Looks great to me! (But I'm still getting up to speed on this codebase)
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 have no issue with switching the couple of schema interfaces to concrete classes, but if something would go wrong with this diff that's where I'd anticipate downstream issues.
args: [ | ||
{ | ||
name: 'name', | ||
description: undefined, | ||
type: new GraphQLNonNull(GraphQLString), | ||
defaultValue: undefined, | ||
deprecationReason: undefined, | ||
extensions: undefined, | ||
astNode: undefined, | ||
}, | ||
], |
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.
nice cleanup
@@ -184,17 +184,17 @@ function validateDirectives(context: SchemaValidationContext): void { | |||
// Ensure the type is an input type. | |||
if (!isInputType(arg.type)) { | |||
context.reportError( | |||
`The type of @${directive.name}(${arg.name}:) must be Input Type ` + | |||
`The type of ${arg} must be Input Type ` + |
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.
oooh this is a much nicer pattern too. Quite clever, that the arg will be schematized when it's stringified.
|
||
if (!argDef && fieldDef && parentType) { |
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.
oh that is a much cleaner pattern: it's great that we can now remove the only-needed-for-the-message value.
@@ -1724,14 +1701,46 @@ export interface GraphQLInputFieldConfig { | |||
|
|||
export type GraphQLInputFieldConfigMap = ObjMap<GraphQLInputFieldConfig>; | |||
|
|||
export interface GraphQLInputField { | |||
export class GraphQLInputField extends GraphQLSchemaElement { |
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.
This change seems likely to break implementations that implement GraphQLInputField
in a custom way. I don't know how common that is, but definitely not a purely safe adjustment.
context.reportError( | ||
new GraphQLError( | ||
`The field ${parentType.name}.${fieldDef.name} is deprecated. ${deprecationReason}`, | ||
`The field ${fieldDef} is deprecated. ${deprecationReason}`, |
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.
Should this be Field ${fieldDef} is deprecated.
similar to what you're doing in ValuesOfCorrectTypeRule?
[#3049 rebased on main](#3049). This is the last rebased PR from the original PR stack concluding with #3049. * Rebased: #3809 [Original: #3092] * Rebased: #3810 [Original: #3074] * Rebased: #3811 [Original: #3077] * Rebased: #3812 [Original: #3065] * Rebased: #3813 [Original: #3086] * Rebased: #3814 (this PR) [Original: #3049] Update: #3044 and #3145 have been separated from this stack. Changes from original PR: 1. `astFromValue()` is deprecated instead of being removed. @leebyron comments from #3049, the original PR: > Implements [graphql/graphql-spec#793](graphql/graphql-spec#793) > > * BREAKING: Changes default values from being represented as an assumed-coerced "internal input value" to a pre-coerced "external input value" (See chart below). > This allows programmatically provided default values to be represented in the same domain as values sent to the service via variable values, and allows it to have well defined methods for both transforming into a printed GraphQL literal string for introspection / schema printing (via `valueToLiteral()`) or coercing into an "internal input value" for use at runtime (via `coerceInputValue()`) > To support this change in value type, this PR adds two related behavioral changes: > > * Adds coercion of default values from external to internal at runtime (within `coerceInputValue()`) > * Removes `astFromValue()`, replacing it with `valueToLiteral()` for use in introspection and schema printing. `astFromValue()` performed unsafe "uncoercion" to convert an "Internal input value" directly to a "GraphQL Literal AST", where `valueToLiteral()` performs a well defined transform from "External input value" to "GraphQL Literal AST". > * Adds validation of default values during schema validation. > Since assumed-coerced "internal" values may not pass "external" validation (for example, Enum values), an additional validation error has been included which attempts to detect this case and report a strategy for resolution. > > Here's a broad overview of the intended end state: > > ![GraphQL Value Flow](https://user-images.githubusercontent.com/50130/118379946-51ac5300-b593-11eb-839f-c483ecfbc875.png) --------- Co-authored-by: Lee Byron <[email protected]>
…QLEnumValue (#4288) this extracts logic from #3044 and #3145 (later rebased as #3807 and #3808) to implement more informative error messages without implementing [the full schema coordinate RFC](graphql/graphql-spec#794) This is a BREAKING CHANGE because these schema elements are now longer plain objects and function differently in various scenarios, for example with `String(<schemaElement>` `JSON.stringifu(<schemaElement>` and `.toString()` and `.toJSON()` --------- Co-authored-by: Jovi De Croock <[email protected]>
Depends on #3044
GraphQLSchemaElement
base class which defines a.coordinate
property andtoString
/toJSON
methods.Results in a net-reduction of code, minor simplification of definition.ts, and simplification/standardization of error messages