?

2024年JavaScript新特性做了哪些升級(jí)？讓我們來(lái)回顧一下ES15帶來(lái)的全新的特性和有前景的提案。（ "ES15" 是指 ECMAScript 2024。ECMAScript 是 JavaScript 的標(biāo)準(zhǔn)，由 ECMA International 的技術(shù)委員會(huì) TC39 負(fù)責(zé)制定。）

讓我們一起來(lái)盤(pán)點(diǎn)一下那些令人驚嘆的5項(xiàng)JavaScript新功能。

數(shù)組原生的group-by方法

Object.groupBy()：

有了它，也就不在需要Lodash了，現(xiàn)在看Lodash基本大部分功能都有了原生的支持。

我本以為還會(huì)有一個(gè)類似 Array.prototype.groupBy 的新實(shí)例方法，但不知出于什么原因，它并沒(méi)有增加到數(shù)組上。

反倒是在Map上增加了一個(gè)靜態(tài)方法， Map.groupBy 對(duì)對(duì)象鍵進(jìn)行分組：

目前支持使用groupBy的，就是Object和Map了。

Promise.withResolvers

有了Promise.withResolvers()，創(chuàng)建Promise更簡(jiǎn)單了，而在此之前，我們不得不通過(guò)閉包來(lái)實(shí)現(xiàn)：

或者從 NPM 安裝 - 多一個(gè)依賴項(xiàng)！

但現(xiàn)在有了 ES15 中的 Promise.withResolvers()：

Promise.withResolvers使得做開(kāi)關(guān)延遲特別方便，例如在資源加載完畢后resolve。這允許我們?cè)赑romise外部控制加載過(guò)程，實(shí)現(xiàn)更有效的延遲加載策略，優(yōu)化頁(yè)面加載時(shí)間和性能。

Buffer性能升級(jí)

Buffer是用于存儲(chǔ)應(yīng)用程序生成的臨時(shí)數(shù)據(jù)的微型數(shù)據(jù)存儲(chǔ)區(qū)。它們使在pipeline的各個(gè)階段傳輸和處理數(shù)據(jù)變得異常簡(jiǎn)單。

像以下的Pipelines:

• 文件處理: Input file → buffer → process → new buffer → output file
• 視頻流: Network response → buffer → display video frame
• 生產(chǎn)消費(fèi)隊(duì)列: Receive customer → queue/buffer → serve customer

有了緩沖器，每個(gè)階段處理數(shù)據(jù)的速度各不相同，互不影響。

但是，如果流水線上的數(shù)據(jù)超過(guò)了緩沖區(qū)的容量，會(huì)發(fā)生什么情況呢？

在此之前，我們必須將當(dāng)前數(shù)據(jù)的緩沖區(qū)全部復(fù)制到一個(gè)更大的緩沖區(qū)中。

這對(duì)性能的影響非常大，尤其是當(dāng)管道中會(huì)有大量數(shù)據(jù)時(shí)。

ES15 為我們提供了解決這一問(wèn)題的方法：可調(diào)整的數(shù)組緩沖區(qū)。

異步升級(jí)

Atomics.waitAsync()：ES2024 中另一個(gè)強(qiáng)大的異步編碼功能：

在JavaScript中，Atomics對(duì)象提供了一組靜態(tài)方法，用于在多線程環(huán)境中以原子方式執(zhí)行操作，比如共享內(nèi)存的操作。Atomics.waitAsync()方法允許開(kāi)發(fā)者在異步環(huán)境中等待某個(gè)條件變量達(dá)到特定值，這在并發(fā)編程中非常有用，因?yàn)樗梢员苊庾枞骶€程，同時(shí)等待某個(gè)事件的發(fā)生。

例如：當(dāng)兩個(gè)代理共享一個(gè)緩沖區(qū)時(shí)

而代理 1 則 Sleep"，等待代理 2 完成任務(wù)。

當(dāng)代理 2 完成后，它會(huì)使用共享緩沖區(qū)作為通道發(fā)出通知。

如果你認(rèn)為這與普通的 async/await 類似，那你就完全正確了。

但最大的區(qū)別在于這兩個(gè)代理可以存在于完全不同的代碼上下文中，它們只需要訪問(wèn)同一個(gè)緩沖區(qū)。

而且：多個(gè)代理可以在不同時(shí)間訪問(wèn)或等待共享緩沖區(qū)，其中任何一個(gè)代理都可以通知 "喚醒 "所有其他代理。

這怎么理解？假設(shè)我們有兩個(gè)Web Workers，一個(gè)主線程和多個(gè)工作線程。工作線程將等待主線程更新一個(gè)共享的內(nèi)存位置。

主線程代碼：

// 創(chuàng)建一個(gè)共享的ArrayBuffer
const sharedBuffer = new SharedArrayBuffer(4);
const sharedUint32 = new Uint32Array(sharedBuffer);

// 初始值設(shè)置為0
sharedUint32[0] = 0;

// 創(chuàng)建一個(gè)Worker
const worker = new Worker('worker.js');

// 向Worker發(fā)送共享內(nèi)存的引用
worker.postMessage({ sharedBuffer });

// 稍后更新共享內(nèi)存的值
setTimeout(() => {
  sharedUint32[0] = 1; // 這個(gè)值的改變將觸發(fā)等待中的Atomics.waitAsync()
}, 1000);

工作線程代碼（worker.js）：

// 監(jiān)聽(tīng)主線程發(fā)送的消息
onmessage = async ({ data }) => {
  const { sharedBuffer } = data;
  const sharedUint32 = new Uint32Array(sharedBuffer);

  // 等待sharedUint32[0]的值變?yōu)?
while (true) {
    const value = Atomics.waitAsync(sharedUint32, 0, 0);
    if (value === 1) {
      console.log('Value has changed to 1!');
      break;
    }
  }

  // 做一些工作...
  console.log('Processing data...');
};

在這個(gè)例子中，工作線程使用Atomics.waitAsync()在共享內(nèi)存位置sharedUint32[0]上等待，直到它的值變?yōu)?。主線程在1秒后更新這個(gè)值為1，這將觸發(fā)工作線程中的等待，工作線程隨后繼續(xù)執(zhí)行。

正則升級(jí)：v表示&集合操作

為了匹配不斷增加的 Unicode 字符集，如

• 表情符號(hào)：??、??、??、?? 等。
• 重音字母：é、à、?、? 等。
• 符號(hào)和非拉丁字符：?、?、€、￡、μ、￥ 等

因此，我們?cè)谶@里使用 Unicode regex 和 v 標(biāo)志來(lái)匹配所有希臘字母：

另外在正則表達(dá)式中，集合操作指的是使用字符集（character sets）來(lái)匹配多個(gè)字符。例如：

• [abc]：匹配任何一個(gè)字符a、b或c
• [^abc]：匹配任何不是a、b或c的字符
• [a-z]：匹配任何小寫(xiě)字母

而新的語(yǔ)法里增加了如下的新操作符

總結(jié)

總體而言，2024 對(duì) JavaScript 來(lái)說(shuō)是一次重大飛躍，它具備了現(xiàn)代開(kāi)發(fā)所必需的多項(xiàng)功能。

幫助你寫(xiě)出更簡(jiǎn)潔、更具表現(xiàn)力和更清晰的代碼。

閱讀原文：https://mp.weixin.qq.com/s/cHLL6cmCoGmbJMCrUobLig