Apologies I’m on my phone now so I can’t construct an example of the coercion scenario I’m talking about. I believe the idea is that if you return like
[%{foo: 1}, 1, %{foo: 2}]the middle integer cannot coerce to an object, so you get an error.
This seems right to me.
A naive implementation of my scenario would look like this:
object :entity do
field(:text, do: resolve(fn parent, _, _ -> {:ok, String.upcase(parent.text)} end)
end
object :create_entities_payload do
field(:entities, list_of(:entity))
end
object :mutation do
field :create_entities, :create_entities_payload do
resolve(fn _, _, _ -> {:ok, %{entities: [%{text: "hi"}, nil]}})
end
end
The mutation operation would look like this:
mutation SomeMutationOperation {
createEntities {
entities {
text
}
}
}
The response in this case would be:
%{"data" => %{"createEntities" => [%{"entities" => [%{"text" => "HI"}, nil]}]}}
In other words, the field resolvers for entity are called for each element in the entities list, which in this case uppercases the value of text. Is this not resolution?
UPDATE:
@benwilson512 I think I see the problem I’m having. In order to create the response I want, I’d need to have data at createEntities.entities and also errors whose paths are createEntities.entities. In my example above, the error path would be createEntitites.entities.text if the text resolver returned an error.
It does seem unfortunate that the spec has this limitation in the case of a field whose value is a list of nullable types, though. The inability to return a list that describes partial success and also return error describing the failures leads to workarounds like returning errors as data, which IMO violates the spec.
We’ll probably end up doing what you suggested; that is, returning a list of payload types instead of a single payload type whose fields are lists. Thanks for the discussion.
