Hallo Leute! Als ich vor einiger Zeit die neuesten TC39-Vorschl?ge durchst?berte, stie? ich auf eines, das mich begeisterte – und ein wenig skeptisch machte. Es geht um eine teilweise Anwendungssyntax für JavaScript. Auf den ersten Blick scheint es die perfekte L?sung für viele h?ufig auftretende Programmierprobleme zu sein, aber als ich darüber nachdachte, wurde mir klar, dass es sowohl viel zu m?gen als auch Raum für Verbesserungen gibt. ?

Noch besser: Diese Bedenken l?sten eine v?llig neue Idee aus, die JavaScript noch leistungsf?higer machen k?nnte. Lassen Sie mich Sie auf diese Reise mitnehmen, komplett mit realistischen Beispielen, wie diese Funktionen die Art und Weise, wie wir jeden Tag programmieren, ver?ndern k?nnten.

TLDR: Der Artikel stammt aus meiner alten Ausgabe zum Vorschlag: https://github.com/tc39/proposal-partial-application/issues/53

Der Vorschlag

Mit der teilweisen Anwendung k?nnen Sie einige Argumente einer Funktion ?voreinstellen“ und so eine neue Funktion zur sp?teren Verwendung zurückgeben. Unser aktueller Code sieht so aus:

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

Der Vorschlag führt hierfür eine ~()-Syntax ein:

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

Sehen Sie, was passiert? Die fetchWithAuth-Funktion füllt das Header-Argument vorab aus, sodass Sie nur die URL angeben müssen. Es ist wie .bind(), aber flexibler und einfacher zu lesen.

Der Vorschlag erm?glicht Ihnen auch die Verwendung von ? als Platzhalter für unbefüllte Argumente und ... für einen Restparameter. Zum Beispiel:

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

Mir gef?llt am besten, dass ich die Typanmerkungen nicht duplizieren muss!

Klingt nützlich, oder? Aber es gibt noch viel mehr zu entpacken.

Das Argument für referenzielle Transparenz

Beginnen wir mit einem praktischen Problempunkt: Funktionsabschlüsse und veraltete Variablenreferenzen.

Angenommen, Sie planen eine Benachrichtigung. Sie k?nnten so etwas schreiben:

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

Haben Sie das Problem bereits gesehen? Die Eigenschaft ?data“ kann sich w?hrend des Timeouts ?ndern und die Warnung zeigt nichts an! Um dieses Problem zu beheben, muss die Wertreferenz explizit übergeben werden. Hoffentlich akzeptiert ?setTimeout“ zus?tzliche Argumente, um sie an den Rückruf zu übergeben:

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

Nicht schlecht, aber es wird nicht allgemein von allen APIs unterstützt. Eine teilweise Anwendung k?nnte dieses Muster weitaus universeller machen:

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

Durch das Sperren von state.data zum Zeitpunkt der Funktionserstellung vermeiden wir unerwartete Fehler aufgrund veralteter Referenzen.

Reduzierung wiederholter Berechnungen

Ein weiterer praktischer Vorteil der Teilanwendung besteht darin, dass redundante Arbeiten bei der Verarbeitung gro?er Datens?tze entfallen.

Zum Beispiel haben Sie eine Mapping-Logik, die für jeden Iterationsschritt zus?tzliche Daten berechnen muss:

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

Das Problem liegt im Proxy-Zugriff auf this.some.another. Es ist ziemlich schwer, jeden Iterationsschritt aufzurufen. Es w?re besser, diesen Code wie folgt umzugestalten:

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

Mit der teilweisen Anwendung k?nnen wir es weniger ausführlich machen:

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

Durch das Einbinden gemeinsamer Berechnungen machen Sie den Code pr?gnanter und leichter verst?ndlich, ohne dass die Leistung darunter leidet.

Warum neue Syntax hinzufügen?

Hier fing ich an, mir den Kopf zu zerbrechen. W?hrend die vorgeschlagene Syntax elegant ist, verfügt JavaScript bereits über viele Operatoren. Besonders die Fragezeichenoperatoren? Das Hinzufügen von ~() kann das Erlernen und Parsen der Sprache erschweren.

Was w?re, wenn wir die gleiche Funktionalit?t erreichen k?nnten, ohne eine neue Syntax einzuführen?

Eine methodenbasierte Alternative

Stellen Sie sich vor, Function.prototype mit einer Tie-Methode zu erweitern:

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

Es ist etwas ausführlicher, vermeidet aber die Einführung eines v?llig neuen Operators. Durch ein zus?tzliches Sonderzeichen für Platzhalter k?nnen wir das Fragezeichen ersetzen.

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

Es ist ein perfektes Polypiling ohne zus?tzliche Komplexit?t in der Bauzeit!

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

Aber das ist nur die Spitze des Eisbergs. Dadurch wird das Platzhalterkonzept über verschiedene APIs hinweg wiederverwendbar.

Lazy Operations: Noch weiter gehen

Hier wird es richtig interessant. Was w?re, wenn wir das Symbolkonzept erweitern würden, um Lazy Operations zu erm?glichen?

Beispiel 1: Kombination von .filter() und .map()

Angenommen, Sie bearbeiten eine Produktliste für eine E-Commerce-Website. Sie m?chten nur reduzierte Artikel mit gerundeten Preisen anzeigen. Normalerweise würden Sie Folgendes schreiben:

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

Dies erfordert jedoch eine zweimalige Iteration über das Array. Mit Lazy Operations k?nnten wir beide Schritte in einem Durchgang kombinieren:

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 weist die Engine an, Elemente aus dem endgültigen Array auszuschlie?en, wodurch der Vorgang sowohl effizient als auch ausdrucksstark wird!

Beispiel 2: Vorzeitige Beendigung in .reduce()

Stellen Sie sich vor, Sie berechnen den Gesamtumsatz aus den ersten fünf Verk?ufen. Normalerweise würden Sie eine Bedingung innerhalb von .reduce():
verwenden

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

Das funktioniert, verarbeitet aber trotzdem jedes Element im Array. Mit verz?gerten Kürzungen k?nnten wir eine vorzeitige Kündigung signalisieren:

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

Das Vorhandensein von Symbol.skip k?nnte der Engine mitteilen, dass sie die Iteration stoppen soll, sobald die Bedingung erfüllt ist, wodurch wertvolle Zyklen eingespart werden.

Warum das wichtig ist

Diese Ideen – teilweise Anwendung, referenzielle Transparenz und verz?gerte Operationen – sind nicht nur akademische Konzepte. Sie l?sen reale Probleme:

• Sauberere API-Nutzung: Argumente im Voraus sperren und veraltete Referenzen vermeiden.
• Verbesserte Leistung: Eliminieren Sie redundante Berechnungen und erm?glichen Sie eine effizientere Iteration.
• Gr??ere Ausdruckskraft:Schreiben Sie pr?gnanten, deklarativen Code, der einfacher zu lesen und zu warten ist.

Ob wir bei ~() bleiben oder Alternativen wie tie und Symbol.skip erkunden, die zugrunde liegenden Prinzipien haben ein enormes Potenzial, die Art und Weise, wie wir JavaScript schreiben, zu verbessern.

Ich stimme für den Symbolansatz, da er leicht mehrfach auszufüllen ist und verschiedene Verwendungsm?glichkeiten bietet.

Was kommt als n?chstes?

Ich bin neugierig – was denkst du? Ist ~() die richtige Richtung oder sollten wir methodenbasierte Ans?tze erkunden? Und wie würden sich Lazy Operations auf Ihren Arbeitsablauf auswirken? Lasst uns in den Kommentaren diskutieren!

Das Sch?ne an JavaScript liegt in seiner von der Community vorangetriebenen Entwicklung. Indem wir Ideen austauschen und diskutieren, k?nnen wir eine Sprache entwickeln, die für alle besser funktioniert. Lassen Sie uns das Gespr?ch am Laufen halten!

Das obige ist der detaillierte Inhalt vonJavaScript neu denken. Teilweise Anwendung, referenzielle Transparenz und verz?gerte Operationen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!