Skip to content
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

Closed
swolchok opened this issue Jul 14, 2015 · 3 comments
Closed

Having both isDeprecated and deprecationReason is redundant #53

swolchok opened this issue Jul 14, 2015 · 3 comments

Comments

@swolchok
Copy link

Just define it so that fields are deprecated iff they have a non-null deprecationReason.

@leebyron
Copy link
Collaborator

The current reason for this is that deprecationReason is optional, regardless of if a field is deprecated or not, allowing a field to be tersely deprecated and avoiding less good cases like using empty strings to indicate deprecation or something along those lines.

I also felt like it was more clear to have the isDeprecated field, otherwise it seemed easy to misread the list of fields and assume deprecation was always possible.

If we decide to change this though, I would expect that decision to also include making description non-nullable. It's non-nullable for the same reason this semi-redundancy exists.

@leebyron
Copy link
Collaborator

leebyron commented Oct 2, 2018

Closing this aging issue.

@leebyron leebyron closed this as completed Oct 2, 2018
@martinbonnin
Copy link
Contributor

martinbonnin commented Aug 22, 2023

necromancer_mode_on

Can we revive this discussion?

allowing a field to be tersely deprecated and avoiding less good cases like using empty strings to indicate deprecation or something along those lines

Since the current @deprecated directive definition has a default value, feels like terseness is not a problem anymore? One can always deprecate using just the directive:

type Query {
  foo: Int @deprecated
}

We could make reason non-nullable in SDL:

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 deprecationReason:

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 isDeprecated internally: graphql/graphql-js#2700

Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants