皆さんこんにちは！少し前に、最新の TC39 提案を閲覧しているときに、私は興奮すると同時(shí)に少し懐疑的な提案を見(jiàn)つけました。 JavaScript の部分的なアプリケーション構(gòu)文についてです。一見(jiàn)すると、これは多くの一般的なコーディングの問(wèn)題に対する完璧な解決策のように思えますが、よく考えてみると、気に入った點(diǎn)と改善の余地がたくさんあることに気付きました。 ?

さらに良いことに、これらの懸念は、JavaScript をさらに強(qiáng)力にする可能性があるまったく新しいアイデアを引き起こしました。これらの機(jī)能が私たちの日々のコーディング方法をどのように変える可能性があるかを示す現(xiàn)実的な例を交えて、この旅にあなたを連れて行きましょう。

TLDR: 記事は私の古い問(wèn)題から提案に基づいています: https://github.com/tc39/proposal-partial-application/issues/53

---

提案

部分アプリケーションでは、関數(shù)の一部の引數(shù)を「事前設(shè)定」して、後で使用できるように新しい関數(shù)を返すことができます?，F(xiàn)在のコードは次のようになります:

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

この提案では、次のような ~() 構(gòu)文が導(dǎo)入されています。

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

何が起こっているかわかりますか? fetchWithAuth 関數(shù)は headers 引數(shù)を事前に入力するため、URL を指定するだけで済みます。 .bind() に似ていますが、より柔軟で読みやすくなっています。

この提案では、? の使用も許可されています。未入力の引數(shù)のプレースホルダーとして、および殘りのパラメーターの ... として。例:

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

私の気に入っている點(diǎn)は、型の注釈を複製する必要がないことです!

便利そうですね?しかし、開(kāi)梱すべきことはまだたくさんあります。

---

參照の透明性のケース

実際的な問(wèn)題點(diǎn)から始めましょう: 関數(shù)のクロージャーと古い変數(shù)參照

何らかの通知をスケジュールしているとします。次のように書(shū)くとよいでしょう:

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

問(wèn)題はもうわかりましたか? 「データ」プロパティはタイムアウト中に変更される可能性があり、アラートには何も表示されません。これを修正するには、値の參照を明示的に渡す必要があります。できれば、「setTimeout」で追加の引數(shù)を受け入れて、それをコールバックに渡します:

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)
  }
}

関數(shù)作成時(shí)に state.data をロックすることで、古い參照による予期せぬバグを回避します。

---

繰り返しの計(jì)算を減らす

部分適用のもう 1 つの実用的な利點(diǎn)は、大規(guī)模なデータセットを処理する際の冗長(zhǎng)な作業(yè)を排除できることです。

たとえば、反復(fù)ステップごとに追加データを計(jì)算する必要があるマッピング ロジックがあるとします。

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

問(wèn)題は this.some.another へのプロキシ アクセスにあり、各反復(fù)ステップを呼び出すとかなり負(fù)荷がかかります。このコードを次のようにリファクタリングする方が良いでしょう:

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

部分的な適用を使用すると、冗長(zhǎng)性を減らすことができます:

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

共有計(jì)算を組み込むことで、パフォーマンスを犠牲にすることなく、コードがより簡(jiǎn)潔になり、理解しやすくなります。

---

新しい構(gòu)文を追加する理由

さて、ここからが頭を悩ませ始めました。提案された構(gòu)文は洗練されていますが、JavaScript にはすでに多くの演算子があります。特に疑問(wèn)符演算子 ? 。 ~() を追加すると、言語(yǔ)の學(xué)習(xí)と解析が難しくなる可能性があります。

新しい構(gòu)文を?qū)毪护氦送笝C(jī)能を?qū)g現(xiàn)できたらどうなるでしょうか?

---

メソッドベースの代替案

tie メソッドを使用して Function.prototype を拡張することを想像してください:

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

これはもう少し冗長(zhǎng)ですが、まったく新しい演算子の導(dǎo)入を避けています。プレースホルダーに追加の特殊記號(hào)を使用すると、疑問(wèn)符を置き換えることができます。

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

ビルド時(shí)の複雑さを追加することなく、完全にポリパイルされています!

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

しかし、これは氷山の一角にすぎません。これにより、プレースホルダーの概念がさまざまな API 間で再利用可能になります。

---

遅延操作: さらに進(jìn)化

ここからが本當(dāng)に興味深いことになります。シンボルの概念を拡張して遅延操作を可能にしたらどうなるでしょうか?

例 1: .filter() と .map() の組み合わせ

電子商取引サイトの製品リストを処理していると仮定します。価格を四捨五入して割引商品のみを表示したいとします。通常は次のように書(shū)きます:

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

しかし、これには配列を 2 回繰り返す必要があります。遅延操作を使用すると、両方のステップを 1 つのパスに結(jié)合できます。

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 は、最終的な配列から項(xiàng)目を除外するようにエンジンに指示し、操作を効率的かつ表現(xiàn)力豊かにします。

例 2: .reduce() での早期終了

最初の 5 つの販売からの合計(jì)収益を計(jì)算することを想像してください。通常、.reduce():
內(nèi)で條件を使用します。

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

これは機(jī)能しますが、それでも配列內(nèi)のすべての項(xiàng)目が処理されます。遅延リダクションを使用すると、早期終了を通知できます:

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

Symbol.skip が存在すると、條件が満たされるとすぐに反復(fù)を停止するようにエンジンに指示でき、貴重なサイクルを節(jié)約できます。

---

なぜこれが重要なのか

これらのアイデア (部分的な適用、參照の透明性、遅延操作) は、単なる學(xué)術(shù)的な概念ではありません。彼らは現(xiàn)実世界の問(wèn)題を解決します:

• よりクリーンな API の使用法: 引數(shù)を事前にロックし、古い參照を回避します。
• パフォーマンスの向上: 冗長(zhǎng)な計(jì)算を排除し、より効率的な反復(fù)を可能にします。
• 表現(xiàn)力の向上: 読みやすく保守しやすい、簡(jiǎn)潔な宣言型コードを作成します。

~() に固執(zhí)するか、tie や Symbol.skip などの代替案を検討するかにかかわらず、基礎(chǔ)となる原則には JavaScript の記述方法をレベルアップする大きな可能性があります。

ポリフィルが簡(jiǎn)単でさまざまな用途があるため、私はシンボルのアプローチに投票します。

---

次は何ですか?

興味があるのですが、どう思いますか? ~() は正しい方向ですか? それともメソッドベースのアプローチを検討する必要がありますか?そして遅延操作はワークフローにどのような影響を與えるでしょうか?コメントで議論しましょう!

JavaScript の美しさは、コミュニティ主導(dǎo)の進(jìn)化にあります。アイデアを共有し、議論することで、誰(shuí)にとってもより適切に機(jī)能する言語(yǔ)を形作ることができます。會(huì)話を続けましょう！

以上がJavaScript を再考する。部分的な適用、參照の透明性、遅延操作の詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國(guó)語(yǔ) Web サイトの他の関連記事を參照してください。