Replies: 1 comment 2 replies
-
|
If the child field is optional, you can represent it by making the child field optional in the schema: Then, if you are using codegen, you can specify Hope that helps. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
I have what I hope is a simple question. Consider the following schema:
...and the following kotlin classes, perhaps code-generated from the schema:
Assume it's expensive to compute the child. We implement it via a separate resolver, making sure that it won't be invoked unless requested. That would look something like this:
Kotlin rightly rejects this -- we can't construct
Parentwithout providing aChildin theparentresolver. The obvious "fix" is to make the child nullable in our schema, but that doesn't actually correctly reflect the domain model in this case.So what's the recommended approach? Should we be constructing trivial
Childs on the parent's field resolver, perhaps mocking them? For lists, it's easy enough to provide an empty list, but most non-trivial objects will require data to construct. This feels like a common situation. Would appreciate any pointers!Beta Was this translation helpful? Give feedback.
All reactions