附錄B：填補塊兒作用域 · 你不懂JS：作用域與閉包

# 附錄B：填補塊兒作用域在第三章中，我們探索了塊兒作用域。我們看到最早在 ES3 中引入的?`with`?和?`catch`?子句都是存在于 JavaScript 中的塊兒作用域的小例子。但是 ES6 引入的?`let`?最終使我們的代碼有了完整的，不受約束的塊作用域能力。不論是在功能上還是在代碼風格上，塊作用域都使許多激動人心的事情成為可能。但要是我們想在前 ES6 環境中使用塊兒作用域呢？考慮這段代碼： ```source-js { let a = 2; console.log( a ); // 2 } console.log( a ); // ReferenceError ``` 它在 ES6 環境下工作的非常好。但是我們能在前 ES6 中這么做嗎？`catch`?就是答案。 ```source-js try{throw 2}catch(a){ console.log( a ); // 2 } console.log( a ); // ReferenceError ``` 哇！這真是難看和奇怪的代碼。我們看到一個?`try/catch`?似乎強制拋出一個錯誤，但是這個它拋出的“錯誤”只是一個值?`2`。然后接收它的變量聲明是在?`catch(a)`?子句中。三觀：毀盡。沒錯，`catch`?子句擁有塊兒作用域，這意味著它可以被用于在前 ES6 環境中填補塊兒作用域。 “但是……”，你說。“……沒人愿意寫這么丑的代碼！”你是對的。也沒人編寫由 CoffeeScript 編譯器輸出的（某些）代碼。這不是重點。重點是工具可以將 ES6 代碼轉譯為能夠在前 ES6 環境中工作的代碼。你可以使用塊兒作用域編寫代碼，并從這樣的功能中獲益，然后讓一個編譯工具來掌管生成將在部署之后實際?*工作*?的代碼。這實際上是所有（嗯哼，大多數）ES6 特性首選的遷移路徑：在從前 ES6 到 ES6 的轉變過程中，使用一個代碼轉譯器將 ES6 代碼轉換為 ES5 兼容的代碼。 ## Traceur Google 維護著一個稱為“Traceur”[^note-traceur]的項目，它的任務正是為了廣泛使用 ES6 特性而將它轉譯為前 ES6（大多數是 ES5，但不是全部！）代碼。TC39 協會依賴這個工具（和其他的工具）來測試他們所規定的特性的語義。 Traceur 將從我們的代碼段中產生出什么？你猜對了！ ```source-js { try { throw undefined; } catch (a) { a = 2; console.log( a ); } } console.log( a ); ``` 所以，使用這種工具，我們可以開始利用塊兒作用域，無論我們是否面向 ES6，因為?`try/catch`?從 ES3 那時就開始存在了（并且這樣工作）。 ## [](https://github.com/getify/You-Dont-Know-JS/blob/1ed-zh-CN/scope%20%26%20closures/apB.md#%E9%9A%90%E5%90%AB%E7%9A%84%E4%B8%8E%E6%98%8E%E7%A1%AE%E7%9A%84%E5%9D%97%E5%84%BF)隱含的與明確的塊兒在第三章中，在我們介紹塊兒作用域時，我們認識了一些關于代碼可維護性/可重構性的潛在陷阱。有什么其他的方法可以利用塊兒作用域同時減少這些負面影響嗎？考慮一下?`let`?的這種形式，它被稱為“let 塊兒”或“let 語句”（和以前的“let 聲明”對比來說）。 ```source-js let (a = 2) { console.log( a ); // 2 } console.log( a ); // ReferenceError ``` 與隱含地劫持一個既存的塊兒不同，let 語句為它的作用域綁定明確地創建了一個塊兒。這個明確的塊兒不僅更顯眼，而且在代碼重構方面健壯得多，從文法上講，它通過強制所有的聲明都位于塊兒的頂部而產生了某種程度上更干凈的代碼。這使任何塊兒都更易于觀察，更易于知道什么屬于這個作用域和什么不屬于這個作用域。作為一種模式，它是與許多人在函數作用域中采納的方式相對稱的 —— 它們手動地將所有`var`聲明移動/提升到函數的頂部。let 語句有意地將它們放在塊兒的頂部，而且如果你沒有通篇到處使用?`let`?聲明，那么你的塊兒作用域聲明就會在某種程度上更易于識別和維護。但是，這里有一個問題。let 語句的形式沒有包含在 ES6 中。就連官方的 Traceur 編譯器也不接受這種形式的代碼。我們有兩個選擇。我們可以使用 ES6 合法的語法格式化，再加上一點兒代碼規則： ```source-js /*let*/ { let a = 2; console.log( a ); } console.log( a ); // ReferenceError ``` 但是，工具就意味著要解決我們的問題。所以另一個選項是編寫明確的 let 語句塊兒，并讓工具將他轉換為合理的，可以工作的代碼。所以，我建造了一個稱為“let-er”[^note-let_er]的工具來解決這個問題。*let-er*?是一個編譯期代碼轉譯器，它唯一的任務就是找到 let 語句形式并轉譯它們。它將你的代碼其他部分原封不動地留下，包括任何 let 聲明。你可以安全地將?*let-er*?用于 ES6 轉譯器的第一步，然后如果有需要，你可以將你的代碼通過 Traceur 這樣的東西。另外，*let-er*?有一個配置標志?`--es6`，當它打開時（默認是關閉），會改變生成的代碼的種類。與使用?`try/catch`?的 ES3 填補黑科技不同的是，*let-er*?將拿著我們的代碼并產生完全兼容 ES6 的代碼，沒有黑科技： ```source-js { let a = 2; console.log( a ); } console.log( a ); // ReferenceError ``` 所以，你可以立即開始使用?*let-er*，而且可以面向所有前 ES6 環境，當你僅關心 ES6 時，你可以加入配置標志并立即僅面向 ES6。而且最重要的是，你可以使用更好的和更明確的 let 語句形式，即便它（還）不是任何 ES 官方版本的一部分。 ## [](https://github.com/getify/You-Dont-Know-JS/blob/1ed-zh-CN/scope%20%26%20closures/apB.md#%E6%80%A7%E8%83%BD)性能讓我在?`try/catch`?的性能問題上加入最后一個快速的說明，并/或解決這個問題：“為什么不使用一個IIFE來創建作用域？” 首先，`try/catch`?的性能?*是*?慢一些，但是沒有任何合理的假設表明它?*必須*?是這樣，或者它?*總是*?這樣。因為 TC39 認可的官方 ES6 轉譯器使用?`try/catch`，Traceur 團隊已經讓 Chrome 去改進?`try/catch`?的性能了，而且它們有很明顯的動力這樣做。第二，IIFE 和?`try/catch`?不是一個合理的“蘋果對蘋果”的比較，因為一個包裝著任意代碼的函數改變了這段代碼的含義，以及它的?`this`、`return`、`break`、和?`continue`?的含義。IIFE 不是一個合適一般替代品。它只能在特定的情況下手動使用。真正的問題變成了：你是否想要使用塊兒作用域。如果是，這些工具給你提供了這些選擇。如果不，那就在你的代碼中繼續使用?`var`！ [^note-traceur]:?[Google Traceur](http://traceur-compiler.googlecode.com/git/demo/repl.html) [^note-let_er]:?[let-er](https://github.com/getify/let-er)