enums are usually nicer than literals for two reasons:

You can use the TS language service to refactor rename them across your workspace.
If you're not basing the enum of an external API, you can make them opaque (i.e. don't provide a value) - meaning people can't accidentally use literals in comparisons, etc
- using literals is really hard to refactor, and can cause bugs if you're not careful

Example:

enum StrFoo {
    a = 'a'
}
const y: StrFoo = StrFoo.a;
if (y === 'a') {  // is compile-time safe, but hard to refactor
    
}

enum NumFoo {
    a = 1
}
const z: NumFoo = NumFoo.a;
if (z === 1) { // is compile-time safe, but hard to refactor
    
}

enum Foo {
    a
}
const x: Foo = Foo.a;
if (x === 'a') { // is NOT compile-time safe
    
}

repl

If you refactor enum names or adjust the values, then you can very easily create subtle bugs that are type safe

 enum NumFoo {
-   a = 1
+   a = 0
+   b = 1
 }
 const y: NumFoo = NumFoo.a;
 if (y === 1) {  // this check is compile-time correct, but the logic is now broken because we've changed the enum values.
     
 }

There's a big reason that the flow team is scrambling to add enums to their language - because using string literals and string unions is really, really clunky and causes you to have to write a lot of unnecessary code.

Uh oh!

Rule proposal: Const enum #280

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions