String Enum Initializer

[thomasmost]

String Enum Initializer

A more typesafe and succinct way of defining enum types that compile to strings

Search Terms

enum, string, string enum
default value
initializer
infer

Proposal

It seems like you should be able to specify that you are using a string enum, and then you'd only have to write out the 'value' once, and it would be automatically made into a string matching the enum code.

enum<string> Action {
   LOAD_PROFILE,
   ADD_TASK,
   REMOVE_TASK
}

or

enum Action: string {
   LOAD_PROFILE,
   ADD_TASK,
   REMOVE_TASK
}

instead of

enum Action {
   LOAD_PROFILE = "LOAD_PROFILE",
   ADD_TASK = "ADD_TASK",
   REMOVE_TASK = "REMOVE_TASK"
}

Thanks for all the great work!

EDIT
Recently updated to reflect variations proposed by @imcotton here and @lostpebble here; as well as search terms proposed by @KennethKo (#36319) and @garrettmaring (#33015)

[imcotton]

like this?

enum Action: string {
    LOAD_PROFILE,
    ADD_TASK,
    REMOVE_TASK,
}

[thomasmost]

That would be perfect!

[pradyuman]

This would be super great - any updates on this?

[lostpebble]

Yep, this would be a really great addition.

See this comment on the original pull request which brought string enums to Typescript.

Also mentioned in that thread was the syntax of enum<T = number> to describe enums. I think this syntax works quite nicely. So for strings we might have:

enum<string> TaskIds {
   TASK_RESIZE_IMAGE,
   TASK_ADD_PROFILE_PIC,
   TASK_DELETE_USER,
}

[thomasmost]

yup, I'm about this

[thomasmost]

Hey, can we get an update on this? TypeScript 2.9 just came out and honestly it's a little frustrating that we've gone 4 minor releases without any progress reported to this ticket...

[RyanCavanaugh]

The status on this is the same as it was before

[thomasmost]

@RyanCavanaugh What additional Feedback are you looking for (referencing 'Awaiting More Feedback')?

[RyanCavanaugh]

This label means we'd like to hear from more people who would be helped by this feature, understand their use cases, and possibly contrast with other proposals that might solve the problem in a simpler way (or solve many other problems at once).

[lostpebble]

@RyanCavanaugh This is pretty much as simple as its gonna get. We'd just like a way to define string enums without having to repeat everything. I'm not sure what other feedback you require to push through a new feature? Is there just perhaps not enough activity pushing for this?

I think the team should maybe weigh in a bit on what they think on the current proposal, and if there are issues we can move on from there.

I do foresee a slight issue with what I wrote earlier in the thread:

enum<T = number>

This won't interact nicely with the current way string enums work, and I'm sure whichever method is chosen it would have to be backwards compatible.

number being the default technically means this would be possible with the current implementation:

enum<number> {
   SOMETHING = "SOMETHING",
   ELSE = "ELSE"
}

Also, it seems like because of the way its currently implemented that using the enum<T> method is a bit difficult and might be ambiguous - because if someone happens to change enum<string> to just plain enum, the actual data type will change completely but it might not be very obvious.

But would be nice if the team could weigh in on a way they might envision this as well.

[RyanCavanaugh]

We're always looking at things holistically. There are over 1,000 open suggestions and it would be a complete disaster to just do all of them; features need to more than pay for themselves in terms of new complexity vs value added.

We have to consider questions like:

• Does this enable you to do something you couldn't do before?
  • No - it's pure sugar
• If not, is the existing way of doing it truly burdensome, or just a bit annoying?
  • It's just annoying
• How many people are affected by the feature not existing?
  • The answer appears to be 13ish?
• Could this be solved in some other way, such as tooling?
  • "Convert numeric enum to string enum" refactoring would be trivial to write; we should consider doing that instead
• Is there strong precedent from other languages implying a need here?
  • No
• Are there frameworks or libraries whose patterns are greatly simplified by it?
  • No (?)

The bar is much higher than you probably think it is - once something goes into the language, we can't take it out, and everything that exists is something that future TS learners will need to understand. Features at the language level need to feel like "the thing we've been missing all along", not "this would be nice".

[thomasmost]

I want to emphasize that I understand and agree with everything you're saying; I don't expect TypeScript to change at the whim of a few users, however I think some of your thinking is overly dismissive.

For example, you say that there is "no strong precedent from other languages implying a need," but I would argue that this is inherent to the concept of an enum. Having to define each state of the enum twice, and potentially introducing conflicts where two enum values correspond to the same string, flies in the face of an enum's existential purpose. From that perspective, this isn't just annoying; it's a fundamental flaw in the initial implementation.

Once again, I completely understand the challenge of maintaining a language used by thousands in a scalable way, but please remember that we're all here because we love TypeScript and we should be working towards the best solution together.

Speaking of which, you say that, "'Convert numeric enum to string enum' refactoring would be trivial to write; we should consider doing that instead" -- but I'm not 100% sure what you mean by that. Is this something we can do in our own codebases? Do you mean just adding a post-transpile hook that changes all the enum values to strings?

Thank you again for all you do.

[icholy]

@thomascmost what's your use-case?