-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Enable passing values configuration to GraphQLEnumType as a thunk #4018
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
Conversation
✅ Deploy Preview for compassionate-pike-271cb3 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Hi @benjie, 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:
|
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.
That's a great find (and improvement)! All for consistency on these properties either way
The option of passing a thunk was made available by: #4018 . Always passing the thunk helps contribute to a "lazy" build process, which gives the following performance boost:  Lazy evaluation results in bad names for enum values not being checked until `type.getValues()` is called, similar to how bad names for fields are not checked until `type.getFields()` is called. Explicit validation validates enum value names just as with field names.
Many of the type configuration objects in GraphQL-js have properties that accept thunks:
These are because their definitions may contain references to other types which may form cycles, and thus a thunk is required to enable their definition.
This PR allows setting
GraphQLEnumTypeConfig.valuesto be a thunk. At first, this might seem unnecessary (and, well, it has been this way for 9 years so you can be forgiven for thinking that) but it can be quite useful when building enums that reference types. For example: you might have a field that returns a union (Person.pets), and you might want to add an argument that allows you to limit the returned types to only certain types (Person.pets(only:)):For this it can be useful for the
AnimalTypetype to enumerate the types in theAnimalunion, but those types contain references back toAnimalType-> there's a cycle.The thunk approach outlined in this PR would solve the cycle. There are workarounds (i.e. manually listing out the types) but they're not as ergonomic as (and are more error-prone than) resolving the values directly from the union.