Graphql-code-generator: Add `__typename` to [Typescript], not just [Typescript Operations]

Created on 6 May 2019  路  6Comments  路  Source: dotansimha/graphql-code-generator

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...
image
is a lot kinder to interact with than this...
image

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 馃槩

enhancement plugins waiting-for-release

Most helpful comment

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?

All 6 comments

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!

1701 is now merged, but using the latest alpha I still do not get the behavior I was hoping for. What's the historical reason for __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.

Was this page helpful?
0 / 5 - 0 ratings