为什么TypeScript的Enum会出现问题
作者：小红星闪啊闪
TypeScript引入了很多静态编译语言的特性，比如class（现在是JavaScript的一部分了），interface, generics和union types等。
但是今天有一个类型需要着重讨论下，这就是enum。
对于很多的静态语言来说，枚举是一个很非常常见的语言特性。比如，c，c#，java和swift。枚举就是你在代码里可以用的一组常量。
我们用TypeScript来新建一个enum来代表一周的几天：
enum DayOfWeek {
Sunday,
Monday,
Tuesday,
Wednesday,
Thursday,
Friday,
Saturday
};
这个枚举使用enum关键字声明，后面跟着DayOfWeek名称。然后我们定义枚举里可以使用的常量。
现在我们定义一个方法，接受这个枚举类型的参数，来判断传入的参数是不是周末。
function isItTheWeekend(day: DayOfWeek) {
switch (day) {
case DayOfWeek.Sunday:
case DayOfWeek.Saturday:
return true;
default:
return false;
}
}
最后，我们可以这要用：
console.log(isItTheWeekend(DayOfWeek.Monday)); // log: false
对于消除程序里的魔法字符串来说，这是一个非常有用的方法。
但是，事情远不是我们想的这么简单。下面的代码调用会在TypeScript编译之后得到什么呢？
console.log(isItTheWeekend(2)); // is this valid?
知道结果你会吓一跳。这样的调用是符合TypeScript规则的，编译器也会顺利编译。
发生了什么呢？
上面的情况可能会让你认为你发现了一个TypeScript的bug。其实TypeScript就是这么设计的。
我们这里新建了一个数字枚举，而且我们可以在TypeScript Playground里看看编译出来的结果是什么：
var DayOfWeek;
(function (DayOfWeek) {
DayOfWeek[DayOfWeek["Sunday"] = 0] = "Sunday";
DayOfWeek[DayOfWeek["Monday"] = 1] = "Monday";
DayOfWeek[DayOfWeek["Tuesday"] = 2] = "Tuesday";
DayOfWeek[DayOfWeek["Wednesday"] = 3] = "Wednesday";
DayOfWeek[DayOfWeek["Thursday"] = 4] = "Thursday";
DayOfWeek[DayOfWeek["Friday"] = 5] = "Friday";
DayOfWeek[DayOfWeek["Saturday"] = 6] = "Saturday";
})(DayOfWeek || (DayOfWeek = {}));
运行结果是：
事实上枚举就是一个JavaScript对象。
这个对象的属性就是根据我进定义的枚举常量生成，还根据定义的顺序生成了对应的数字（顺序，Sunday是0，Saturday是6）。这个对象也有数字作为key，对应的常量字符串作为值的属性。
因此，我们可以给上面的方法传入数字，数字映射到对应的枚举值。枚举既是一个数字常量也是一个字符串常量。
什么时候用
如果一个方法接收一个枚举类型参数，但是一个任意的数字就可以通过编译的话。这样的结果显然破坏了TypeScript构建的类型安全体系。这什么时候可以用呢？
假设你有一个服务返回一个JSON串，你想把这个串建模，对应的某个属性是一个枚举。
在你的数据库里存的是数字。定义一个TypeScript枚举可以很容易解决这个问题：
const day: DayOfWeek = 3;
这个在赋值时执行的显示的类型转换会把数字转换成枚举的对应常量。也就是说我们在代码里使用这个枚举会让代码更容易读懂。
控制枚举的数字
枚举的成员对应的数字是根据枚举常量定义的顺序生成的。那我们是否可以控制这个数字的值呢？是可以的。
enum FileState {
Read = 1,
Write = 2
}
只是描述一个文件可能的状态的枚举。
它可能是读也可能是写状态，我们显示的定义了枚举值。现在就很明确什么样的值是合理的，因为显示定义了。
Bit值
但是还有另一个情况很有用，位值（Bit）。
我们再来看一下这个FileState枚举，给它添加一个新的枚举值ReadWrite：
enum FileState {
Read = 1,
Write = 2,
ReadWrite = 3
}
之后假设有一个方法接受这个类型的参数：
const file = await getFile("/path/to/file", FileState.Read | FileState.Write);
我们在FileState上使用了|操作符。这样我们可以使用位运算来获得一个新的枚举值。在这个例子里面就是3，ReadWrite的值。
事实上，我们可以写的更清楚一些：
enum FileState {
Read = 1,
Write = 2,
ReadWrite = Read | Write
}
这个ReadWrite的值不是写死的，而是位运算得到的。
但是再这样使用枚举的时候要多加小心。
如下的枚举：
enum Foo {
A = 1,
B = 2,
C = 3,
D = 4,
E = 5
}
如果要得到E（或者5），可以位运算得到么：Foo.A | Foo.D or Foo.B | Foo.C?
所以如果要用枚举值做位运算，那么明确如何得到这个值。
控制索引
一般情况下，每个枚举值都会有一个默认的数字值。如果需要也可以明确的给这些枚举值赋值。另外，还可以给某部分枚举赋值：
enum DayOfWeek {
Sunday,
Monday,
Tuesday,
Wednesday = 10,
Thursday,
Friday,
Saturday
}
前几个值是按照位置赋值，Sunday到TuesDay是0到2.之后在Wednesday给了一个新值，从这开始每个值都递增1. 这就可能会出现问题了：
enum DayOfWeek {
Sunday,
Monday,
Tuesday,
Wednesday = 10,
Thursday = 2,
Friday,
Saturday
}
Tuesday赋值为2，生成的JavaScript是什么样子呢：
var DayOfWeek;
(function (DayOfWeek) {
DayOfWeek[DayOfWeek["Sunday"] = 0] = "Sunday";
DayOfWeek[DayOfWeek["Monday"] = 1] = "Monday";
DayOfWeek[DayOfWeek["Tuesday"] = 2] = "Tuesday";
DayOfWeek[DayOfWeek["Wednesday"] = 10] = "Wednesday";
DayOfWeek[DayOfWeek["Thursday"] = 2] = "Thursday";
DayOfWeek[DayOfWeek["Friday"] = 3] = "Friday";
DayOfWeek[DayOfWeek["Saturday"] = 4] = "Saturday";
})(DayOfWeek || (DayOfWeek = {}));
看起来Tuesday和Thursday的数值都是2。
所以，需要显示的设定数值。
非数字枚举
目前为止，我们只讨论了数值枚举，但是枚举的值不一定非的是数字。它也可以是任何常量或者计算值：
enum DayOfWeek {
Sunday = "Sun",
Monday = "Mon",
Tuesday = "Tues",
Wednesday = "Wed",
Thursday = "Thurs",
Friday = "Fri",
Saturday = "Sat"
}
现在就不能给isItTheWeekend方法穿数字参数了。这个枚举已经不再是数字枚举。然而，我们也不能传任意字符串进去，因为枚举知道什么样的值才是合理的。
这样也带来另外一个问题：
const day: DayOfWeek = "Mon";
这样是行不通的。
字符串并不能直接给枚举赋值，而是需要一个显示的类型转换：
const day = "Mon" as DayOfWeek;
能不能给它赋其他值呢？事实上枚举可以有很多类型的值：
enum Confusing {
A,
B = 1,
C = 1 << 8,
D = 1 + 2,
E = "Hello World".length
}
这个例子的枚举值都是数字。但是这些数字值可以直接赋值，也可以是计算值，或者是字符串的length属性。如果都是常量的话，那么就可以是多种类型的值：
enum MoreConfusion {
A,
B = 2,
C = "C"
}
这种情况就很难让人理解枚举后面的数据是怎么工作的。所以，最好不要用这样的枚举。
结论
TypeScript的枚举是对JavaScript的一个很好地补充，使用得当将非常有用。它将有助于清理代码中存在的魔术值（magic values）字符串、数字。而且它是类型安全的。
到此这篇关于为什么TypeScript的Enum会出现问题的文章就介绍到这了,更多相关TypeScript Enum内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！