## 前言 也許前端的同學會問JavaScript從誕生至今都沒有列舉型別，我們不是都活得挺好的嗎？為什麼TypeScript需要引入列舉型別呢？ 也許被迫寫前端的後端同學會問，TypeScript的列舉型別是和Java/.NET的一樣嗎？ 下面我們來一起探討和嘗試解答吧！ ## 前端一直都需要列舉 我敢保證，前端的同學都會萬分肯定地告訴大家：我們從來沒有寫過列舉。那是因為雖然ECMAScript將`enum`作為保留字，但至ES2020為止還沒有提出列舉的實現規範。語言沒有提供規範和語言實現，不代表思想活躍勇於造輪子的程式設計師們不會自己擼一個。 如果語言沒有提供，還有那麼毅然決然要自己造一個，那列舉到底能解決我們什麼問題呢？ ### 列舉真的有點用 首先，列舉字面上的意思就遍歷一個存在若干個的值有窮集合的所有成員。核心有兩點： 1. 有窮集合； 2. 遍歷。 也就是說，只要我們需要表示某個變數的值必須為某個有窮集合的成員時，我們是怎麼也繞不開列舉的。 ### 寫個JavaScript版本的列舉 下面是剛好滿足大部分業務需求的列舉實現： ``` class Color { // tricky：自增列舉成員值 static counter = null // 列舉成員 static Red = new Color('Red') static Green = new Color('Green') // 反向對映 static valueOf(value) { for (var name in Color) { if (!(name in Color.prototype) && Color[name].value === value) { return Color[name] } } } constructor(name, value){ if ('counter' in Color);else return this.name = name if (value == null) { if (Color.counter === null) { this.value = Color.counter = 0 } else { this.value = ++Color.counter } } else { this.value = Color.counter = value } } toString() { return `Color.${this.name}` } } delete Color.counter Object.freeze(Color) // tricky：禁止在定義之外的位置修改列舉成員 ``` 其實我們只想表達某些變數將以含有Red、Green兩個成員的Color有窮集合作為值域而已，卻要寫這麼多語義無關的程式碼(嚴格遵循“能寫hi絕對不寫hello”原則)。而且在一般規模的專案當中，往往不止一個列舉型別，複製貼上確實可以解決問題，但真心不優雅。 而TypeScript內建列舉的語言實現恰恰能解決這個問題。 ## TypeScript的列舉和後端的真不一樣 後端的同學對列舉絕對是不會陌生的（除非是Pyton/Nodejs後端的同學啦），雖然TypeScript是JavaScript的超集，但最終需要編譯為JavaScript程式碼，並且要相容現有JavaScript庫，所以確實無法和後端的列舉型別一模一樣。 所以我還是建議大家運用空杯心理，重頭理解TypeScript的列舉型別，將過去的知識作為助燃劑，而不是圍欄更適宜。 ## 數字列舉型別和字串列舉型別 TypeScript官網教程已經對列舉型別進行了詳細的講解說明，我認為最核心是理解清楚其分為兩大類： 1. 數字列舉型別 ``` enum Response { No = 0, // 手動設定初始化器 Yes = // 附加預設的支援自動增長的初始化器，因此Yes的值為1 } ``` 特性為： 1.1. 列舉成員附帶預設的初始化器； 1.2. 初始化器支援自動增長； 1.3. 支援反向對映。(注意：這裡是反向對映，而不是通過值轉換為列舉成員) 2. 字串列舉型別 ``` enum Color { Red = 'Red', Green = 'Green', } ``` 特性為： 1.1. 必須為列舉成員設定初始化器； 1.2. 初始化器不支援自動增長； 1.3. 不支援反向對映。 而計算和常量成員其實就是上述兩種列舉型別中初始化器的細分特性罷了。 ## `enum`讓數字列舉型別反向對映成為可能 上一節介紹到數字列舉型別支援反向對映，但前提是通過`enum`定義的數字列舉型別才支援。那是因為`enum Respose {No,Yes,}`最終會被編譯為如下JavaScript程式碼： ``` var Response; (function (Response) { Response[Response["No"] = 0] = "No"; Response[Response["Yes"] = 1] = "Yes"; })(Response || (Response = {})); ``` 那麼我們就可以通過~Response[0]~反向對映得到~"No"~。 但對於字串列舉型別就沒有這種好事了，看看`enum Color {Red='Red',Green='Green',}`編譯出來的程式碼吧 ``` var Color; (function (Color) { Color["Red"] = "Red"; Color["Green"] = "Green"; })(Color || (Color = {})); ``` 只能說非常樸實無華，就這樣沒啥好說的，大家在使用時注意差異就好了。 ## `const enum`高效的編譯時內聯 官方文件明確寫出“大多數情況下，列舉是十分有效的方案。 然而在某些情況下需求很嚴格。 為了避免在額外生成的程式碼上的開銷和額外的非直接的對列舉成員的訪問，我們可以使用 const列舉”，那是為什麼呢？ 那是因為通過`const enum`定義的編譯時列舉型別，效果和通過C/C++的`#define`定義常量沒實質區別。說白了就是假如僅僅通過通過`const enum`定義了列舉型別而沒有其它地方呼叫，這段程式碼將在編譯時被直接抹掉。 當其它地方呼叫該列舉型別時，將直接把列舉型別成員的值內聯到使用處，如下： ``` const enum Response { No, Yes, } console.log(Response.NO, Response.Yes) ``` 編譯後成為`console.log(0, 1)`，執行效果自然只能比`enum`定義的好。 ## 什麼時候用`enum`？又在什麼場景下用`const enum`呢？ 先說說結論： 1. 使用`enum`的場景： 1.1. 需要使用反向對映時； 1.2. 需要編譯後的JavaScript程式碼保留`物件.屬性`或`物件[屬性]`形式時。 2. 使用`const enum`的場景：能不用`enum`時就用`const enum`(哈哈！) 使用`enum`的場景中的第一條還很好理解，但第二條是啥回事呢？我這裡有個真實發生的示例，可以讓大家更好的理解： *背景：*為Photoshop的ExtendScript編寫型別宣告。 *需求：*`DialogModes.NO`在ExtendScript中返回值為`DialogModes.No`本身，編譯後的JavaScript中必須保留`DialogModes.NO`的程式碼形式。 那麼又為何鼓勵大家能用`const enum`時就用`const enum`呢？ 這是TypeScript為大家特意準備的編譯時優化方式，好東西為啥不用呢？編譯時優化難道不香嗎？ ## 外部列舉`declare enum`的作用？ 所謂外部列舉，即使我們為了在TypeScript開發環境下，更好地使用某些已採用JavaScript編寫的庫，而被迫為其編寫的列舉型別宣告。 如ExtendScript標準庫存在列舉`DialogModes.NO`，`DialogModes.YES`，`DialogModes.ALL`。於是在`.d.ts`檔案中編寫如下外部列舉型別宣告 ``` declare enum DialogModes { NO, YES, ALL, } ``` ## 總結 對於日常開發中我們繞不過列舉型別，TypeScript為我們提供語言實現和編譯時優化，除了保護了我們為如何優化實現列舉型別而日思夜想導致日漸稀疏的頭髮外，還大大降低了因複製貼上帶來的程式碼庫體積徒增的風險。 寫更少的程式碼，做正確的事，早點下班豈不更快哉^_^ 轉載請註明來自：https://www.cnblogs.com/fsjohnhuang/p/13893641.html —— ^_^肥仔