Add __typename to base TS and flow types

[jefflewis]

As seen in these issues, __typename being included in the base type will help with comparing types returned by unions.

• Suggestion: Allow __typename in types returned by resolvers #1633
• [TypeScript] Add __typename to typings #649

I hooked into the skipTypenames configuration flag. If undefined or false, __typename will be generated as an optional type in base types.

[dotansimha]

Hi @jefflewis , thank you for your contribution!
I'll review it very soon.

[kamilkisiela]

Maybe we should make skipTypename: true by default?

[kamilkisiela]

And maybe __typename should be only defined in interfaces?

[dotansimha]

@kamilkisiela why only for interfaces? I think we can add it for types as well.
My only concern is that now we should use Pick with __typename instead of manually adding it. But maybe we can do it after merging this PR.

[jefflewis]

@kamilkisiela Adding __typename to the generated type is just as important here. Many of my generated GQL types are included in unions. Not having typename for these is exactly what I'm trying to fix.

@dotansimha I was unsure of a good way to refactor this to use a Pick, or to make it non-optional (note how the read-only flow type is not being used here) as I was also unsure of how to get that addressed.

It seems that both could be addressed in a future commit. Anyone needing typenames would be helped by this. and adding skipTypename: false would get the current behavior. It seems changing the default would be okay, but would similar "break" people's configs since the default is already true for operation types.

[kamilkisiela]

@jefflewis ok, seems reasonable.

About the default, I think since graphql-js doesn't add __typename property, that's what the developer does, then we shouldn't show it to people, it might be misleading.

{
  users: (parent, args, context, info) {
    // parent.__typename is accessible but undefined
  }
}

[jefflewis]

@kamilkisiela I'm not sure I understand what you mean here...

If __typename is output in the generated type, it will be accessible and defined. If the config is set to not generate, it will not be accessible or defined.

Changing the default to not generate __typename seems fine, but there's a lot more code to refactor to accomodate that change, since skipTypename is used in the typescript-operations plugin. Either way is fine with me, since all I need is to get the typename into the generated types! 😄

[jefflewis]

I had to rebase after all of the packages moved into folders...

[cris-santos]

skipTypename is already on the docs (https://graphql-code-generator.com/docs/plugins/flow-operations) but the flow definitions aren't being generated with __typename. Am I missing something or it's not working because this PR is still open?

[tokenvolt]

@cristianosantos95 this is for GraphQL operations, i.e. query, mutation, subscription and fragment, but not for the GraphQL types.

[jefflewis]

Is there anything I need to change about this before it gets merged and released? I'm more than willing to update the PR with any necessary changes.

[cris-santos]

@tokenvolt you mean this pull request or the one that's on the docs? Either way, none of my generated definitions have __typename (GraphQL operations and types). Is there a way to add it?

[tokenvolt]

@cristianosantos95 on the docs. This PR adds __typename to GraphQL objects as well.

[vasilich6107]

Hi! Thanks for library and PR.
I’m awaiting of this PR to be merged)

[dotansimha]

Hi @jefflewis , Sorry for the delay, I hope I'll find the time to merge it in the next days.

[jefflewis]

No worries @dotansimha! Ping me if you need me to make any changes.

[Jonatthu]

@jefflewis Is this helping or related to this issue?
#643 (comment)

[andreyvital]

@dotansimha sorry to push on this, but do you have an expectation of when to merge this PR? I'm not getting __typename in the generated definitions for TS. Thanks!

[beeequeue]

We are also waiting eagerly for this PR to be merged and released, we need it to migrate from Apollo's type generation

[dotansimha]

Hi all, sorry for the delay. I'm rebasing this PR manually now, and then I'll merge it to master. It still requires some changes because we need now to Pick<> the __typename as well, so it might take a bit more time (a day or so maybe) to have a stable release with it.

[dotansimha]

I think, at the moment, I'll merge it as-is to allow the base plugins to add __typename, and x-operations plugins will add __typename by themself (like we do today).
The reason for that is might be a bit more complicated to do Pick<Type, '__typename'> when __typename? is optional, and then to remove the optional sign from it (in case the query contains __typename explicitly).
Everything should work as-is, and maybe in a future release we'll use Pick to get the __typename as well (it's just an optimization, so it's not required at the moment).

@jefflewis I did some minor changes to your PR (moved the __typename logic from DeclarationBlock to the BaseVisitor because I wanted it to be generic as possible).

Making sure now that everything works, and then I'll merge it :)

[lookfirst]

this should be readonly __typename

[dotansimha]

You are right, thanks.