My project uses unions that are quite large, so I import the fragment types to have access to __typename -- appreciate that inclusion by the way. For me, __typename is a wonderful convenience to switch over, and this...

is a lot kinder to interact with than this...

Describe the solution you'd like
Add (an option to include) __typename in the base [Typescript] plugin.
Describe alternatives you've considered
Using SomeTypeFragment instead of SomeType. It's not a fun solution 馃槩
Hi @awdyson !
There is an open PR for that: https://github.com/dotansimha/graphql-code-generator/pull/1701 , created by @jefflewis. I believe we'll merge it in a few days, the reason it takes time to merge is because we will need some more changes and tests.
Waiting for this as well! Use case is the same: unions are not possible to discriminate without __typename. Thanks!
__typename being typed as optional? In another PR (#1062) it looks like work was done to make it non-optional when it's explicitly requested. Internally it looks like #1701 is effectively adding it to the selection set I'd expect it to be non-optional.My use case is that I use Apollo which automatically adds __typename to queries by default (https://www.apollographql.com/docs/react/advanced/caching#configuration). I'm not able to generate proper typings for those queries as it stands.
Perhaps an additional config option to generate __typename as non-optional is warranted?
Hi @cecchi
Basically, the __typename in typescript-operations is being added automatically for all queries, but as optional, because we don't want to assume that all GraphQ clients adds __typename (Apollo does, but not all clients does that).
If you'll add __typename fields to your selection set, it won't be optional.
The #1701 PR adds __typename as optional, but we wanted to wait a bit before releasing a new version for stabilize and test it.
I think now that we have the ability to add __typename to typescript package, we should have an option to make it non-optional fields, by setting nonOptionalTypename: true and it will also be available in typescript-operations (so Apollo users will be able to set it and get __typename without adding it to all their queries).
@cecchi what do you think about that?
@dotansimha that sounds perfect. I'll see if I can put together a PR this weekend.
Available in 1.2.0.
Most helpful comment
Hi @cecchi
Basically, the
__typenameintypescript-operationsis being added automatically for all queries, but as optional, because we don't want to assume that all GraphQ clients adds__typename(Apollo does, but not all clients does that).If you'll add
__typenamefields to your selection set, it won't be optional.The #1701 PR adds
__typenameas optional, but we wanted to wait a bit before releasing a new version for stabilize and test it.I think now that we have the ability to add
__typenametotypescriptpackage, we should have an option to make it non-optional fields, by settingnonOptionalTypename: trueand it will also be available intypescript-operations(so Apollo users will be able to set it and get__typenamewithout adding it to all their queries).@cecchi what do you think about that?