ECMAScript 2021主要新功能 – thenewstack

banq發表於2021-06-12

ECMAScript 的下一個年度更新（JavaScript 語言的正式規範）將於今年 7 月釋出，今年對 JavaScript 的新增主要是著重改進方面，讓開發人員更愉快地使用該語言，提供新功能或更簡單的方式來表達可以用其他方式完成的事情。但是有一個強大的新選項也是對語言的一個相當根本的改變，它專門用於支援 WebAssembly。
 

Promise.any
使用Promise.any，JavaScript 現在有四種方法來處理非同步操作集來處理 promise 的解決方式（透過實現或拒絕）：

  • Race 允許您跟蹤多個promise 並在第一個承諾成功或失敗時立即採取行動。
  • 只有當所有的promise 都成功時，才成功。
  • allSettled 返回一個陣列，列出每個promise 是成功還是失敗。
  • any 會在任何promise 成功時立即成功來填補空白，如果它們都失敗則失敗。

當您遇到提供一些冗餘的情況時，Promise.any 最有用。想象一下，您可以從多個不同的網站獲取文件或資源。也許您希望透過並行地從多個不同的伺服器請求它來加速您的網站的效能，而您並不關心這些請求中的哪一個成功。你感興趣的只是第一個成功完成後的結果。
Promise.any 不會自動終止任何其他請求；在 Promise.any 返回結果後，您仍然需要手動取消它們。
如果所有的 Promise 都被拒絕， Promise.any 會返回一個聚合錯誤：來自每個 Promise 的單個錯誤的陣列，因為您可能需要準確地知道每個操作失敗的原因。
Promise.allSettled 向 JavaScript 引入了聚合錯誤。Promise.any對聚合錯誤進行了標準化，以確保任何未來的功能都將使用相同的語法——因為它是一種非常有用的錯誤型別，已經廣泛用於庫（以及他工作的 Azure SDK）中。ECMAScript 的未來版本可能包括向 Error 建構函式新增原因，連結一系列錯誤，以便您可以跟蹤它們來處理底層問題，這將與聚合錯誤一起工作。
 

String.prototype.replaceAll
字串的新替換函式修復了 JavaScript 中另一個長期存在的漏洞。
以前，除非您使用 /G 標誌並編寫全域性正規表示式來替換所有例項，否則替換隻會更改字串的第一個例項。StackOverflow 上很多開發人員正在尋找有關如何處理此問題的資訊，這是一個常見的絆腳石。
很多人可能只是沒有意識到這一點，並使用replace來實現替換功能，以為它將替換所有例項，然後沒有。現在那些不喜歡正規表示式的人終於可以有了他們一直想要的替換功能了。
 

邏輯賦值運算子
JavaScript 已經允許您透過組合數學運算子來編寫更簡潔的程式碼；x += y 而不是 x = x + y。
使用Logical assignment，開發人員將能夠使用 &&、或 || 等邏輯運算子執行類似數學運算一樣的操作： x ||= y 而不是 x ||(x = y)。
這是一種非常常見的語法糖，它避免了有人向你傳遞一個但有效的值，如 false、0 或空字串，但你最終會用預設值覆蓋它。
 

數字分隔符
當一個長數字被拆分成邏輯塊時，確保正確讀取它要容易得多。由於在 ECMAScript 2020 中引入了 BigInt，開發人員現在可以處理非常大的整數。數字分隔符是一種語法糖，透過用下劃線將它們分開，使這些長數字更易於閱讀，因此您可以輸入 1_000_000_000 而不是 1000000000 來表示 1,000,000,000。
下劃線已經在 J​​ava、Python、Perl、Ruby、Rust、Julia、Ada 和 C# 中以這種方式使用。這些下劃線沒有語義；他們純粹是為了讓我們的數字變得美麗。
 

Intl.DisplayNames
每個站點是否都需要自己的貨幣、語言或地區名稱的翻譯列表，以便在語言、地區和指令碼選擇器的下拉選單中使用？Intl.DisplayNames為一些常用（和翻譯）字串提供標準翻譯，例如語言名稱和星期幾。
在某些時候，您將需要一個下拉選單供使用者選擇語言，如果能夠做到這一點，而無需為每種語言手動建立翻譯，那就太好了，因為我們有資料庫具有本地語言本地名稱的計算機。
如果開發人員不需要包含人類可讀的語言、區域和指令碼顯示名稱形式，他們可以編寫更短、更易讀的 HTML 和 JavaScript。瀏覽器每次下載的內容都會減少，如果開發人員不編寫或複製貼上該程式碼（或編寫程式碼來解析 Intl.DateTimeFormat 的輸出），他們就不會在其中犯錯。這使得本地化變得更容易、更便宜。
 

WeakRef 和 FinalizationRegistry
JavaScript 的一大優勢是開發人員通常不需要進行手動記憶體管理，因此垃圾收集在各個瀏覽器和其他 JavaScript 引擎之間可能有所不同但不重要。通常，物件的引用可在 JavaScript 中被強保留：只要您有對物件的引用，它就不會被垃圾收集。
如果您想透過刪除不再需要儲存的資料來節省記憶體，則必須明確刪除強引用，例如事件偵聽器。即使現有的 WeakMap 和 WeakSet 構造也不是真正的弱引用：新的 WeakRef 是一個真正的弱引用，您可以使用它來包裝事件偵聽器之類的東西，因此它們可以被垃圾收集。
這是 JavaScript 中的一項基本新功能，在哲學上與通常的方法非常不同。
當您確實需要使用事件偵聽器或透過線上性緩衝區中分配記憶體來進行手動記憶體跟蹤時，JavaScript 沒有很好的構造來處理它。怎麼把這自動和手動處理記憶體的兩個世界結合起來？
WeakRef 解決了這個問題，儘管代價是額外的工作，無論何時你想使用物件，也許是取消引用它，你必須問它，'你還在嗎？' 如果其他人都發布了對它的強引用，您可能會發現它不再存在。
這也有助於處理訂閱等相關資源；讓訂閱回撥使用弱引用來輪詢物件意味著當不再需要主物件時，訂閱不會意外地使主物件保持活動狀態。
缺點：弱引用可能意味著開發人員正在編寫不再可移植的程式碼。
那麼為什麼要引入一個被 ECMAScript 6 考慮並拒絕並且可能永遠不會被絕大多數 JavaScript 開發人員使用的潛在危險特性呢？因為它改進了與 WebAssembly 的整合——在 JavaScript 引擎中實現的日益流行的記憶體安全、沙盒、執行環境。
  

符合人體工程學的Finalizers
Finalizer用途：程式設計師可以註冊回撥，這樣能在物件被垃圾回收時接收事件，而不是輪詢物件，這樣他們就可以刪除支援它的資源。
為了避免出現問題，他建議不要在Finalizer終結器後面控制重要的行為；根據 JavaScript 引擎，垃圾收集執行時可能不會立即呼叫Finalizer終結器，它們可能不會按順序呼叫，並且在某些情況下——比如在高效能情況下執行的緊密迴圈——它們可能根本不會被呼叫。
 

相關文章