- 原文地址：What’s Coming Up in JavaScript 2018: Async Generators, Better Regex
- 原文作者：Mary Branscombe
- 譯文出自：掘金翻譯計劃
- 本文永久連結：github.com/xitu/gold-m…
- 譯者：MeFelixWang
- 校對者：CoderMing
2018 年 6 月釋出的最新年度 ECMAScript 更新，儘管在常見功能的積壓上仍然遠遠小於 ECMAScript 6，但依然是迄今為止最大的年度版本。
身為 ECMAScript 編輯及微軟在 ECMA TC39 委員會代表的 Brian Terlson 告訴 The New Stack：這個版本中兩個最大的開發者功能是非同步生成器和一些期待已久的正規表示式改進，以及 rest/spread 屬性。
“非同步生成器和迭代器是將非同步函式和迭代器結合起來的結果，所以它就像你可以在其中等待的非同步生成器或你可以從中得到返回值的非同步函式，”他解釋道。以前，ECMAScript 允許你編寫一個可以輸入或等待但不能同時進行兩者操作的函式。“這對於在 Web 平臺佔比越來越大的消費流來說非常方便，尤其是在 Fetch 物件公開流的情況下。”
非同步迭代器類似於 Observable 模式，但更靈活。“Observable 是推模型; 一旦你訂閱了它，無論你是否準備好，你都會被爆炸式的事件和通知衝擊，所以你必須實施緩衝或取樣策略來處理干擾，”Terlson 解釋道。非同步迭代器是一種推拉模型 —— 你請求一個值後傳送給你 —— 這對於諸如網路 IO 原語之類的東西更有效。
Promise.prototype.finally 對非同步程式設計也很有幫助，在一個 promise 狀態變為 fulfilled 或 rejected 後，指定一個最終方法來進行清理。
更多常規正規表示式功能
Terlson 對正規表示式的改進感到特別興奮（其中大部分工作都是由 V8 團隊完成的，他們已經完成了這四個主要功能的早期實現），因為這是此語言落後的領域。
“自從 JavaScript 誕生之日起，ECMAScript 正規表示式就沒有過顯著進步；幾乎所有其他程式語言的正規表示式庫都比 ECMAScript 的功能高階。“ECMAScript 6 包含了一些小的更新，但他將 ECMAScript 2018 視為“第一次明顯改變你如何編寫正規表示式的更新”。
dotAll 標誌使點字元匹配所有字元，而不再會對匹配一些換行符（比如 n 或 f ）無效。“你不能使用點字元，除非你處於多行模式並且你不關心每行的結束，”他指出。這方面的變通辦法創造了一些不必要的複雜的正規表示式，Terlson 期望“每個人都能在正規表示式中使用該模式”。
命名捕獲組與許多其他語言中的命名組類似，你可以在命名正規表示式匹配的字串中的不同部分，並將其視為物件。“這幾乎等同於在你的正規表示式中新增註釋，通過賦予它一個名字來解釋該組試圖捕捉的內容，”他解釋道。“這個模式的一部分是月份，這是出生日期......這對於未來其他人維護你的模式真的很有幫助。”
還有其他關於空字元的提案，即告訴正規表示式引擎忽略模式匹配中的空格、換行符以及註釋，允許在空格後的行尾新增註釋，這種特性可能包含在 ECMAScript 的未來版本中並將進一步提高可維護性。
以前 ECMAScript 有先行斷言但沒有後行斷言。“人們使用了一些技巧，比如反轉字串，然後進行匹配，或一些其他 hacks，”Terlson 指出。這對於查詢和替換的正規表示式特別有用。“你看到的並沒有成為你匹配的一部分，所以如果你要替換前後任何一邊有美元符號的數字，你就可以做到這一點而無需做額外的工作將美元符號重新放回去。”ECMAScript 後行斷言允許像 C# 中那樣的可變長度的後行斷言，而不僅僅是 Perl 中的固定長度模式。
特別是對於需要支援國際使用者的開發人員，允許在正規表示式中使用 Unicode 屬性轉義 \\p{…} 和 \\P{…} 將使建立 Unicode 可識別的正規表示式變得更加容易。目前，這對開發人員來說是件很麻煩的事。
“Unicode 定義了數字，但這些數字不僅包括基本拉丁語 ASCII 0 到 9，還包括數學數字，粗體數字，大綱數字，花哨的演示數字，表格數字。如果要匹配 Unicode 中的任何數字，則 Unicode 可識別的應用程式必須具有可用的整個 Unicode 資料表。通過新增此功能，你可以將這些全部委託給 Unicode，”他說。如果你想以嚴格的方式匹配 Unicode 字元，比如說進行表單驗證，並且你想做正確的事情而不是告訴人們他們的名稱是無效的，這在很多情況下很難做到，但是使用 Unicode 字元類你可以明確指出名稱所需的字元範圍。已經有了不同語言和指令碼的類，所以如果你只想處理希臘語或漢字，完全可以做到。Emoji 正變得越來越普遍。
還有一些新的國際化 API，用於本地化的日期和時間格式，歐元貨幣格式和複數形式，這樣可以更輕鬆地執行本地化標籤和按鈕等操作。
ECMAScript 2018 擴充套件了物件和陣列對 rest 和 spread 模式的支援（在 React 生態系統中很常見，許多開發人員都沒有意識到它還沒有完全標準化），Terlson 稱之為有超大影響的小功能。rest 和 spread 對於複製和克隆物件很有用，例如，如果你有一個不可變的結構，而你要更改除一個屬性之外的所有內容，或者你想複製一個物件但新增一個額外的屬性。Terlson 指出，這種模式經常用於為選項記錄分配預設值。“對於你一直在做的事情來說，這是一個非常好的語法模式。”
Babel 和 TypeScript 等轉換器已經支援 ECMAScript 2018 的許多功能。瀏覽器支援也將隨著時間的推移實現，並且所有新功能都已經在 Chrome 的釋出版本中（要獲得完整的支援矩陣圖表，請檢視 ECMAScript 相容性表）。
ECMAScript 相容性表檢測到的瀏覽器支援情況。
未來發展；ECMAScript 2019
一些有趣的提案尚未達到成為 ECMAScript 標準的一部分所必需的第四階段，包括對私有欄位和方法的宣告略有爭議的想法，其中包括許多備選提案。
當在 ECMAScript 6 中引入類時，它們是“極小的”，Terlson 解釋為“故意在很小[範圍]，因為我們將在以後繼續處理它們。”私有欄位允許開發人員宣告可以在類的內部通過名稱進行引用的欄位，但不能從類的外部訪問，”他說。這不只是提供了更好的效能，因為當在類建構函式中宣告所有欄位時，執行時可以更好地優化物件的處理，但也是語言強制實現隱私，而 TypeScript 中的私有欄位則不是這樣。與 symbols 不同，你可以使用 get 屬性列出物件上的所有 symbols，私有欄位將不允許反射。
“庫作者正在尋求一種擁有私人狀態的方式，以便開發者不能依賴它，”Terlson 解釋道。“即使做了他們不應該做的事情，庫也不喜歡打斷使用者。”例如，類中的私有屬性將允許庫作者避免暴露內部實現細節，如果他們將來可能會修改的話。
BigInt 提案也處於第三階段。目前，ECMAScript 只有 64 位浮點數型別，但許多平臺和 web API 使用 64 位整數 — 包括 Twitter 用作推文 ID 的 64 位整數。“你不能再將 JavaScript 中的推文 ID 表示為數字，”Terlson 解釋道。“它們必須表示為一個字串。” BigInt 是一個更通用的提案，用於新增任意精度的整數，而不只是新增 64 位整數。加密 API 和高精度計時器也將利用這一點，Terlson 預計 JIT JavaScript 引擎可能會使用原生 64 位欄位來提供大整數以提升效能。
兩項提案已經進入第四階段；讓 catch 繫結成為可選項（如果你不需要實際使用變數，就不必再將變數傳遞給 catch 塊），以及進行小的語法更改以處理 JSON 和 ECMAScript 字串格式之間的不匹配。這些將與其他在未來幾個月內取得進展的提案一起進入 ECMAScript 2019。
微軟是 The New Stack 的贊助商。
首圖來自 Pixabay。
如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。