Ben Kraft
f4c981031e
## Summary: When genqlient generates output types, it generates whatever code is necessary to unmarshal them. Conversely, when it generates input types, it generates whatever code is necessary to marshal. This is all that's needed for genqlient itself: it never needs to marshal output types or unmarshal input types. But maybe you do! (For example, to put the responses in a cache, which is the use case that @csilvers hit at Khan, although there are others one can imagine.) While we can't support every serialization format you might want (at least not without adding plugins or some such), it's not unreasonable to expect that since genqlient can read JSON, it can write it too. Sadly, in the past this was not true for types requiring custom unmarshaling logic, for several reasons. In this commit I implement logic to always write both marshalers and unmarshalers whenever they're needed to be able to correctly round-trip the types, even though genqlient doesn't do so. I wasn't starting from scratch, since of course we already write both marshalers and unmarshalers in some cases. But this ended up requiring surprisingly large changes on the marshaling side, mostly to correctly support embedding (which we use for named fragments). Specifically, as the comments in `types.go` discuss, the most difficult issue is spreads with duplicate fields, which translate to Go embedded fields which end up hidden from the json-marshaler. Ultimately, I had to do things quite differently from unmarshaling, and essentially flatten the type when we write marshaler. But in the end it's not so ugly -- indeed arguably it's cleaner! Mainly it's just different. One thing to note is that we do marshal `__typename` based on what we know about the types; users need not fill it in (and if they do we'll ignore it). This seemed to me to be a better UX, and didn't add much complexity. In general, I begin to wonder whether using `encoding/json` at all is really right for genqlient: we're doing a lot of work to appease it, despite knowing what our types look like. I think it would still be a significant increase in lines of code to roll our own, but that code would perhaps be simpler, and would surely be faster (although if we just want the speed gains we could use another JSON-generator library, see also #47). Anyway, something to think about in the future. ## Test plan: make tesc Author: benjaminjkraft Reviewers: csilvers, StevenACoffman, benjaminjkraft, dnerdy, aberkan, jvoll, mahtabsabet, MiguelCastillo Required Reviewers: Approved By: StevenACoffman, dnerdy 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/120
2.6 KiB
2.6 KiB
Changelog
next
Breaking changes:
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.
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.