重新思考 JavaScript。部分應用、引用透明和惰性操作

大家好！前段時間，在瀏覽最新的 TC39 提案時，我偶然發現了一個讓我興奮但又有點懷疑的提案。這是關於 JavaScript 的部分應用程式語法。乍一看，這似乎是解決許多常見編碼問題的完美方法，但當我仔細考慮時，我意識到它既有很多值得喜歡的地方，也有一些改進的空間。  

更好的是，這些擔憂引發了一個全新的想法，可以讓 JavaScript 變得更強大。讓我帶您踏上這段旅程，並透過現實的例子來說明這些功能如何改變我們每天的編碼方式。

TLDR：這篇文章來自我對提案的舊問題：https://github.com/tc39/proposal-partial-application/issues/53

---

提案

部分應用程式可讓您「預設」函數的一些參數，傳回一個新函數以供以後使用。我們目前的程式碼如下所示：

const fetchWithAuth = (path: string) => fetch(
  { headers: { Authorization: "Bearer token" } },
  path,
);
fetchWithAuth("/users");
fetchWithAuth("/posts");

該提案為此引入了 ~() 語法：

const fetchWithAuth = fetch~({ headers: { Authorization: "Bearer token" } }, ?);
fetchWithAuth("/users");
fetchWithAuth("/posts");

看看發生了什麼事？ fetchWithAuth 函數預先填入 headers 參數，因此您只需提供 URL。它類似於 .bind() 但更靈活且更易於閱讀。

該提案還允許您使用 ?作為未填充參數的佔位符和...作為剩餘參數。例如：

const sendEmail = send~(user.email, ?, ...);
sendEmail("Welcome!", "Hello and thanks for signing up!");
sendEmail("Reminder", "Don't forget to confirm your email.");

我最喜歡的部分是我不需要重複類型註解！

聽起來很有用，對吧？但還有很多東西要解開。

---

參考透明度的案例

讓我們從一個實際的痛點開始：函數閉包和過時的變數參考。

假設您正在安排一些通知。你可能會寫這樣的內容：

function notify(state: { data?: Data }) {
  if (state.data) {
      setTimeout(() => alert(state.data), 1000)
  }
}

你已經看到問題了嗎？ 「資料」屬性可能會在逾時期間發生變化，且警報將不會顯示任何內容！修復此問題需要明確傳遞值引用，希望“setTimeout”接受其他參數以將其傳遞到回調：

function notify(state: { data?: Data }) {
  if (state.data) {
      setTimeout((data) => alert(data), 1000, state.data)
  }
}

還不錯，但 API 並未廣泛支援。部分應用可以讓這種模式更普遍：

function notify(state: { data?: Data }) {
  if (state.data) {
      setTimeout(alert~(state.data), 1000)
  }
}

透過在函數建立時鎖定 state.data，我們可以避免因為過時的參考而出現意外錯誤。

---

減少重複計算

部分應用程式的另一個實際好處是消除處理大型資料集時的冗餘工作。

例如，你有一個映射邏輯，它需要為每個迭代步驟計算額外的資料：

const fetchWithAuth = (path: string) => fetch(
  { headers: { Authorization: "Bearer token" } },
  path,
);
fetchWithAuth("/users");
fetchWithAuth("/posts");

問題在於代理存取 this.some.another，呼叫每個迭代步驟非常繁重。最好像這樣重構這段程式碼：

const fetchWithAuth = fetch~({ headers: { Authorization: "Bearer token" } }, ?);
fetchWithAuth("/users");
fetchWithAuth("/posts");

透過部分應用，我們可以做得更簡潔：

const sendEmail = send~(user.email, ?, ...);
sendEmail("Welcome!", "Hello and thanks for signing up!");
sendEmail("Reminder", "Don't forget to confirm your email.");

透過烘焙共享計算，您可以使程式碼更加簡潔且更易於遵循，而不會犧牲效能。

---

為什麼要新增語法？

現在，這就是我開始搔頭的地方。雖然提議的語法很優雅，但 JavaScript 已經有很多運算符。特別是問號運算子？ 。添加 ~() 可能會使語言更難學習和解析。

如果我們可以在不引入新語法的情況下實現相同的功能怎麼辦？

---

基於方法的替代方案

想像一下使用 tie 方法擴充 Function.prototype：

function notify(state: { data?: Data }) {
  if (state.data) {
      setTimeout(() => alert(state.data), 1000)
  }
}

它有點冗長，但避免引入全新的運算子。使用額外的特殊符號作為佔位符，我們可以替換問號。

function notify(state: { data?: Data }) {
  if (state.data) {
      setTimeout((data) => alert(data), 1000, state.data)
  }
}

它是完美的多重堆積，沒有額外的建造時間複雜性！

function notify(state: { data?: Data }) {
  if (state.data) {
      setTimeout(alert~(state.data), 1000)
  }
}

但這只是冰山一角。它使得佔位符概念可以在不同的 API 之間重複使用。

---

惰性操作：更進一步

這就是事情變得非常有趣的地方。如果我們擴展符號概念以啟用惰性運算會怎麼樣？

範例 1：組合 .filter() 和 .map()

假設您正在處理電子商務網站的產品清單。您只想顯示折扣商品，並對其價格進行四捨五入。通常，你會這樣寫：

class Store  {
  data: { list: [], some: { another: 42 } }
  get computedList() {
    return this.list.map((el) => computeElement(el, this.some.another))
  }
  contructor() {
    makeAutoObservable(this)
  }
}

但這需要迭代數組兩次。透過惰性操作，我們可以將這兩個步驟合併為一次：

class Store  {
  data: { list: [], some: { another: 42 } }
  get computedList() {
    const { another } = this.some
    return this.list.map((el) => computeElement(el, another))
  }
  contructor() {
    makeAutoObservable(this)
  }
}

Symbol.skip 告訴引擎從最終數組中排除項目，使操作既高效又富有表現力！

範例 2：.reduce() 中的提前終止

想像一下計算前五次銷售的總收入。通常，您會在 .reduce() 中使用條件：

class Store  {
  data: { list: [], some: { another: 42 } }
  get computedList() {
    return this.list.map(computeElement~(?, this.some.another))
  }
  contructor() {
    makeAutoObservable(this)
  }
}

這可行，但它仍然處理數組中的每個項目。透過惰性減少，我們可以發出提前終止的訊號：

function notify(state: { data?: Data }) {
  if (state.data) {
      setTimeout(alert.tie(state.data), 1000)
  }
}

Symbol.skip 的存在可以告訴引擎一旦滿足條件就停止迭代，從而節省寶貴的週期。

---

為什麼這很重要

這些想法——部分應用、引用透明和惰性操作——不僅僅是學術概念。他們解決現實世界的問題：

• 更簡潔的 API 使用： 預先鎖定參數並避免過時的參考。
• 提高效能：消除冗餘運算並實現更有效率的迭代。
• 更強的表現力：編寫簡潔的聲明性程式碼，更容易閱讀和維護。

無論我們堅持使用 ~() 或探索像 tie 和 Symbol.skip 這樣的替代方案，基本原理都具有巨大的潛力來提高我們編寫 JavaScript 的水平。

我投票支持符號方法，因為它很容易填充並且有多種用途。

---

接下來是什麼？

我很好奇－你覺得怎麼樣？ ~() 是正確的方向嗎，還是我們應該探索基於方法的方法？ 惰性操作將如何影響您的工作流程？評論裡一起討論吧！

JavaScript 的美妙之處在於它由社群驅動的演變。透過分享和辯論想法，我們可以塑造出更適合每個人的語言。讓我們繼續對話吧！

以上是重新思考 JavaScript。部分應用、引用透明和惰性操作的詳細內容。更多資訊請關注PHP中文網其他相關文章！