即將釋出的JavaScript2018：非同步生成器，更好的正則表示式
釋出於2018年6月最新的年度 ofollow,noindex" target="_blank">ECMAScript 更新 , ,儘管在常見功能上僅次於ECMAScript6， 但仍是至今為止最大的年度版本。
Brian Terlson ，是ECMAScript的編輯兼微軟在 ECMA TC39委員會 的代表 ，在The New Stack上發表：這個版本兩個最大的開發者功能是非同步生成器和一些大家期待已久的，對於正則表示式改進，和rest/spread屬性。
“非同步生成器和迭代器是將非同步函式和迭代器結合，所以它就像是可以在其中等待的非同步生成器或者可以得到返回值的非同步函式，” 他解釋到。此前，ECMAScript允許你寫一個可以yield或者非同步等待的函式，但是不能生成一個二者同時進行的函式。“對於在Web平臺佔比越來越大的消耗資源流來說非常方便了，尤其是對於Fetch物件公開流的情況下。”
非同步迭代器類似於觀察者模式，但是靈活性更大。 ”觀察者模式是一個不可逆的模式。一旦你訂閱了，不管你是否準備好，將以最快的速度進入了所有的事件和釋出，所以你必須實施緩衝或採樣策略處理干擾，”Terlson解釋道。非同步迭代器是一個可以推拉的模式——你請求一個值然後傳送給你，這對像一些網路IO原語之類的東西更加有效。
Promise.prototype.finally 對非同步程式設計也非常的有幫助，在一個promise狀態變為fulfilled或者rejected後，指定一個最終方法進行清理。
更多常規的正則表示式
Tealson對正則表示式的改進非常興奮（其中大部分工作都是由工作於V8引擎的團隊完成的，他們已經完成了四個主要的特性的早期實現），因為這是這個語言落後的地方。
“自JavaScript誕生起，ECMAScript正則表示式沒有過很大的進步提升，幾乎其他的程式語言的正則表示式的庫功能更加高階。” ECMAScript 6 包含了 一些小的更新 ,但是他將ECMAScript 2018視為“第一次明顯改變你怎樣寫正則表示式的更新“。
dotAll 標誌 使 . 匹配所有字元，而不會對匹配一些斷點（如\n或\f）無效。“你不能使用 . 除非你在處於多行模式下並且你不在意每行的結束。”他指出。這方面的變通方法創造了不必要的複雜的正則表示式，並且Terlson期待：“每一個人都會在正則表示式中使用該模式”。
命名捕獲組 類似於一些其他語言的命名組，你可以在命名正則表示式匹配的字串中的不同部分，並將其視為物件。“這幾乎等同於在你的正則表示式中添加註釋，通過賦予它一個名字來解釋這個組試圖捕捉的內容，”他解釋道，“這部分模式就是月份，這是出生日期......這對於未來其他人維護你的模式真的很有幫助。”
還有關於空字元的提案，告訴了正則表示式引擎忽略模式匹配中的空格，換行，以及註釋，並且允許在空格後的行尾添加註釋，這種特性可能包含了在將來的ECMAScript版本中進一步提高可維護性。
以前的ECMAScript只有先行斷言而沒有後行斷言。“人們使用了一些技巧，就像反轉字串，然後進行匹配，或者一些其他hacks，” Terslon強調。這對於查詢和替換的正則表示式非常有用。 “你看到的沒有變成你匹配的一部分，所以如果你要替換前後任何一側有美元符號的數字，你就可以做到這一點無需做額外的工作將美元符號重新放回去” ECMAScript 的 後行斷言 允許像C#中那樣可變長度的後行斷言，而不是僅僅的像Perl的固定長度模式。
尤其是對於需要支援國際使用者的開發者, 允許在正則表示式中使用 Unicode屬性轉義 \p{…} 和 \P{…} 將使Unicode可識別的正則表示式將會更加簡單。目前，這對開發人員來說是一件非常麻煩的事情。
“Unicode定義了數字，但這些數字不僅僅包括基本的拉丁語ASCII 0-9，還包括數學數字，粗體數字，大綱數字，花哨的演示數字，表格數字。如果想匹配Unicode可識別的任何數字，則Unicode可識別的應用程式必須具有可用的整個Unicode資料表格。通過新增這些特性，你可以全部委託給Unicode，”他說道。如果你想要嚴格匹配Unicode字元，比如進行一些表單校驗，並且如果你想要一件正確的事情，而不是告訴人們他們的名稱是不合法的，這在很多情況下很難做到，但是通過使用Unicode字元類你可以明確指出名稱所需的字元範圍。已經有了一些其他不同語言和指令碼的類，所以如果你只想要解決希臘語和漢字，完全可以做到。Emojis符號正變得越來越普遍。
還有很多國際化 API,用於本地化的 時間和日期格式 ,歐元貨幣格式, 和 複數形式 , 這可以輕鬆地執行本地化標籤和按鈕。
ECMAScript 2018擴充套件了物件和數字對rest和spread模式的支援（在React生態系統中很常見，有些開發者還沒有意識到他還沒有完全標準化），Terslon稱有巨大的影響的小特性。rest和spread對於拷貝和克隆物件非常的有用。例如，你有一個不可變的結構，而你要改變除了一個屬性之外的所有內容，或者你想要複製一個物件但要新增一個額外的屬性。這個模式頻繁的運用為選項記錄分配預設值，Terslom強調，“對於你一直在做的事情來說，這是一個非常好的語法模式。”
類似於Babel和TypeScript的轉換器已經支援一些ECMAScript 2018的許多功能。瀏覽器支援也會伴隨著時間推移實現，並且所有的新特性已經裝載到Chrome的釋出版本上 (想要獲得完整的支援矩陣圖表，請檢視 ECMAScript 兼容表格 .)
根據ECMAScript相容性表格檢測到的瀏覽器支援情況。
未來的發展; ECMAScript 2019
一些有趣的提案至今沒有達到成為ECMAScript的標準的一部分所必需的第四個階段的程度，包括一些對私有欄位和方法的宣告的有爭議性的想法，其中包括很多備選提案。
當類被引入ECMAScript 6，它們是“最大地最小化”。Terslon解釋其中的意思，“故意在最小化，因為我們也會在以後繼續處理它們。”私人欄位將會允許開發者宣告可以在一個類的內部通過名稱進行引用的欄位，但是不允許從類的外部進行訪問，”他說。不僅僅是提供更好的效能，因為當在類建構函式中宣告所有欄位時，執行時可以更好地優化物件的處理，但也是語言強制實現隱私，而 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。