Hi,
I was able to create enums with values using stuff like:
new GraphQLEnumType({
name : 'Test',
values: {
FOO: { value: 1 },
BAR: { value: 2 }
}
});
I realized that with the buildSchema method, you can only use this:
enum Test {
FOO
BAR
}
How can I achieve the first example using the new syntax ?
The internal value of an enum is an implementation detail, and the schema language syntax intentionally does not define any internal implementation details.
This is one of a few examples of implementation details of a schema not being exposed via the schema language, another example is the resolver functions for fields.
For this very reason, the first example cannot be achieved by using the schema language alone since it requires specifying an internal implementation detail. Similar to how custom resolver functions cannot be defined with the schema language alone.
What might be a little hacky, but would probably work, is to first create a schema with the schema language, and then manually edit that schema to insert the internal values for the enums in question. I know tools like Apollo already use this technique for providing custom resolver functions, so it should probably also work for custom internal enum values.
Of course, you can also continue to use the type and schema constructors directly! They're still the preferred method for building larger or more complex type systems since they provide everything necessary to define the internal implementation details inline.
Yep, this is something we should add support on in graphql-tools. Let's work on a design there, I think the implementation will be pretty simple!
Hey @stubailo,
Per your above comment, do you know if support for specifying enum values was added to graphql-tools yet?
I found the documentation for how to do this with graphql-tools:
https://www.apollographql.com/docs/graphql-tools/scalars.html#internal-values
Most helpful comment
The internal value of an enum is an implementation detail, and the schema language syntax intentionally does not define any internal implementation details.
This is one of a few examples of implementation details of a schema not being exposed via the schema language, another example is the resolver functions for fields.
For this very reason, the first example cannot be achieved by using the schema language alone since it requires specifying an internal implementation detail. Similar to how custom resolver functions cannot be defined with the schema language alone.
What might be a little hacky, but would probably work, is to first create a schema with the schema language, and then manually edit that schema to insert the internal values for the enums in question. I know tools like Apollo already use this technique for providing custom resolver functions, so it should probably also work for custom internal enum values.
Of course, you can also continue to use the type and schema constructors directly! They're still the preferred method for building larger or more complex type systems since they provide everything necessary to define the internal implementation details inline.