Skip to content

Commit dd719de

Browse files
Add a mechanism to specify options on input-type fields (#124)
## Summary: This has been a bit of a thorn since we started using genqlient in production: just as you might want to specify, say, `omitempty` on an argument, you might equally want to specify it on an input-type field. But there's no obvious syntax to do that, because the input-type field does not appear in the query (only the schema) so there's nowhere to put the `# @genqlient` directive. This commit, at last, fixes that problem, via a new option, `for`, which you use in an option applied to the entire operation (or fragment), and says, "actually, apply this directive to the given field, not the entire operation". (It's mainly useful for input types, but I allowed it for output types too; I could imagine it being convenient if you want to say you always use a certain type or type-name for a certain field.) It works basically like you expect: the inline options take precedence over `for` take precedence over query-global options. The implementation was fairly straightforward once I did a little refactoring, mostly in the directive-parsing and directive-merging (which are now combined, since merging is now a bit more complicated). With that in place, and extended to support `for`, we need only add the same wiring to input-fields that we have for other places you can put directives. I did not attempt to solve the issue I've now documented as #123, wherein conflicting options can lead to confusing behavior; the new `for` is a new and perhaps more attractive avenue to cause it but the issue remains the same and requires nontrivial refactoring (described in the issue) to solve. (The breakage isn't horrible for the most part; the option will just apply, or not apply, where you don't expect it to.) But while applying that logic, I noticed a problem, which is that we were inconsistently cascading operation-level options down to input-object fields. (I think this came out of the fact that initially I thought to cascade them, then realized that this could cause problems like #123 and intended to walk them back, but then accidentally only "fixed" it for `omitempty`. I guess until this change, operation-level options were rare enough, and input-field options messy enough, that no one noticed.) So in this commit I bring things back into consistency, by saying that they do cascade: with at least a sketch of a path forward to solve #123 via better validation, I think that's by far the clearest behavior. Issue: #14 ## Test plan: make check Author: benjaminjkraft Reviewers: csilvers, StevenACoffman, benjaminjkraft, aberkan, dnerdy, jvoll, mahtabsabet, MiguelCastillo Required Reviewers: Approved By: csilvers, StevenACoffman Checks: ✅ Test (1.17), ✅ Test (1.16), ✅ Test (1.15), ✅ Test (1.14), ✅ Lint, ✅ Test (1.17), ✅ Test (1.16), ✅ Test (1.15), ✅ Test (1.14), ✅ Lint Pull Request URL: #124
1 parent 9ef7636 commit dd719de

11 files changed

+343
-91
lines changed

docs/CHANGELOG.md

+3
Original file line numberDiff line numberDiff line change
@@ -22,10 +22,13 @@ When releasing a new version:
2222

2323
### Breaking changes:
2424

25+
- Previously, `# @genqlient` directives applied to entire operations applied inconsistently to fields of input types used by those operations. Specifically, `pointer: true`, when applied to the operation, would affect all input-field arguments, but `omitempty: true` would not. Now, all options apply to fields of input types; this is a behavior change in the case of `omitempty`.
26+
2527
### New features:
2628

2729
- genqlient's types are now safe to JSON-marshal, which can be useful for putting them in a cache, for example. See the [docs](FAQ.md#-let-me-json-marshal-my-response-objects) for details.
2830
- The new `flatten` option in the `# @genqlient` directive allows for a simpler form of type-sharing using fragment spreads. See the [docs](FAQ.md#-shared-types-between-different-parts-of-the-query) for details.
31+
- The new `for` option in the `# @genqlient` directive allows applying options to a particular field anywhere it appears in the query. This is especially useful for fields of input types, for which there is otherwise no way to specify options; see the [documentation on handling nullable fields](FAQ.md#-nullable-fields) for an example, and the [`# @genqlient` directive reference](genqlient_directive.graphql) for the full details.
2932

3033
### Bug fixes:
3134

docs/FAQ.md

+35-2
Original file line numberDiff line numberDiff line change
@@ -144,7 +144,7 @@ query MyQuery(
144144
}
145145
```
146146

147-
You can also put the `# @genqlient(omitempty: true)` on the first line, which will apply it to all arguments in the query.
147+
You can also put the `# @genqlient(omitempty: true)` on the first line, which will apply it to all arguments in the query, or `# @genqlient(for: "MyInput.myField", omitempty: true)` on the first line to apply it to a particular field of a particular input type used by the query (for which there would otherwise be no place to put the directive, as the field never appears explicitly in the query, but only in the schema).
148148

149149
If you need to distinguish null from the empty string (or generally from the Go zero value of your type), you can tell genqlient to use a pointer for the field or argument like this:
150150
```graphql
@@ -157,7 +157,40 @@ query MyQuery(
157157
}
158158
```
159159

160-
This will generate a Go field `MyString *string`, and set it to `nil` if the server returns null (and in reverse for arguments). Such fields can be harder to work with in Go, but allow a clear distinction between null and the Go zero value. Again, you can put the directive on the first line to apply it to everything in the query, although this usually gets cumbersome.
160+
This will generate a Go field `MyString *string`, and set it to `nil` if the server returns null (and in reverse for arguments). Such fields can be harder to work with in Go, but allow a clear distinction between null and the Go zero value. Again, you can put the directive on the first line to apply it to everything in the query, although this usually gets cumbersome, or use `for` to apply it to a specific input-type field.
161+
162+
As an example of using all these options together:
163+
```graphql
164+
# @genqlient(omitempty: true)
165+
# @genqlient(for: "MyInputType.id", omitempty: false, pointer: true)
166+
# @genqlient(for: "MyInputType.name", omitempty: false, pointer: true)
167+
query MyQuery(
168+
arg1: MyInputType!,
169+
# @genqlient(pointer: true)
170+
arg2: String!,
171+
# @genqlient(omitempty: false)
172+
arg3: String!,
173+
) {
174+
myString(arg1: $arg1, arg2: $arg2, arg3: $arg3)
175+
}
176+
```
177+
This will generate:
178+
```go
179+
func MyQuery(
180+
ctx context.Context,
181+
client graphql.Client,
182+
arg1 MyInputType,
183+
arg2 *string, // omitempty
184+
arg3 string,
185+
) (*MyQueryResponse, error)
186+
187+
type MyInputType struct {
188+
Id *string `json:"id"`
189+
Name *string `json:"name"`
190+
Title string `json:"title,omitempty"`
191+
Age int `json:"age,omitempty"`
192+
}
193+
```
161194

162195
See [genqlient_directive.graphql](genqlient_directive.graphql) for complete documentation on these options.
163196

docs/genqlient_directive.graphql

+47-12
Original file line numberDiff line numberDiff line change
@@ -7,11 +7,12 @@
77
# by the server, not by the client, so it would reject a real @genqlient
88
# directive as nonexistent.)
99
#
10-
# Directives may be applied to fields, arguments, or the entire query.
11-
# Directives on the line preceding the query apply to all relevant nodes in
12-
# the query; other directives apply to all nodes on the following line. (In
13-
# all cases it's fine for there to be other comments in between the directive
14-
# and the node(s) to which it applies.) For example, in the following query:
10+
# Directives may be applied to fields, arguments, or the entire query or named
11+
# fragment. Directives on the line preceding the query or a named fragment
12+
# apply to all relevant nodes in the query; other directives apply to all nodes
13+
# on the following line. (In all cases it's fine for there to be other
14+
# comments in between the directive and the node(s) to which it applies.) For
15+
# example, in the following query:
1516
# # @genqlient(n: "a")
1617
#
1718
# # @genqlient(n: "b")
@@ -39,16 +40,48 @@
3940
# entire query (so "d", "e", and "f" take precedence over "b" and "c"), and
4041
# multiple directives on the same node ("b" and "c") must not conflict. Note
4142
# that directives on nodes do *not* apply to their "children", so "d" does not
42-
# apply to the fields of MyInput, and "f" does not apply to field4.
43+
# apply to the fields of MyInput, and "f" does not apply to field4. (But
44+
# directives on operations and fragments do: both "b" and "c" apply to fields
45+
# of MyInput and to field4.)
4346
directive genqlient(
4447

45-
# If set, this argument will be omitted if it has an empty value, defined
46-
# (the same as in encoding/json) as false, 0, a nil pointer, a nil interface
47-
# value, and any empty array, slice, map, or string.
48+
# If set to a string "MyType.myField", this entire @genqlient directive
49+
# will be treated as if it were applied to the specified field of the
50+
# specified type. It must be applied to an entire operation or fragment.
51+
#
52+
# This is especially useful for input-type options like omitempty and
53+
# pointer, which are equally meaningful on input-type fields as on arguments,
54+
# but there's no natural syntax to put them on fields.
55+
#
56+
# Note that for input types, unless the type has the "typename" option set,
57+
# all operations and fragments in the same package which use this type should
58+
# have matching directives. (This is to avoid needing to give them more
59+
# complex type-names.) This is not currently validated, but will be
60+
# validated in the future (see issue #123).
61+
#
62+
# For example, given the following query:
63+
# # @genqlient(for: "MyInput.myField", omitempty: true)
64+
# # @genqlient(for: "MyInput.myOtherField", pointer: true)
65+
# # @genqlient(for: "MyOutput.id", bind: "path/to/pkg.MyOutputID")
66+
# query MyQuery($arg: MyInput) { ... }
67+
# genqlient will generate a type
68+
# type MyInput struct {
69+
# MyField <type> `json:"myField,omitempty"`
70+
# MyOtherField *<type> `json:"myField"`
71+
# MyThirdField <type> `json:"myThirdField"`
72+
# }
73+
# and use it for the argument to MyQuery, and similarly if `MyOutput.id` is
74+
# ever requested in the response, it will be set to use the given type.
75+
for: String
76+
77+
# If set, this argument (or input-type field, see "for") will be omitted if
78+
# it has an empty value, defined (the same as in encoding/json) as false, 0,
79+
# a nil pointer, a nil interface value, and any empty array, slice, map, or
80+
# string.
4881
#
4982
# For example, given the following query:
5083
# # @genqlient(omitempty: true)
51-
# query MyQuery(arg: String) { ... }
84+
# query MyQuery($arg: String) { ... }
5285
# genqlient will generate a function
5386
# MyQuery(ctx context.Context, client graphql.Client, arg string) ...
5487
# which will pass {"arg": null} to GraphQL if arg is "", and the actual
@@ -161,8 +194,10 @@ directive genqlient(
161194
# type-name in multiple places unless they request the exact same fields, or
162195
# if your type-name conflicts with an autogenerated one (again, unless they
163196
# request the exact same fields). They must even have the fields in the
164-
# same order. Fragments are often easier to use (see the discussion of
165-
# code-sharing in FAQ.md, and the "flatten" option above).
197+
# same order. They should also have matching @genqlient directives, although
198+
# this is not currently validated (see issue #123). Fragments are often
199+
# easier to use (see the discussion of code-sharing in FAQ.md, and the
200+
# "flatten" option above).
166201
#
167202
# Note that unlike most directives, if applied to the entire operation,
168203
# typename affects the overall response type, rather than being propagated

generate/convert.go

+14-13
Original file line numberDiff line numberDiff line change
@@ -164,11 +164,10 @@ func (g *generator) convertArguments(
164164
name := "__" + operation.Name + "Input"
165165
fields := make([]*goStructField, len(operation.VariableDefinitions))
166166
for i, arg := range operation.VariableDefinitions {
167-
_, directive, err := g.parsePrecedingComment(arg, arg.Position)
167+
_, options, err := g.parsePrecedingComment(arg, nil, arg.Position, queryOptions)
168168
if err != nil {
169169
return nil, err
170170
}
171-
options := queryOptions.merge(directive)
172171

173172
goName := upperFirst(arg.Variable)
174173
// Some of the arguments don't apply here, namely the name-prefix (see
@@ -386,19 +385,21 @@ func (g *generator) convertDefinition(
386385
}
387386

388387
for i, field := range def.Fields {
388+
_, fieldOptions, err := g.parsePrecedingComment(
389+
field, def, field.Position, queryOptions)
390+
if err != nil {
391+
return nil, err
392+
}
393+
389394
goName := upperFirst(field.Name)
390-
// There are no field-specific options for inputs (yet, see #14),
391-
// but we still need to merge with an empty directive to clear out
392-
// any query-options that shouldn't apply here (namely "typename").
393-
fieldOptions := queryOptions.merge(newGenqlientDirective(pos))
394395
// Several of the arguments don't really make sense here:
395396
// (note field.Type is necessarily a scalar, input, or enum)
396397
// - namePrefix is ignored for input types and enums (see
397398
// names.go) and for scalars (they use client-specified
398399
// names)
399400
// - selectionSet is ignored for input types, because we
400401
// just use all fields of the type; and it's nonexistent
401-
// for scalars and enums, our only other possible types,
402+
// for scalars and enums, our only other possible types
402403
// TODO(benkraft): Can we refactor to avoid passing the values that
403404
// will be ignored? We know field.Type is a scalar, enum, or input
404405
// type. But plumbing that is a bit tricky in practice.
@@ -414,8 +415,7 @@ func (g *generator) convertDefinition(
414415
JSONName: field.Name,
415416
GraphQLName: field.Name,
416417
Description: field.Description,
417-
// TODO(benkraft): set Omitempty once we have a way for the
418-
// user to specify it.
418+
Omitempty: fieldOptions.GetOmitempty(),
419419
}
420420
}
421421
return goType, nil
@@ -506,12 +506,11 @@ func (g *generator) convertSelectionSet(
506506
) ([]*goStructField, error) {
507507
fields := make([]*goStructField, 0, len(selectionSet))
508508
for _, selection := range selectionSet {
509-
_, selectionDirective, err := g.parsePrecedingComment(
510-
selection, selection.GetPosition())
509+
_, selectionOptions, err := g.parsePrecedingComment(
510+
selection, nil, selection.GetPosition(), queryOptions)
511511
if err != nil {
512512
return nil, err
513513
}
514-
selectionOptions := queryOptions.merge(selectionDirective)
515514

516515
switch selection := selection.(type) {
517516
case *ast.Field:
@@ -705,6 +704,8 @@ func (g *generator) convertFragmentSpread(
705704
}
706705
}
707706

707+
// TODO(benkraft): Set directive here if we ever allow @genqlient
708+
// directives on fragment-spreads.
708709
return &goStructField{GoName: "" /* i.e. embedded */, GoType: typ}, nil
709710
}
710711

@@ -713,7 +714,7 @@ func (g *generator) convertFragmentSpread(
713714
func (g *generator) convertNamedFragment(fragment *ast.FragmentDefinition) (goType, error) {
714715
typ := g.schema.Types[fragment.TypeCondition]
715716

716-
comment, directive, err := g.parsePrecedingComment(fragment, fragment.Position)
717+
comment, directive, err := g.parsePrecedingComment(fragment, nil, fragment.Position, nil)
717718
if err != nil {
718719
return nil, err
719720
}

generate/generate.go

+1-1
Original file line numberDiff line numberDiff line change
@@ -244,7 +244,7 @@ func (g *generator) addOperation(op *ast.OperationDefinition) error {
244244
f := formatter.NewFormatter(&builder)
245245
f.FormatQueryDocument(queryDoc)
246246

247-
commentLines, directive, err := g.parsePrecedingComment(op, op.Position)
247+
commentLines, directive, err := g.parsePrecedingComment(op, nil, op.Position, nil)
248248
if err != nil {
249249
return err
250250
}

0 commit comments

Comments
 (0)