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
Having both isDeprecated and deprecationReason is redundant #53
Comments
The current reason for this is that I also felt like it was more clear to have the If we decide to change this though, I would expect that decision to also include making |
Closing this aging issue. |
necromancer_mode_on Can we revive this discussion?
Since the current type Query {
foo: Int @deprecated
} We could make directive @deprecated(
# note how reason is non-nullable here
reason: String! = "No longer supported"
) on FIELD_DEFINITION | ARGUMENT_DEFINITION | INPUT_FIELD_DEFINITION | ENUM_VALUE This will also forbid such possibly confusing declarations: type Query {
# is this deprecated? If yes, why? how is it different than the default "No longer supported"?
foo: Int @deprecated(reason: null)
} Introspection would keep nullable type __Field {
name: String!
description: String
args(includeDeprecated: Boolean = false): [__InputValue!]!
type: __Type!
# remove (or deprecate 😄 `isDeprecated`)
# isDeprecated: Boolean!
# keep the current behaviour for deprecationReason
"the deprecation reason if the field is deprecated or null if the field is not deprecated"
deprecationReason: String
} Looks like graphql-js is also taking that route and deprecating Thoughts? |
Just define it so that fields are deprecated iff they have a non-null
deprecationReason
.The text was updated successfully, but these errors were encountered: