- 原文地址: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,但依然是迄今爲止最大的年度版本。javascript
身爲 ECMAScript 編輯及微軟在 ECMA TC39 委員會表明的 Brian Terlson 告訴 The New Stack:這個版本中兩個最大的開發者功能是異步生成器和一些期待已久的正則表達式改進,以及 rest/spread 屬性。html
「異步生成器和迭代器是將異步函數和迭代器結合起來的結果,因此它就像你能夠在其中等待的異步生成器或你能夠從中獲得返回值的異步函數,」他解釋道。之前,ECMAScript 容許你編寫一個能夠輸入或等待但不能同時進行二者操做的函數。「這對於在 Web 平臺佔比愈來愈大的消費流來講很是方便,尤爲是在 Fetch 對象公開流的狀況下。」前端
異步迭代器相似於 Observable 模式,但更靈活。「Observable 是推模型; 一旦你訂閱了它,不管你是否準備好,你都會被爆炸式的事件和通知衝擊,因此你必須實施緩衝或採樣策略來處理干擾,」Terlson 解釋道。異步迭代器是一種推拉模型 —— 你請求一個值後發送給你 —— 這對於諸如網絡 IO 原語之類的東西更有效。java
Promise.prototype.finally 對異步編程也頗有幫助,在一個 promise 狀態變爲 fulfilled 或 rejected 後,指定一個最終方法來進行清理。android
Terlson 對正則表達式的改進感到特別興奮(其中大部分工做都是由 V8 團隊完成的,他們已經完成了這四個主要功能的早期實現),由於這是此語言落後的領域。ios
「自從 JavaScript 誕生之日起,ECMAScript 正則表達式就沒有過顯著進步;幾乎全部其餘編程語言的正則表達式庫都比 ECMAScript 的功能高級。「ECMAScript 6 包含了一些小的更新,但他將 ECMAScript 2018 視爲「第一次明顯改變你如何編寫正則表達式的更新」。git
dotAll 標誌使點字符匹配全部字符,而再也不會對匹配一些換行符(好比 n 或 f )無效。「你不能使用點字符,除非你處於多行模式而且你不關心每行的結束,」他指出。這方面的變通辦法創造了一些沒必要要的複雜的正則表達式,Terlson 指望「每一個人都能在正則表達式中使用該模式」。es6
命名捕獲組與許多其餘語言中的命名組相似,你能夠在命名正則表達式匹配的字符串中的不一樣部分,並將其視爲對象。「這幾乎等同於在你的正則表達式中添加註釋,經過賦予它一個名字來解釋該組試圖捕捉的內容,」他解釋道。「這個模式的一部分是月份,這是出生日期......這對於將來其餘人維護你的模式真的頗有幫助。」github
還有其餘關於空字符的提案,即告訴正則表達式引擎忽略模式匹配中的空格、換行符以及註釋,容許在空格後的行尾添加註釋,這種特性可能包含在 ECMAScript 的將來版本中並將進一步提升可維護性。web
之前 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 標準的一部分所必需的第四階段,包括對私有字段和方法的聲明略有爭議的想法,其中包括許多備選提案。
當在 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、前端、後端、區塊鏈、產品、設計、人工智能等領域,想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。