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

Mark EnumValuesDefinition as required in EnumTypeDefinition #624

Closed
wants to merge 1 commit into from

Conversation

zombiezen
Copy link

I believe this to be a typo, as the Type Validation section reads:

An Enum type must define one or more unique enum values.

Syntactically, I don't see a reason to permit a production like:

enum Foo

because it will never be valid by the above rule. Are there any tools that permit this production?

@IvanGoncharov
Copy link
Member

@zombiezen Thanks for PR 👍

An Enum type must define one or more unique enum values.

This validation applied only to the types in the "executable" schema (fully constructed schema that is ready to execute queries) and it doesn't apply to intermediate schemas.
For example:

# main.graphql

enum TransactionType

# creditCard.graphql

extend enum TransactionType {
  CREDIT_CARD
}

Same goes for any other GraphQL type (type, input, interface, union) you can define them as empty types and latter extend them.

Here is discussion about adding this feature to the spec: #90 (comment)

@zombiezen
Copy link
Author

Got it, thank you for the explanation! Sorry for the noise.

@IvanGoncharov
Copy link
Member

@zombiezen NP, please feel free to open similar PRs.
Actually I think we need to add some clarification into the spec because it's not the first time this question arises, e.g. #564 (comment)
Maybe you have an idea of where to add such clarification and want to work on PR?

@zombiezen
Copy link
Author

I think some more (non-normative) text around extensions in general would be beneficial, because even after multiple readings, I'm not sure that I understand how they interact with the other elements of the spec.

Am I right in understanding that extensions are used for when the schema is split up into multiple chunks internally and then presented as a single schema by tooling? It's unclear to me whether an extension can appear before the type definition, although it doesn't seem like it matters much since the spec seems to necessitate a two-pass type creation algorithm for name resolution.

@IvanGoncharov
Copy link
Member

Am I right in understanding that extensions are used for when the schema is split up into multiple chunks internally and then presented as a single schema by tooling?

@zombiezen AFAIK main reason for adding extensions was client-side schema extensions:
https://relay.dev/docs/en/local-state-management#extending-the-client-schema
So the ability to split types between files is just a by-product (it was never among design goals) but since it's become so popular in GraphQL community we added support for empty types to improve DX.

Am I right in understanding that extensions are used for when the schema is split up into multiple chunks internally and then presented as a single schema by tooling?

Yes, but please note that SDL is not the only way to author schema, for example, you can write an SDL extension for code first schema.

It's unclear to me whether an extension can appear before the type definition, although it doesn't seem like it matters much since the spec seems to necessitate a two-pass type creation algorithm for name resolution.

The order of definitions inside GraphQL documents is not important both for query documents and SDL documents.
GraphQL spec doesn't describe what should happen with SDL documents after parsing but in some implementations (include reference one), the processing order of SDL documents is important you can't extend definition before it defined (or use type before it defined).

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

Successfully merging this pull request may close these issues.

2 participants