Graphql-go: Allow returning string for an ID field?

[vergenzt]

Right now resolvers of fields with GraphQL type ID have to return either a Go graphql.ID type (imported from neelance/graphql-go), or declare their own ID type, implement ImplementsGraphQLType and UnmarshalGraphQL for it, and return that type. Aside from this issue there's no other need to import neelance/graphql-go in resolver definitions at all.

There is already some precedent, though I'm not sure if it's intentional: field _arguments_ of GraphQL type ID are passed correctly to Go resolver functions that expect strings. (See demo below.)

TL;DR: Would it be possible to allow resolvers for fields of GraphQL type ID to simply return strings?

---

See demo gist here: https://gist.github.com/vergenzt/c4dbc132e101d08e4e711796255742e9

With this schema:

schema {
    query: Query
}

type Query {
    stringIdAcceptedAsArgument(userId: ID!): String!
    stringIdNotAcceptedAsReturnValue: ID!
}

and these resolvers:

type resolver struct{}

func (*resolver) StringIdAcceptedAsArgument(args struct{ UserID string }) string {
    return "Hello, user " + args.UserID + "!"
}

func (*resolver) StringIdNotAcceptedAsReturnValue() string {
    return "123"
}

the only error thrown is on the resolver with the string _return_ type.

[lpalmes]

You could wrap the return in graphql.ID("123"), but you would like to avoid this, right?

[vergenzt]

but you would like to avoid this, right?

Correct. 😕 It's not a huge deal, but it just feels messy to have to import graphql-go from my resolver definitions when they're so close to being completely independent.

[vergenzt]

Also I'd also be happy to work on a PR for this if the author is open to it! Just thought I'd report it first though.

[pavelnikolov]

Why do you use ID in your schema? Just use String and everything will be just fine for you, no?

[vergenzt]

ID has more appropriate semantics for an opaque identifier than String. Like I said, not a big deal, but nice to have.

[smithaitufe]

Please what is the update regarding this issue?

Is there a specific why we simply cannot return string?

[pavelnikolov]

I am closing this issue as it's more of a syntactic sugar than an issue.