Ben KraftandGitHub
3a5bf46da4
## Summary: If your type implements an interface, we add getter methods for the shared fields, so that those may be accessed via the interface. But it turns out occasionally it's useful to have these getter methods when they don't implement a GraphQL interface, so you can use two genqlient-generated types in the same function if they have the same fields. (This comes up most often when you have a GraphQL union that maybe should really be an interface, or if you don't yet support interfaces implementing other interfaces (indeed our parser doesn't either). But one can imagine other use cases.) We can't predict how you want to do that, so we can't generate the interface, but we can generate the methods, so you can define the interface and do a type assertion from there. Since these methods are pretty simple to generate, we just do it always. (As with #120, if binary size becomes an issue we could later add an option to only generate methods that are truly needed but including them seems like the better default.) This also fixes a subtle and rare bug, which would have become much more common (indeed existing tests caught it). Specifically, if you have a query like ```graphql fragment FragmentOne on T { id } fragment FragmentTwo on T { id } query Q { f { # interface type T ...FragmentOne ...FragmentTwo } } ``` since both `FragmentOne` and `FragmentTwo` request some common field, say `id`, we generate a method `GetId` on each one. But since `FragmentOne` and `FragmentTwo` are both on `T`, we also include their interfaces in the interface we generate for the type of `f`, `QFT`. So `QFT` includes a method `GetId`. But on the implementations, the two methods conflict, and neither gets promoted; this causes various code to fail to compile. With this change, this would have happened much more frequently -- even if only one of the two fragments is on `T`, as long as both request the field. Anyway, we now generate explicit methods on each struct for all of its recursively emebedded fields -- using the logic from #120 to compute them -- so that we don't need to rely on method-promotion. ## Test plan: make tesc Author: benjaminjkraft Reviewers: csilvers, dnerdy, aberkan, jvoll, mahtabsabet, MiguelCastillo, StevenACoffman Required Reviewers: Approved By: csilvers, 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/126
4.4 KiB
4.4 KiB
Changelog
next
Breaking changes:
New features:
- genqlient now generates getter methods for all fields, even those which do not implement a genqlient-generated interface; this can be useful for callers who wish to define their own interface and have several unrelated genqlient types which have the same fields implement it.
Bug fixes:
- In certain very rare cases involving duplicate fields in fragment spreads, genqlient would generate code that failed to compile due to duplicate methods not getting promoted; genqlient now generates correct types. (See #126 for a more complete description.)
v0.3.0
Version 0.3.0 adds several new configuration options, allowing simplification of generated types and configuration of input types, as well as marshalers for all genqlient-generated types.
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.