Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

apollo client:codegen Option for different TypeScript enum output #1044

Open
rautenrieth-da opened this issue Feb 23, 2019 · 6 comments · May be fixed by #1750
Open

apollo client:codegen Option for different TypeScript enum output #1044

rautenrieth-da opened this issue Feb 23, 2019 · 6 comments · May be fixed by #1750
Labels
🤖 component - codegen related to the codegen core packages

Comments

@rautenrieth-da
Copy link

Currently, the following GraphQL type

enum Color {
  RED
  BLUE
}

generates the following TypeScript type

export enum Color {
  RED = "RED",
  BLUE = "BLUE",
}

I would like to have the option to generate the following type instead:

export type Color = "RED" | "BLUE";

This definition provides the same safety, but is more efficient and works better with TypeScript structural typing.

Unrelated: consider generating const enum instead of enum.

@mike-marcacci
Copy link
Contributor

Related:

@slorber
Copy link

slorber commented Sep 18, 2019

+1, having an enum is annoying for me. I don't want to import the enum and to Enum.Value, I just want to use string literals, it's as safe as enums and works nicely

@RyanCavanaugh
Copy link

#247 was a mistake IMO. String enums should only really be used when you want the underlying string value to be opaque, and that isn't a feature that GraphQL can provide. This would maybe be a good idea if you could produce stable key names, but the key names are going to change just as often as the string values themselves, so there's no point.

@Jessidhia
Copy link

String enums still have a slight advantage in that you can find all usages of it. String constants actually can be searched by "find all usages", which was a nice surprise (:tada:), but typescript can't distinguish "intentional" uses from "coincidental" uses of a given string constant -- the string enums work to disambiguate them, especially if there are multiple different enums in your schema that happen to partially overlap in some of the values; it would be good to know which enum is being referred to when the value appears in code.

I think this might be mitigated by the planned "unique types" feature, but I haven't seen if it can be made to work for this use case.

@rohit-gohri
Copy link

export type Color = "RED" | "BLUE";

These also work better if you have a js codebase and are using checkjs, there is no way (AFAIK) to import and use the typescript enum.

@grantila grantila linked a pull request Jan 9, 2020 that will close this issue
4 tasks
@grantila
Copy link

I've fixed this in #1750 🙄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🤖 component - codegen related to the codegen core packages
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants