Ben Kraft
dd719deb4e
## 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: https://github.com/Khan/genqlient/issues/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: https://github.com/Khan/genqlient/pull/124
3.7 KiB
3.7 KiB
Changelog
next
Breaking changes:
- Previously,
# @genqlientdirectives 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, butomitempty: truewould not. Now, all options apply to fields of input types; this is a behavior change in the case ofomitempty.
New features:
- genqlient's types are now safe to JSON-marshal, which can be useful for putting them in a cache, for example. See the docs for details.
- The new
flattenoption in the# @genqlientdirective allows for a simpler form of type-sharing using fragment spreads. See the docs for details. - The new
foroption in the# @genqlientdirective 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 for an example, and the# @genqlientdirective reference for the full details.
Bug fixes:
v0.2.0
Version 0.2.0 adds several convenience features for using custom scalars, as well as many internal improvements and bug fixes.
Breaking changes:
- The
graphql.Clientinterface now acceptsvariables interface{}(containing a JSON-marshalable value) rather thanvariables map[string]interface{}. Clients implementing the interface themselves will need to change the signature; clients who simply callgraphql.NewClientare unaffected. - genqlient's handling of the
omitemptyoption has changed to match that ofencoding/json, from which it had inadvertently differed. In particular, this means struct-typed arguments with# @genqlient(omitempty: true)will no longer be omitted if they are the zero value. (Struct-pointers are still omitted if nil, so addingpointer: truewill typically work fine. It's also now possible to use a custom marshaler to explicitly map zero to null.)
New features:
- The new
bindings.marshalerandbindings.unmarshaleroptions ingenqlient.yamlallow binding to a type without using its standard JSON serialization; see the documentation for details. - Multiple genqlient directives may now be applied to the same node, as long as they don't conflict; see the directive documentation for details.
Bug fixes:
- The
omitemptyoption now works correctly for struct- and map-typed variables, matchingencoding/json, which is to say it never omits structs, and omits empty maps. (#43) - Generated type-names now abbreviate across multiple components; for example if the path to a type is
(MyOperation, Outer, Outer, Inner, OuterInner), it will again be calledMyOperationOuterInner. (This regressed in a pre-v0.1.0 refactor.) (#109) - Previously, interface fields with
# @genqlient(pointer: true)would be unmarshaled to(*MyInterface)(*<nil>), i.e. a pointer to the untyped-nil of the interface type. Now they are unmarshaled as(*MyInterface)(<nil>), i.e. a nil pointer of the pointer-to-interface type, as you would expect.
v0.1.0
First open-sourced version.