You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
final typeDef =getTypeDefinitionNode(
schemaSource.document,
type,
)!;
final typeNode =_getFieldTypeNode(
typeDef,
node.name.value,
);
we only get the type definition node for the type A the is queried, but the selection may come from a fragment that is on a subtype B of A
So, when we lookup the queried field in A, we can't find it, as it is only in B.
We need to check the selections list for FragmentSpreadNode, and use the type from that FragmentSpreadNode instead when possible.
Edge cases to think about:
what if selections occur with different types in different fragment spread nodes? the "right" way to handle is is probably the generate the same code as if the user explicitly used type conditions
Assume the following schema :
And now, in your app, you query it like
Building the following will result in
Until this is resolved, a workaround is to wrap your fragment with the type condition :
In case it's useful, source of graphql manifest : https://spec.graphql.org/October2021/#sec-Type-Conditions
The text was updated successfully, but these errors were encountered: