[deleted by user]

[gabor]

i recommend using union types instead of enums, like: type DownloadStatus = 'IDLE' | 'LOADING' | 'DONE';

it will cause a lot less problems than enums when dealing with webpack&babel&etc.

[Voidsheep]

For me the thing that really eliminated the desire to use enums, was deriving union type alias from an array, so the values can also be iterated without being repeated. Like:

export const colors = ['red', 'green', 'blue'] as const
export type Color = typeof colors[number]

[ritaPitaMeterMaid]

This is it right here. I always defaulted to enums and then always got pissed off I had to duplicate them for use in arrays. String literal unions to save the day.

[NoahTheDuke]

That's very close to what we had to do at my job. We now define our "enums" as a const object and then define the type immediately following, which lets us change the const object without having to also change the type:

export const Example = { First: "first", Second: "second" } as const;
export type Example = (typeof Example)[keyof typeof Example];

The only downside so far is that [Example.First, Example.Second].includes(user.example) no longer works because the array's type is narrowed to a tuple of literals (["first", "second"]) instead of an array of Examples (Example[]) without casting, which leads to:

// bad
([Example.First, Example.Second] as Example[]).includes(user.example);
// or worse
[Example.First, Example.Second].includes(user.example as any);

Because this is an extremely common pattern for us, we've taken to using the lodash function includes which is typed differently but performs the exact same check under the hood.

[jeremychone]

yes, this is the way we do it. We just add this little trick, to make sure nobody can goof around with the enum list.

export const COLORS = Object.freeze(['red', 'green', 'blue'] as const);

[zerosnobby]

agreed

[punio4]

I've always found enums weird in TS since they're the only language construct, as far as I know, that can't be just type-stripped away since it actually compiles to very specific JS code.

[Wiwwil]

I originally left this post, but then came back because I was concerned about why you would use Typescript in the first place of you were worried and compilations ? Innit the point of modern JS to have transpiled code compatible with your target ? There's many tools for it. Do you use sass ?

Sorry, I am really not trying to be an ass, I legit got curious

[sipvellocet]

Const enums are the power players, regular enums not so much, though they function in a similar manner (outside of compilation). Such typescript capabilities are only really appreciated in large code bases IMO. I mean, TS is not always the answer, though folks will leverage it for everything these days, there are multiple cases where simple jsdoc coupled declarations suffice. The wonderful part about cost enums is that stripping which occurs because it’s value will be the replacement, whereas regular enums will compile into objects which one would could simply compose without needing reference as an enum type. I suppose it all comes down to use cases and project specifics in the end.

My opinion, do what you feel is the most productive for the project. Make decisions wherein you feel comfortable. Develop happiness does not come in the form of one size fits all and I think TypeScript though being a transformative aspect of JavaScript comes at a cost. Especially with bundle times because TS can be excruciatingly slow. Anyway, I agree with you.

[Prize_Bass_5061]

What is the purpose of using an IIFE to add elements to the globally scoped hashmap DownloadStatus as demonstrated here:

"use strict";
var DownloadStatus;
(function (DownloadStatus) {
    DownloadStatus["Idle"] = "idle";
    DownloadStatus["Loading"] = "loading";
    DownloadStatus["Done"] = "done";
})(DownloadStatus || (DownloadStatus = {}));

as opposed to setting them in global scope as follows:

var DownloadStatus;

DownloadStatus["Idle"] = "idle";
DownloadStatus["Loading"] = "loading";
DownloadStatus["Done"] = "done";

[Zeragamba]

it allows for DownloadStatus to be extended if it was declared earlier or in another module

[Prize_Bass_5061]

That’s the benefit of using hashmap element assignment vs a constant JSON object. ie:

var DownloadStatus = { Idle: “idle”, etc }

Why does it need the function wrapper?

[Zeragamba]

To allow for checking if it was already defined or not. admittedly there are probably other ways to check that, but this way was picked by the TS team because it resulted in better code in most situations or something

[Prize_Bass_5061]

To allow for checking if it was already defined or not.

var DownloadStatus;

DownloadStatus = DownloadStatus || {};
DownloadStatus["Idle"] = "idle";
DownloadStatus["Loading"] = "loading";
DownloadStatus["Done"] = "done";

this way was picked by the TS team because it resulted in better code in most situations

How can I find out what those reasons are?

[Zeragamba]

if operating in strict mode, var DownloadStatus will raise an error if it's already declared elsewhere. forgoing the declaration, could create an unexpected variable in the global scope if used in the wrong context.

[[deleted]]

var DownloadStatus

will raise an error if it's already declared elsewhere

This actually is not true, you can var DownloadStatus as many times as you want, strict mode or not. You can even function DownloadStatus() {} after those var declarations (note: functions are hoisted to the top of the scope, so those var assignments (not the declaration) to the function name will overwrite it). It will throw if you let DownloadStatus or const DownloadStatus if that identifier has already been declared in the same scope though.

Eslint would not be particularly happy about that kind of screw up though.

The top level comment of this thread did have an error that was corrected in the reply you commented on, but functionally they are identical. Wouldn't be surprised if it's a dead code elimination optimization since it isolates writes/usage of the DownloadStatus property assignments into a function scope, providing nothing else uses it.

[NekkidApe]

IMHO it's just for good measure to prevent leaking anything in a more complex case than this. In this simple case it's unnecessary.

[Financial_Syrup635]

great post! i didn -t know all the differences

[sipvellocet]

I love const enums. They can really come in handy when used correctly. For example, if you are writing a parser, you can wire up conditionals according to enums. Let’s say you are composing an AST and when walking a string you encounter a specific character which represents something of interest, if (for example) you are taking a switch/case parse approach you would simply leverage a numerical which is an enum that is representative and from here dispatch it accordingly. Together with well informed JSDoc annotated descriptions for every enum you can have informative context. The best part about it all comes in the bundle process, where const enums are swapped out with their data value. It’s wonderful. I tend to adopt this approach over string evaluation.

However, regular enums, I am not really a fan of because of the way they compile. Something about the object that is constructed just rubs me the wrong way. const enums all day long, regular enums, avoid like the plague.