-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: implemented Interface not working nor properly typed #351
Comments
I agree, I also need this functionality. type Query {
entity(id: ID!): Node
} If I query for this fragment: {
entity: [
{ id: "" },
{
__typeName: true,
id: true
}
]
} the return typescript type should work even without using |
should work in 5.2.2 |
Hi @aexol, thanks for your hard work on this! I just tried using the API, but it didn't seem to work for me. Could you provide some guidance on how to use it correctly, or let me know if there's something I might be missing? Thanks in advance for your help! PS: I was thinking of this: https://graphql.org/learn/schema/#union-types, where it states that: "Also, in this case, since Human and Droid share a common interface (Character), you can query their common fields in one place rather than having to repeat the same fields across multiple types: |
could you provide me with your Zeus generated files? I can debug |
I see your output is correct right now. |
I see now you meant unions sharing an interface |
I can think about it of course. Meanwhile, it would help if you typed fields for each union member. Now, this feature works only if you return the interface from the field. I can think of applying the exact mechanism to unions. |
that's right, when you return an interface, it works as expected. However, when some or all members of a union implement the same interface, it should be possible to use the interface and get a union of the concrete types with only the fields defined in the interface and the __typename of the respective concrete types 🤔 |
Problem
inline fragment
with theinterface
name instead of theconcrete types
themselves. This is very useful when doing error handling and you don't want to specifically have to handle each case or manually update new error types on the client side. e.g https://blog.logrocket.com/handling-graphql-errors-like-a-champ-with-unions-and-interfaces/Example issue:
Below should allow interface
![Screenshot 2022-12-01 at 2 57 10](https://user-images.githubusercontent.com/31687368/204940625-8fcf22e2-5d6c-4b03-b6f2-66f5f0c992ed.png)
Node
inline framgenet to get the common field -Id
i.e...on Node { id true}
Example schema:
The text was updated successfully, but these errors were encountered: