Enum support for resolver functions

[marktani]

What feature are you missing?

Defining an input field in a resolver of type enum like this:

extend type Query {
  fixer(base: Currency, date: DateTime): FixerPayload
}

with the enum

enum Currency {
  USD
  EUR
}

results in this error message when deploying:

Schema Extension Error for function 'fixer-wrapper': Relations are
 ▸    currently not supported. Field 'base':
<snip>

The same error is returned for this payload:

type FixerPayload {
  base: String!
  date: DateTime!

  # might be null, for base
  usd: Currency
}

Enums should be supported as input field types, as well as output field types for resolver functions! 🙂

[vtsatskin]

@marktani I'm interested in tracking the availability of this feature. Will the closing of this issue mean that it has been implemented?

[johnslemmer]

I would also like to add a request that not noly Enums but any type defined. I'm trying to return an object I defined in my types.graphql, and it of course won't work.
For the resolvers, graphcool, and API to be fully graphql-esque we shouldn't need to make a second api request. But right now I have to return a primitive (the id of the object) from the resolver and then make a second request for the object via the included CRUD api.
Graphql was created in part to make doing this "second round trip" unnecessary.

[shortjared]

Just ran into this one as well. Would have expected enums to bubble up from the root types.graphql at least. All other root types would be handy too obviously.

[kbrandwijk]

@johnslemmer Support for model types is also tracked in this issue: https://github.com/graphcool/framework/issues/743.

[marktani]

This issue has been moved to graphcool/graphcool-framework.