Difference between Enum and Objects with 'string' key and 'number' value pair-CodePudding

What is the difference between an enum object and a regular object with 'string' keys and 'number' values ?

// THIS  IS TYPESCRIPT CODE

enum Role { ADMIN, READ_ONLY_USER, FINANCES } // enum

const Role_alt = { ADMIN : 0, READ_ONLY_USER : 1, FINANCES : 2 } // object with 'string' keys and 'number' values

console.log(Role.FINANCES) // <- 2
console.log(Role_alt.FINANCES) // <- 2

It gets transpiled to this JS:

var Role;                                                   // 
(function (Role) {                                          //        
    Role[(Role["ADMIN"] = 0)] = "ADMIN";                    // object declared as enum in TS
    Role[(Role["READ_ONLY_USER"] = 1)] = "READ_ONLY_USER";  //
    Role[(Role["FINANCES"] = 2)] = "FINANCES";              //
})(Role || (Role = {}));                                    //

var Role_alt = { ADMIN: 0, READ_ONLY_USER: 1, FINANCES: 2 }; // object with 'string' keys and 'number' values

console.log(Role.FINANCES); // <- 2
console.log(Role_alt.FINANCES); // <- 2

Obviously, the enum is transpiled to much complex code. I was wondering what the advantage of that is.

CodePudding user response：

enum Role { ADMIN, READ_ONLY_USER, FINANCES } // enum

const Role_alt = { ADMIN : 0, READ_ONLY_USER : 1, FINANCES : 2 } // object with 'string' keys and 'number' values

console.log(Role.FINANCES) // <- 2
console.log(Role_alt.FINANCES) // <- 2

Well, because you can also do this, and you can't with a normal object:

Role[2] // "FINANCES"

Sometimes it is useful, sometimes it is not.

CodePudding user response：

Yes there is a difference

Here's the example

enum Value {
  No = 0,
  Yes = 1,
}
function demo(response: Value): void {
  //
}

But if it was const

const ValueConst {
  No: 0,
  Yes: 1,
}
function demo(response: typeof ValueConst): void {
  // have to use `typeof`, otherwise you get an Error
  // 'ValueConst' refers to a value, but is being used as a type here. Did you mean 'typeof ValueConst'?
}

And also enums are readonly

ValueConst.No = 1 // enables assignment (Not good)
Value.No = 1 // Cannot assign to 'No' because it is a read-only property.

And from docs

The biggest argument in favour of this format over TypeScript’s enum is that it keeps your codebase aligned with the state of JavaScript, and when/if enums are added to JavaScript then you can move to the additional syntax.

CodePudding user response：

An enum generally has a string value and a numeric value that relates to that string value.

In TS, you can parse 1 into Role.READ_ONLY_USER, and 'READ_ONLY_USER' into Role.READ_ONLY_USER.
As TS transpiles to JavaScript, the resulting code needs some kind of data format that stores these relations.

The simplest way to do that is to generate an object that contains both:

The numeric keys with string values;
The string keys with numeric values.

Then, Role[1] will return 'READ_ONLY_USER'.

So, in short, the numeric keys exist to allow conversion of numbers to enum values.