39 Posts getaggt mit "ECMAScript"

Der Vorschlag Explizites Ressourcenmanagement führt einen deterministischen Ansatz ein, um den Lebenszyklus von Ressourcen wie Datei-Handles, Netzwerkverbindungen und mehr ausdrücklich zu verwalten. Dieser Vorschlag bringt folgende Erweiterungen in die Sprache ein: die using- und await using-Deklarationen, die automatisch die Dispose-Methode aufrufen, wenn eine Ressource aus dem Gültigkeitsbereich fällt; [Symbol.dispose]()- und [Symbol.asyncDispose]()-Symbole für Bereinigungsoperationen; zwei neue globale Objekte DisposableStack und AsyncDisposableStack als Container zur Aggregation von disposablen Ressourcen; und SuppressedError als neuen Fehler-Typ (enthält sowohl den zuletzt geworfenen Fehler als auch den unterdrückten Fehler), um das Szenario zu adressieren, in dem während der Bereinigung einer Ressource ein Fehler auftritt und möglicherweise ein bereits vorhandener Fehler verdeckt wird, der aus dem Body oder der Bereinigung einer anderen Ressource geworfen wurde. Diese Erweiterungen ermöglichen es Entwicklern, robusteren, leistungsfähigeren und leichter wartbaren Code zu schreiben, indem sie eine feingliedrige Kontrolle über die Ressourcenbereinigung bieten.

Iterator-Helfer sind eine Sammlung neuer Methoden auf dem Iterator-Prototyp, die bei der allgemeinen Verwendung von Iteratoren helfen. Da sich diese Hilfsmethoden auf dem Iterator-Prototyp befinden, erhalten alle Objekte, die Iterator.prototype in ihrer Prototypenkette haben (z. B. Array-Iteratoren), diese Methoden. In den folgenden Abschnitten erklären wir die Iterator-Helfer. Alle bereitgestellten Beispiele funktionieren auf einer Blog-Archivseite, die eine Liste von Blog-Beiträgen enthält, und veranschaulichen, wie Iterator-Helfer beim Finden und Bearbeiten der Beiträge hilfreich sind. Sie können sie auf der V8-Blogseite ausprobieren!

Bisher​

V8 hat die Funktion Import Assertions in Version 9.1 veröffentlicht. Diese Funktion erlaubte es Importanweisungen für Module, zusätzliche Informationen mit dem Schlüsselwort assert hinzuzufügen. Diese zusätzlichen Informationen werden aktuell verwendet, um JSON- und CSS-Module innerhalb von JavaScript-Modulen zu importieren.

JavaScript unterstützt reguläre Ausdrücke seit ECMAScript 3 (1999). Sechzehn Jahre später führte ES2015 Unicode-Modus (das u-Flag), Sticky-Modus (das y-Flag) und die RegExp.prototype.flags Getter-Funktion ein. Weitere drei Jahre später führte ES2018 dotAll-Modus (das s-Flag), Lookbehind-Assertions, Named Capture Groups und Unicode-Zeicheneigenschafts-Auswege ein. Und in ES2020 erleichterte String.prototype.matchAll die Arbeit mit regulären Ausdrücken. JavaScript-Regular Expressions haben sich enorm weiterentwickelt und verbessern sich weiterhin.

Elemente von Anfang an finden​

Das Finden eines Elements, das eine bestimmte Bedingung in einem Array erfüllt, ist eine häufige Aufgabe und wird mit den Methoden find und findIndex von Array.prototype sowie den verschiedenen TypedArray-Prototypen durchgeführt. Array.prototype.find nimmt ein Prädikat und gibt das erste Element im Array zurück, für das dieses Prädikat true zurückgibt. Wenn das Prädikat für kein Element true zurückgibt, gibt die Methode undefined zurück.

Die neue at-Methode auf Array.prototype, den verschiedenen TypedArray-Prototypen und String.prototype macht das Zugreifen auf ein Element näher am Ende der Sammlung einfacher und prägnanter.

Der Zugriff auf das N-te Element vom Ende einer Sammlung ist eine häufige Operation. Jedoch sind die üblichen Wege dafür umständlich, wie my_array[my_array.length - N], oder möglicherweise nicht performant, wie my_array.slice(-N)[0]. Die neue at-Methode macht diese Operation ergonomischer, indem negative Indizes interpretiert werden, um "vom Ende" zu bedeuten. Die vorherigen Beispiele können als my_array.at(-N) ausgedrückt werden.

Stellen Sie sich vor, Sie haben eine Funktion, die zwei separate Arbeitslasten doSomeWork und doMoreWork aufruft. Beide Funktionen können dieselben Arten von Fehlern werfen, aber Sie müssen sie auf unterschiedliche Weise behandeln.

Das Abfangen des Fehlers und das erneute Werfen mit zusätzlichen Kontextinformationen ist ein häufiger Ansatz für dieses Problem, beispielsweise:

function doWork() {
  try {
    doSomeWork();
  } catch (err) {
    throw new CustomError('Einige Arbeiten fehlgeschlagen', err);
  }
  doMoreWork();
}

try {
  doWork();
} catch (err) {
  // Kommt |err| von |doSomeWork| oder von |doMoreWork|?
}

Leider ist die obige Lösung mühsam, da man seinen eigenen CustomError erstellen muss. Und noch schlimmer ist, dass kein Entwicklerwerkzeug in der Lage ist, hilfreiche Diagnosen für unerwartete Ausnahmen zu liefern, da kein Konsens darüber besteht, wie diese Fehler richtig dargestellt werden.

Heutzutage ist es sehr üblich, einen Code wie diesen zu schreiben:

const hasOwnProperty = Object.prototype.hasOwnProperty;

if (hasOwnProperty.call(object, 'foo')) {
  // `object` hat die Eigenschaft `foo`.
}

Oder Bibliotheken zu verwenden, die eine vereinfachte Version von Object.prototype.hasOwnProperty bereitstellen, wie z. B. has oder lodash.has.

Mit dem Object.hasOwn-Vorschlag können wir einfach schreiben:

if (Object.hasOwn(object, 'foo')) {
  // `object` hat die Eigenschaft `foo`.
}

Object.hasOwn ist bereits in V8 v9.3 hinter dem --harmony-object-has-own-Flag verfügbar, und wir werden es bald in Chrome einführen.

Unterstützung für Object.hasOwn​

Die neue Funktion Importbedingungen ermöglicht es, dass Modulimportanweisungen zusätzliche Informationen neben dem Modulspezifizierer enthalten. Eine erste Anwendung dieser Funktion besteht darin, JSON-Dokumente als JSON-Module zu importieren:

Der in-Operator kann verwendet werden, um zu testen, ob das angegebene Objekt (oder ein beliebiges Objekt in seiner Prototypenkette) die angegebene Eigenschaft besitzt:

const o1 = {'foo': 0};
console.log('foo' in o1); // true
const o2 = {};
console.log('foo' in o2); // false
const o3 = Object.create(o1);
console.log('foo' in o3); // true

Das Feature für Private-Markenüberprüfungen erweitert den in-Operator, um private Klassenfelder zu unterstützen:

class A {
  static test(obj) {
    console.log(#foo in obj);
  }
  #foo = 0;
}

A.test(new A()); // true
A.test({}); // false

class B {
  #foo = 0;
}

A.test(new B()); // false; es ist nicht dasselbe #foo

Da private Namen nur innerhalb der Klasse verfügbar sind, die sie definiert, muss der Test auch innerhalb der Klasse erfolgen, beispielsweise in einer Methode wie static test oben.

Unterklasseninstanzen erhalten private Felder von der Elternklasse als Eigen-Eigenschaften:

class SubA extends A {};
A.test(new SubA()); // true

Aber Objekte, die mit Object.create erstellt werden (oder deren Prototyp später über den __proto__-Setter oder Object.setPrototypeOf gesetzt wird), erhalten die privaten Felder nicht als Eigen-Eigenschaften. Da der Zugriff auf private Felder nur auf Eigen-Eigenschaften funktioniert, findet der in-Operator diese geerbten Felder nicht: