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
It would be nice if this was exposed directly in the generated fragments file that way it can be referenced in other places in the code that consumes the GraphQL API.
The hardest thing with this approach is that it's hard to combine with Python inheritance I think.
For example, if the query above didn't modify the fragment but added username to the result set in the query, it wouldn't be possible to inherit from the union to extend the type with the additional username field. This library doesn't currently use inheritance for that anyway,,, but,,, yeah.
Just ran into this issue and though I could post this for posterity at least.
The text was updated successfully, but these errors were encountered:
I agree with the usecase for this, but I am marking this as "decision needed" because its something that I have no idea currently how we can achieve in the codegen.
Currently, creating a fragment on an interface type generally results in that type being "inlined" into the Pydantic models where they're used.
results in the generated code akin to
(i've omitted some of the less interesting bits)
It would be nice if this was exposed directly in the generated fragments file that way it can be referenced in other places in the code that consumes the GraphQL API.
The hardest thing with this approach is that it's hard to combine with Python inheritance I think.
For example, if the query above didn't modify the fragment but added
username
to the result set in the query, it wouldn't be possible to inherit from the union to extend the type with the additionalusername
field. This library doesn't currently use inheritance for that anyway,,, but,,, yeah.Just ran into this issue and though I could post this for posterity at least.
The text was updated successfully, but these errors were encountered: