Open frederikhors opened 3 years ago
Very glad to see your effort to deal with the problem of optional/nullable. I vote for solution 2: Generate NullType to handle optional params/models.
undefined
has no difference to null
. If the type is String!
it can't be also null and undefined.NullNullString
. (In some other language such as rust, you can see some type like Option<Option<T>>
)NullType
before the generic type feature publish.Here's an additional, slightly different but just as ugly solution, it uses GetFieldContext instead of GetRequestContext and gives back a list of "touched" fields within an object
// GetArgumentFieldnames returns a list of fieldnames from an argument
func (r *Resolver) GetArgumentFieldnames(ctx context.Context, name string) []string {
fieldContext := graphql.GetFieldContext(ctx)
names := []string{}
for _, arg := range fieldContext.Field.Arguments {
if arg.Name != name {
continue
}
for _, child := range arg.Value.Children {
names = append(names, child.Name)
}
}
return names
}
Is there any progress on this?
I would allow for a optional struct at least for input fields, that allows to differentiate defined and undefined fields.
Especially now with Go 1.18's generics this could be implemented, more or less type safe.
Also interested!
gqlgen supported Go 1.18 and Generics. Supporting Optional has become a reality.
I would like to get more opinions on https://github.com/99designs/gqlgen/pull/2585#issuecomment-1479841839 please!
# graphql
type Mutation {
submit(input: SubmitInput!): SubmitPayload
}
input SubmitInput {
firstName: String
lastName: String
email: String
}
// go
type SubmitInput struct {
FirstName **string
LastName **string
Email **string
}
var input SubmitInput
if input.Email == nil {
// this is undefined
}
if input.Email != nil && *input.Email == nil {
// this is null
}
if input.Email != nil && *input.Email != nil {
email := **input.Email
// this is value
}
Hi !~ Can this be one of solutions ?
I think this topic could win the award as the most debated topic on web all along (since that damn day
null
was invented, at least :smile:)!I would like to summarize here everything I have read and tried on the subject, in the hope that Santa Claus will give us the robust solution we deserve this year (at least for gqlgen).
THE PROBLEM
As a developer I would like a quick way to identify in my resolvers if the user has deliberately chosen
null
as the value of the field (string/int/time/...) or if he is using sparse updates and has omitted those fields entirely.PROPOSALS READ AROUND
the official solution proposed by Gqlgen team (@vektah at least), use
map[string]interface{}
(https://gqlgen.com/reference/changesets/); but of course there are several counter-argumentsnullable types (proposed many times, one for all here); but as @jszwedko said it seems to not work either
checking ArgumentMap from context [as suggested here]()https://github.com/99designs/gqlgen/issues/505#issuecomment-586584763; the solution I'm using although it is very verbose and I need things like code generation
methods for setters proposed by the amazing @danilobuerger which is still a WIP
THREADS ON THE TOPIC
https://github.com/99designs/gqlgen/issues/505
https://github.com/99designs/gqlgen/issues/506
https://github.com/99designs/gqlgen/issues/977
https://github.com/99designs/gqlgen/issues/866
https://github.com/99designs/gqlgen/issues/646
WE ARE NOT ALONE
https://webdevstation.com/post/Work-with-nullable-strings-in-gqlgen-GraphQL-Server-0x4e28
https://www.calhoun.io/how-to-determine-if-a-json-key-has-been-set-to-null-or-not-provided/
https://github.com/guregu/null/issues/39
https://github.com/graphql-go/graphql/pull/401
https://github.com/graphql-go/graphql/issues/178
https://github.com/datastax/cassandra-data-apis/issues/6
https://github.com/graph-gophers/graphql-go/issues/210
https://github.com/graphql-rust/juniper/issues/183
https://github.com/graphql-rust/juniper/issues/108
PLEASE
Help us, gqlgen team.
🙏