-
Notifications
You must be signed in to change notification settings - Fork 70
Adding __typename on a interface field generates generates string type instead of union type with constant strings #190
Comments
Maybe I’m missing something, but shouldn’t you declare the union type within your schema? Something like: union DiceRollDetail =
DiceRollDiceRollNode
| DiceRollConstantNode
| DiceRollCloseParenNode
type DiceRoll {
result: Float!
detail: [DiceRollDetail!]!
} |
@renanmav Why use a union type instead of an interface type? It makes it utterly complicated when selecting only the shared fields (such as Interface fragment formattedDiceRoll_diceRoll on DiceRoll {
result
detail {
__typename
content
}
} vs Union fragment formattedDiceRoll_diceRoll on DiceRoll {
result
detail {
... on DiceRollOperatorNode {
__typename
content
}
... on DiceRollConstantNode {
__typename
content
}
... on DiceRollOpenParenNode {
__typename
content
}
... on DiceRollCloseParenNode {
__typename
content
}
... on DiceRollDiceRollNode {
__typename
content
}
}
} |
I’m not very experienced with union types, but the last snippet seems more explicit, and one of relay’s purposes is explicit data requirements. |
How does the generated code and your expected output align up with how Relay for flow works? I know we've had some issues regarding this in the past, but I think we should generate the code the same way the official implementation works (I'm not saying that is what is happening now, but there has been bugs both in the official implementation and in ours). Can you do comparisons with the flow based implementation and see if there's any differences there? If there is then it is definitely a bug that we should look into fixing. |
@n1ru4l I love this idea! Would make conditional's type-safe as well. If we get a consensus we should look at implementing it. @kassens @josephsavona @jstejada can you give us some guidance if this is even a good idea, as we'd love this to make into relay-compiler (rust) as well. |
Until recently this wasn't feasible, since Relay didn't know at runtime which types implement which interfaces. We changed that with the new precise type refinement feature, so that we dynamically query this information as necessary. We expect to enable that feature by default in an upcoming release at which point we can start generating more precise types for interfaces (ie as suggested here, instead of making all fields on the interface result value optional, generate a union with non-optional fields). However, we're also looking at alternatives to So: we're not quite ready to do this yet, but agree w the direction. |
@josephsavona Can you give us any update on this and the open PR #192 that seems to resolve this? |
This is in our backlog. It's a major change to the way we produce types and we can't simply flip a switch here, we need to figure out an upgrade path. |
Thanks for the info @josephsavona keep us posted 😀 |
@josephsavona Our team our Prisma would be interested in contributing a solution here. Let me know what potential there is for that, we use result types in our API and so rely on this feature heavily (we're migrating from genql). |
Schema Types:
Generated Type:
Expected Generated Type:
HOWEVER:
The following will generates the correct types:
Fragment Container:
Generated Code:
But this is how I expect union types to work. IMHO interface fields should not require that much boiler plate code.
GraphQL Codegen supports generating the "correct" interface selection set typings.
The text was updated successfully, but these errors were encountered: