-
Notifications
You must be signed in to change notification settings - Fork 2k
Add coordinate field to schema element definitions #3808
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: schema-coordinates
Are you sure you want to change the base?
Add coordinate field to schema element definitions #3808
Conversation
✅ Deploy Preview for compassionate-pike-271cb3 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Hi @yaacovCR, I'm @github-actions bot happy to help you with this PR 👋 Supported commandsPlease post this commands in separate comments and only one per comment:
|
cc309b6
to
39b5de5
Compare
While rebasing/reviewing this, I noticed that the new I initially thought to just add them in, but then I also noticed that some of the existing Questions:
|
f7e4d06
to
e08f1d7
Compare
4dbc894
to
3df173b
Compare
d2275f2
to
1931581
Compare
1931581
to
d8dc391
Compare
extracted from graphql#3808 PR graphql#3808 uses schema coordinates to improve GraphQL-JS error messages. To reduce the size of the PR, this commit standardizes error messages according to the general pattern that will be introduced with schema coordinates without introducing the coordinates themselves, in the hopes of aiding review of the later PR. Parenthetically, extracting these changes out of graphql#3808 demonstrates how the use of schema coordinates improves our error messages. For example, it is difficult when printing an error message regarding an argument to easily look up the field of that argument, and, if it a nested input field, the full field path. It is similarly sometimes difficult to know the type of the field or argument triggering the error. Embedding schema coordinates within GraphQL-JS makes this trivial. This PR simply omits the changes from graphql#3808 that are directly enabled by the use of schema coordinates. graphql#3808 can then be rebased on top of this PR to demonstrate the code changes and the direct improvement in the various error messages.
extracted from graphql#3808 PR graphql#3808 uses schema coordinates to improve GraphQL-JS error messages. To reduce the size of the PR, this commit standardizes error messages according to the general pattern that will be introduced with schema coordinates without introducing the coordinates themselves, in the hopes of aiding review of the later PR. Parenthetically, extracting these changes out of graphql#3808 demonstrates how the use of schema coordinates improves our error messages. For example, it is difficult when printing an error message regarding an argument to easily look up the field of that argument, and, if it a nested input field, the full field path. It is similarly sometimes difficult to know the type of the field or argument triggering the error. Embedding schema coordinates within GraphQL-JS makes this trivial. This PR simply omits the changes from graphql#3808 that are directly enabled by the use of schema coordinates. graphql#3808 can then be rebased on top of this PR to demonstrate the code changes and the direct improvement in the various error messages.
…4177) extracted from #3808 PR #3808 uses schema coordinates to improve GraphQL-JS error messages. To reduce the size of the PR, this commit standardizes error messages according to the general pattern that will be introduced with schema coordinates without introducing the coordinates themselves, in the hopes of aiding review of the later PR. EDITED 8/26/2024: I was able to reproduce all of the standardized error messages from #3808 except for the ones in getArgumentValues when it is passed a Field Definition, because the parent type is not passed. Everything else can be calculated for the error messages we are currently printing, although schema coordinates simplifies things. Extracting these changes out of #3808 and rebasing #3808 on main will therefore will better demonstrate how schema coordinates improves the clarity of some of our error messages (namely, getArgumentValues) and simplifies printing them.
293f34b
to
163918f
Compare
…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 <decroockjovi@gmail.com>
* Changes `GraphQLSchemaElement` interface into a base class which defines a `.coordinate` property and `toString`/`toJSON` methods. * Uses the base class to types, fields, arguments, input fields, enum values, and directives. * Uses this in validation error printing string templates. * Exports the now finalized GraphQLSchemaElement, GraphQLField, GraphQLArgument, GraphQLInputField, GraphQLEnumValue classes. This differs from the original graphql#3145 in that GraphQLField, GraphQLArgument, GraphQLInputField, GraphQLEnumValue constructors take the parent type/field as arguments instead of the parent coordinate. This obviates the need to validate the parent coordinate.
163918f
to
d0dd902
Compare
export { | ||
resolveObjMapThunk, | ||
resolveReadonlyArrayThunk, | ||
// Definitions | ||
GraphQLSchema, | ||
GraphQLDirective, | ||
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.
Answering here from #3044 (comment). I missed that PR during the recent coordinates dicussion. Do we need GraphQLSchemaElement
?
I'm fine if there's no "bidirectionality" between a coordinate and a schema element. We could even have GraphQLSchemaElement
without the coordinate
property and that would probably be fine for me too. In other words, I'm ok with coordinates being "1-way".
Did we have any more context about this? Are there use cases out there that would benefit from GraphQLField
having a coordinate
property for an example?
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.
We can ask @leebyron for more context, I think the original idea was to use the coordinate concept as an internal convenience to standardize our error messages. In #4288 we basically took the concept with their standardized error messages without the coordinate field itself, so that's why this rebased PR doesn't have a large error message diff and #3145 does.
#3145 rebased on main.
depends on #3044
GraphQLSchemaElement
interface into a base class which defines a.coordinate
property andtoString
/toJSON
methods.This differs from the original PR #3145 in that GraphQLField, GraphQLArgument, GraphQLInputField, GraphQLEnumValue constructors now take the parent type/field itself as the first argument instead of the parent coordinate. This obviates any need to validate the parent coordinate.
@leebyron comments from original PR: