Are enums really for JavaScript?

[theScottyJam]

I feel like, as a JavaScript community, we keep asking for enums because it's what every other language has, and we run into lots of problems that would be solved by enums. But I'm not sure we really want them in the language. The primary problems enums are intended to solve we've learned how to solve in other ways. Dedicated enum syntax is, in many ways, a clunkier way to solve the problem we already know how to solve.

I'm going to start by speaking from a TypeScript perspective.

TypeScript already has excellent enum support, and no, I'm not talking about their enum syntax. I'm talking about union types.

type TrafficLightState = 'RED' | 'YELLOW' | 'GREEN';

function getState(): TrafficLightState { ... }

console.log('Stop?', getState() === 'RED');

Now lets throw in the proposed enum syntax.

enum TrafficLightState {
  RED = 'RED',
  YELLOW = 'YELLOW',
  GREEN = 'GREEN',
}

function getState(): TrafficLightState { ... }

console.log('Stop?', getState() === 'RED');
// Or if you really wanted to, but there's no reason real to do it
console.log('Stop?', getState() === TrafficLightState.RED);

I know it's early days for syntax discussion, but if the currently proposed enum syntax stays the same, then personally I wouldn't use it in my own code - unions are much more terse. Technically the enum syntax has the advantage that it's a runtime value that you can iterate over, but in practice it's extremely rare for me to need that capability.

Speaking from a non-TypeScript perspective, it's common to use objects in place of enums as a way to self-document the available enum values.

const trafficLightState = {
  RED: 'RED',
  YELLOW: 'YELLOW',
  GREEN: 'GREEN',
};

If I use enum syntax, then I get the benefit of the object automatically being non-extensible, which is cool, but also, meh. It's not like preventing extension on these objects is all that important when I'm not doing the same thing on anything else in my codebase. Or, maybe I am freezing/preventing-extension all over the place, in which case it's not that much trouble to do it on the enum-like objects as well.

Conclusion

Perhaps we don't need to be like other languages. We don't really need enum types. What we already have seems to be working really well, so well in fact that dedicated enum syntax actually feels inferior to use.

[ljharb]

Re your code comment, the reason to do it is that repeating a static string in any codebase that represents the same concept is a smell - it's bad code. With or without enums, if you don't do something like TrafficLightState.RED, then you're writing bad code and you should feel bad.

[ReinsBrain]

@theScottyJam - i recall reading that form of argument against enums in ecmascript before some years back - don't remember where. while i have always preferred that ecmascript have enum syntax, i did acknowledge at the time that we could simply get away with using an object in place of enum and things would generally work similarly. but now with type stripping becoming a real thing, that argument is holding less and less weight. i feel that the tides are turning regarding the importance of enum in ecmascript. the unioned type you are suggesting we settle for looks a bit hacky to me and i still would much prefer enum.

[theScottyJam]

Re your code comment, the reason to do it is that repeating a static string in any codebase that represents the same concept is a smell - it's bad code. With or without enums, if you don't do something like TrafficLightState.RED, then you're writing bad code and you should feel bad.

Why? Do you think you can back that up a bit?

[ljharb]

Sure!

If you have a bunch of hardcoded strings littered throughout your app, especially with common words like "red", you run the likely risk of having two different "concepts", both of which are represented by the same string, but semantically have different meanings. That ruins greppability and debuggability of your codebase, as well as refactorability.

Things are much simpler when it's clear which "red" is being used in a given context. It's the same reason nominal typing has more value in some cases than structural typing.

[theScottyJam]

If it's not a TypeScript codebase, I would agree - it's important to have a physical object to constantly be referring to, as that's the only way you have to hint what type the thing is.

But in a TypeScript codebase, well, there's a balance between how much explicit type information should be shown vs how much should be inferred. For example, we don't tend to write the following:

const user: User = createUser();

We just write

const user = createUser();

even though the former improves greppability and makes it extremely obvious, at a glance what the type of user is. Why do we do the latter instead? Because we've decided it's better to reduce the noise - you can always hover over user to see what the type is, and TypeScript still provides you with type safety if you ever need to update references to the User type.

To me,

console.log('Stop?', getState() === 'RED');
// vs
console.log('Stop?', getState() === TrafficLightState.RED);

is exactly the same. It's not worth it to explicitly call out the type TrafficLightState in your code when you can easily hover over getState() to see that it returns the type TrafficLightState. You still get the same type safety from TypeScript either way if you do need to refactor that enum/union type in some fashion. All we're doing is hiding type information in the code behind tooltips - really close if you need it, but out of the way when you don't.

[ljharb]

That's still not greppable, though - types don't change that.

[vjau]

When creating an object literal, how do you ensure that the string literal you used validates against the possible values ?

const randomObj = {
  foo: "bar",
  trafficLightColor : "yelow", //typo
}

You can use satisfies

const randomObj = {
  foo: "bar",
  trafficLightColor : "yelow", //error
} satisfies RandomObj;

But while useful, it's not really ergonomic since you loose autocomplete.

With the namespaced enum, you can't mess up

const randomObj = {
  foo: "bar",
  trafficLightColor : TrafficLightState.YELLOW
} 

[theScottyJam]

Huh, I guess that's true. Though in practive, I've never ran into that issue despit making many, many enums using union types. I guess most of the time I'm using enums, I'm using them with objects that have a known, shared type, so I can just do:

const randomObj: RandomObj = { ... }

I'll point out that this isn't necessarily a flaw in JavaScript. The issues you're describing are purely TypeScript-related issue - "no type safety" and "no autocomplete". This issue would also exist with any union type, not just enums. For example:

type Responses = { type: 'ok', value: number } | { type: 'notFound' };

const randomObj = {
  fromServer: true,
  response: { type: 'notFound' } // <-- How do you make sure this conforms to the Responses type?
};

You could use satisfies, but you don't get autocompletes.

TypeScript could introduce a fix for this problem. For example, I've always disliked how "as" can both auto-narrow a type (number -> 2) or auto-widen a type (2 -> number). It means "as" can cause unsafe assumptions to be made if used wrong. I wished there was a version that could only widen, not narrow, making it a completely type-safe version. So we can get auto-complete of the possible values, I'll also switch the order of the operands so you provide the type first. I don't care much what the actual syntax is - I'll demonstraight using &<type> value syntax. You'd get:

// Type narrowing
const n: number = 2;

return n as 3; // This won't fail despite being incorrect
return &<3> n; // Error: Cannot narrow a type with "&<...>" syntax

// Type widening
const n: 2 = 2;

return n as number; // Valid
return &<number> n; // Valid

This would cleanly solve the problem you brought up as well, in the seemingly rare cases we do run into that sort of issue.

type TrafficLightState = "RED" | "YELLOW" | "GREEN";

const randomObj = {
  foo: "bar",
  trafficLightColor: &<TrafficLightState> "YELLOW",
};

And for people who find it valuable to have this information easiliy greppable, they could use &<...> every time they use an enum value, instead of only where it is strictly necessary.

[ljharb]

That would only help TypeScript users, though. The point of proposals is to help JavaScript users, whether they use TypeScript or not.

[theScottyJam]

The primary issues I was responding to in that last comment, "lack of auto-complete" and "not type-safe" are TypeScript specific issues, hense why I proposed a TypeScript-specific solution.

If we shift gears and focus on enums without TypeScript, then I'd go back to what I said in my original post:

Speaking from a non-TypeScript perspective, it's common to use objects in place of enums as a way to self-document the available enum values.

As currently proposed, this enum syntax isn't that much different from doing a simple const myEnum = Object.freeze({ ... }). The one main feature I see that it adds is the "Referring to prior enum members of the same enum in the initializer of a subsequent enum member" idea. But 1. most enums don't need this feature (and it's not that hard to work around if you do need it), and 2. what this solves isn't enum specific - any time you're creating an object, you might find yourself wanting to reference a previous value that's being put into that object - if we really find this to be very motivating, we should fix it for all object literals instead of inventing enum syntax and only fixing it for those.

JavaScript usually has a fairly high bar for new syntax, and this enum syntax doesn't feel like it's providing much value at the moment.

[ljharb]

I agree that solving self-reference should be done with a holistic syntax proposal.

I continue to believe that #30 (comment) has sufficient value for this proposal to proceed.

[theScottyJam]

That comment explains why you find value in using something like TrafficLightState.YELLOW over 'YELLOW'. Do you think you could expound on why enum syntax specifically (as opposed to object literal syntax) is important to you to solve this problem in a non-TypeScript codebase?

[ljharb]

Ah, that's a fair question. I think it's useful to have a simple syntax for the ecosystem to cohere around, especially if the syntax prevents all the many footguns that object literals have, including "inherits from Object.prototype".

[theScottyJam]

Thanks 👍 - that's another valid argument.

Don't think I have much more to add, at this point it's mostly a matter of subjective importance placed on these different pros and cons.

[waynemwashuma]

Hi there, i think enums are nice because they have a runtime presence as a type the way classes do.This is useful for type reflection.Im currently working on a reflection system where i have to use strings to represent enums instead of the actual enum type.

const MyEnum = {
  Variant1: 0,
  Variant2: 1
}

const store = new MyTypeStore()
store.addByName(`MyEnum`,MyEnum)

I would love to do something like this:

enum MyEnum {
  Variant1,
  Variant2
}

store.add(MyEnum)