Ich habe vor kurzem schrieb über die neuen Funktionen in eingeführt ES2020... Während einige dieser Möglichkeiten interessant sind, gibt es keine, die es verdienen, als "revolutionär" bezeichnet zu werden. Dies ist verständlich, da die JS-Spezifikation heutzutage häufig aktualisiert wird. Es stellt sich heraus, dass diejenigen, die am Standard arbeiten, einfach weniger Möglichkeiten haben, ständig etwas Besonderes in die Sprache einzuführen, wie ES6-Module oder Pfeilfunktionen. Dies bedeutet jedoch nicht, dass etwas ausschließlich Neues letztendlich nicht in der Sprache erscheint. Genau darüber möchte ich heute sprechen. Ich möchte über 4 Möglichkeiten sprechen, die in Zukunft als revolutionär bezeichnet werden können. Sie befinden sich jetzt in verschiedenen Phasen des Prozesses.
Koordinierung der Vorschläge. Dies bedeutet einerseits, dass wir sie möglicherweise nie in JavaScript sehen, und andererseits gibt uns das Vorhandensein solcher Sätze Hoffnung, dass wir sie dennoch eines Tages in der Sprache treffen werden.
Dekorateure
Wir werden mit der Funktion beginnen, die wahrscheinlich am häufigsten gefragt wird, um in die Sprache aufgenommen zu werden, und um die herum ziemlich viel Aufsehen erregt wurde. Vor ein paar Jahren haben sie buchstäblich überall über sie geschrieben. Wir sprechen über Dekorateure .
Sie sind vielleicht bereits mit Dekorateuren vertraut. Vor allem, wenn Sie in TypeScript schreiben. Es handelt sich im Wesentlichen um ein Metaprogrammierungskonzept, das dem Entwickler die Möglichkeit geben soll, seine eigene Funktionalität in Klassen, in ihre einzelnen Felder und Methoden "einzufügen" und letztendlich die Klassen programmierbar zu machen.
Schauen Sie sich das folgende Beispiel an:
function sealed(constructor: Function) {
Object.seal(constructor);
Object.seal(constructor.prototype);
}
@sealed
class Greeter {
greeting: string;
constructor(message: string) {
this.greeting = message;
}
greet() {
return "Hello, " + this.greeting;
}
}
Hier habe ich mich entschlossen, mit Vorsicht vorzugehen, und ein Beispiel für die Verwendung von TypeScript-Dekoratoren gegeben . Ich habe dies hauptsächlich getan, um die allgemeine Idee zu zeigen. Im obigen Code-Snippet haben wir einen Dekorator erstellt
sealedund auf die Klasse angewendet Greeter. Wie Sie sehen können, ist ein Dekorator einfach eine Funktion, die Zugriff auf den Konstruktor der Klasse hat, auf die er angewendet wird (dies ist das Ziel). Wir verwenden einen Verweis auf einen Konstruktor sowie eine Methode Object.seal(), um die Klasse nicht erweiterbar zu machen.
Um einen Dekorateur auf eine Klasse anzuwenden, schreiben wir den Namen des Dekorateurs mit einem Symbol
@kurz vor der Klassendeklaration. Als Ergebnis stellt sich heraus, dass vor der Klassendeklaration eine Konstruktion des Formulars erscheint @[name], die in unserem Fall so aussieht @sealed.
Sie können die Funktionalität des Dekorateurs überprüfen, indem Sie diesen TS-Code mit aktivierter Option kompilieren
experimentalDecoratorsund versuchen, den Klassenprototyp zu ändern:
Greeter.prototype.test = "test"; // ERROR
Daher sollten Sie jetzt ein allgemeines Verständnis dafür haben, warum Dekorateure überhaupt benötigt werden. Aber ich möchte hier eine schwierige Frage ansprechen. Es geht um den Stand der Genehmigung des Vorschlags für Dekorateure.
Ich habe mich aus gutem Grund für TypeScript entschieden, um Dekorateure zu demonstrieren. Der Punkt ist, dass es vor einigen Jahren einen Vorschlag zur Einbettung von Dekorateuren in JavaScript gegeben hat. Und es ist jetzt "nur" in der 2. Stufe der Vereinbarung von 4. Sowohl die Syntax als auch die Fähigkeiten der Dekorateure aus diesem Vorschlag werden ständig geändert. Dies hindert die JS-Community jedoch nicht daran, dieses Konzept zu verwenden. Um davon überzeugt zu sein, reicht es aus, sich riesige Open-Source-Projekte wie TypeScript oder Angular v2 + anzusehen.
All dies führt im Laufe der Zeit und während sich der Vorschlag entwickelt, zu einem Problem im Zusammenhang mit der Inkompatibilität von Spezifikationen. Die Dekorationsspezifikation hat sich seit dem Vorschlag stark weiterentwickelt, aber viele Projekte haben sie noch nicht umgesetzt. Das oben gezeigte TypeScript-Beispiel ist eine Demonstration der Implementierung einer älteren Version des Vorschlags. Das Gleiche gilt für Angular und sogar für Babel (obwohl wir im Fall von Babel sagen können, dass derzeit daran gearbeitet wird , eine neuere Version dieser Spezifikation zu implementieren). Im Allgemeinen hat die neuere Version des Satzes, die ein Schlüsselwort
decoratorund eine Syntax verwendet, die zum Verknüpfen geeignet sind, noch keine nennenswerte Verwendung gefunden.
Das Fazit ist, dass Dekorateure das Potenzial haben, die Art und Weise, wie wir Code schreiben, zu ändern. Und diese Veränderungen zeigen sich bereits, obwohl sich die Dekorateure noch im Anfangsstadium befinden. Angesichts des aktuellen Zustands zersplittern Dekorateure jedoch nur die Gemeinschaft, und ich glaube, sie sind noch nicht bereit für eine wirklich ernsthafte Verwendung. Ich würde denjenigen, die sich für Dekorateure interessieren, raten, etwas zu warten, bevor sie in die Produktion eingeführt werden. Meine Empfehlung gilt jedoch nicht für diejenigen, die Frameworks verwenden, die Dekoratoren verwenden (wie Angular).
Bereiche
Lassen Sie uns nun etwas langsamer werden und über eine Funktion sprechen, die nicht so komplex ist wie Dekorateure. Wir sprechen über Bereiche .
Möglicherweise waren Sie bereits in Situationen, in denen Sie Ihren eigenen Code oder Code von einem Drittentwickler ausführen müssen, dies jedoch gleichzeitig so, dass dieser Code die globale Umgebung nicht beeinträchtigt. Viele Bibliotheken, insbesondere Browser-Bibliotheken, arbeiten mit dem globalen Objekt
window. Infolgedessen können sie sich gegenseitig stören, falls das Projekt zu viele Bibliotheken verwendet, die außerhalb der Kontrolle des Entwicklers liegen. Dies kann zu Fehlern führen.
Die aktuelle Browserlösung für dieses Problem besteht darin, Elemente zu verwenden
<iframe>und in einigen besonderen Fällen - beim Einsatz von Web-Workern. In der Node.js-Umgebung wird das gleiche Problem mithilfe eines Moduls vmoder untergeordneter Prozesse gelöst . Die Realms-API wurde entwickelt, um solche Probleme zu lösen.
Mit dieser API können Entwickler separate globale Umgebungen erstellen, die als Bereiche bezeichnet werden. Jeder dieser Bereiche hat seine eigenen globalen Einheiten. Schauen Sie sich das folgende Beispiel an:
var x = 39;
const realm = new Realm();
realm.globalThis.x; // undefined
realm.globalThis.x = 42; // 42
realm.globalThis.x; // 42
x; // 39
Hier erstellen wir ein neues Objekt
Realmmit dem entsprechenden Konstruktor. Von nun an haben wir über eine Eigenschaft globalThis(eingeführt in ES2020) vollen Zugriff auf den neuen Bereich und seine globalen Objekte . Hier können Sie sehen, dass die Variablen des Haupt- "Inkubators" von den Variablen in dem von uns erstellten Bereich getrennt sind.
Insgesamt ist die Realms-API als sehr einfacher Mechanismus geplant, aber ein nützlicher Mechanismus. Diese API hat eine sehr spezifische Reihe von Anwendungsfällen. Es gibt uns weder ein höheres Maß an Sicherheit noch die Möglichkeit, Multithread-Code zu verwenden. Ohne die Systemlast unnötig zu belasten, wird die Hauptaufgabe jedoch perfekt bewältigt, indem grundlegende Funktionen zum Erstellen isolierter Umgebungen bereitgestellt werden.
Der Realms-API-Vorschlag befindet sich derzeit in Phase 2 der Verhandlungen. Wenn es schließlich den Standard erreicht, würde man erwarten, dass es in "schweren" Bibliotheken verwendet wird, die sich auf den globalen Geltungsbereich stützen, in Online-Sandbox-Code-Editoren und in verschiedenen Anwendungen, die darauf abzielen testen.
Mach Ausdrücke
Die JavaScript-Syntax enthält wie die Syntax der meisten Programmiersprachen Anweisungen und Ausdrücke. Der auffälligste Unterschied zwischen diesen Konstrukten besteht darin, dass Ausdrücke als Werte verwendet werden können (dh sie können Variablen zugewiesen, an Funktionen übergeben usw. werden), während Anweisungen nicht als solche verwendet werden können.
Aufgrund dieser Unterscheidung sind Ausdrücke die am meisten bevorzugte Wahl für saubereren, kompakteren Code. In JavaScript können Sie dies anhand der Beliebtheit von Funktionsausdrücken erkennen, zu denen Pfeilfunktionen im Vergleich zu Funktionsdeklarationen und Funktionsanweisungen gehören. Die gleiche Situation wird gesehen, wenn wir die Methoden zum Iterieren über Arrays vergleichen (wie
forEach()) mit Zyklen. Gleiches gilt für fortgeschrittenere Programmierer beim Vergleich eines ternären Operators und einer Anweisung if.
Der Do-Expression- Vorschlag , der sich derzeit in Verhandlungsphase 1 befindet, zielt darauf ab, die Fähigkeiten von JS-Ausdrücken weiter zu verbessern. Verwechseln Sie übrigens das Konzept des "do-expression" nicht mit Schleifen
do…while, da es sich um völlig andere Dinge handelt.
Hier ist ein Beispiel:
let x = do {
if (foo()) {
f();
} else if (bar()) {
g();
} else {
h();
}
};
Hier ist die Syntax aus der do-expression-Klausel. Im Allgemeinen haben wir ein Stück JS-Code vor uns, das in eine Konstruktion eingewickelt ist
do {}. Der letzte Ausdruck in diesem Konstrukt wird als Endwert des gesamten do-Ausdrucks "zurückgegeben".
Ein ähnlicher (aber nicht identischer) Effekt ist mit einem IIFE (Sofort aufgerufener Funktionsausdruck) erreichbar. Bei do-Ausdrücken scheint ihre kompakte Syntax jedoch sehr attraktiv zu sein. Hier, mit ähnlicher Funktionalität, brauchen Sie weder
returnoder irgendwelche hässlichen Hilfsstrukturen wie(() => {})()... Aus diesem Grund glaube ich, dass die Auswirkungen von Ausdrücken auf JavaScript, sobald sie in den Standard aufgenommen wurden, mit denen von Pfeilfunktionen vergleichbar sind. Die Bequemlichkeit von Ausdrücken und die freundliche Syntax in einem Paket sehen sozusagen sehr verlockend aus.
Mustervergleich
Diese Gelegenheit ist die letzte in diesem Material, aber sie ist bei weitem nicht die letzte in ihrer Bedeutung. Dies ist ein Vorschlag, der darauf abzielt, einen Mustervergleichsmechanismus in die Sprache einzuführen .
Möglicherweise kennen Sie die JS-Anweisung
switch. Es ist ähnlich if-else, aber seine Optionen sind etwas eingeschränkter, und es ist sicherlich besser geeignet, um die Wahl einer der vielen Alternativen zu organisieren. So sieht es aus:
switch (value) {
case 1:
// ...
break;
case 2:
// ...
break;
case 3:
// ...
break;
default:
// ...
break;
}
Persönlich denke ich, dass eine Anweisung
switchschwächer ist als eine Anweisung if, da sie switchdas, was an sie übergeben wird, nur mit bestimmten Werten vergleichen kann. Diese Einschränkung kann umgangen werden , aber ich kann mir nicht vorstellen, warum. Zusätzlich ist der Befehl switchmit Hilfselementen überladen. Insbesondere sprechen wir über Anweisungen break.
Der Mustervergleichsmechanismus kann als funktionalere, ausdrucksbasierte und möglicherweise vielseitigere Version einer Anweisung angesehen werden
switch. Anstatt nur Werte zu vergleichen, ermöglicht der Mustervergleichsmechanismus dem Entwickler, Werte mit benutzerdefinierten Mustern (Vorlagen) zu vergleichen, die in hohem Maße anpassbar sind. Hier ist ein Codefragment, das ein Beispiel für die vorgeschlagene API zeigt:
const getLength = vector => case (vector) {
when { x, y, z } -> Math.hypot(x, y, z)
when { x, y } -> Math.hypot(x, y)
when [...etc] -> vector.length
}
getLength({x: 1, y: 2, z: 3})
Es wird eine für JavaScript ungewöhnliche Syntax verwendet (obwohl sie auf der Syntax basiert, die in Sprachen wie Rust oder Scala zu finden ist ), die einige Ähnlichkeiten mit der uns bereits bekannten Anweisung aufweist
switch. Hier wird anstelle eines Schlüsselworts ein Wort switchverwendet case, das den Anfang des Blocks markiert, in dem der Wert überprüft wird. Verwenden Sie dann innerhalb des Blocks das Schlüsselwortwhenbeschreiben wir die Vorlagen, mit denen wir Werte validieren möchten. Die Syntax von Vorlagen ähnelt der Syntax des bereits in der Sprache verfügbaren Objektzerstörungsmechanismus. Sie können Werte mit Objekten vergleichen, die ausgewählte Eigenschaften enthalten, Sie können sie mit Eigenschaftswerten für Objekte und mit vielen anderen Entitäten vergleichen. Weitere Informationen zu diesem Mechanismus finden Sie in diesem Dokument.
Nach der Beschreibung der Vorlage befindet sich ein Pfeil ("flacher Pfeil"
->), der auf den Ausdruck zeigt (in der Perspektive - sogar auf einen anderen Wert), der ausgewertet werden sollte, wenn eine Übereinstimmung mit dem Muster gefunden wird.
Ich glaube, dass das Vorhandensein solcher Funktionen in JS es uns ermöglichen wird, sozusagen Code der neuen Generation zu schreiben. Die jetzt vorgeschlagene Syntax erscheint mir jedoch etwas umständlich, da sie viele völlig neue Konstrukte in die Sprache einführt. Und die Tatsache, dass sich dieser Vorschlag noch in der ersten Phase der Einigung befindet, lässt mich denken, dass er noch Verbesserungspotenzial bietet. Diese Funktion sieht sehr vielversprechend aus, aber es ist noch ein langer Weg, bis sie in die offizielle JS-Spezifikation aufgenommen wird.
Ergebnis
Damit ist meine Geschichte über die revolutionären Funktionen von JavaScript abgeschlossen, die wir vielleicht in Zukunft in der Sprache sehen werden. Es gibt andere ähnliche Möglichkeiten, z. B. Vorschläge für eine externe Standardbibliothek und einen Pipeline-Operator . Aber ich habe für dieses Material nur das ausgewählt, was mir am interessantesten erschien. Beachten Sie, dass sich diese Möglichkeiten noch in der Vorschlagsphase befinden. Sie können sich im Laufe der Zeit ändern. Oder es kann vorkommen, dass sie nie in den Standard kommen. Aber wenn Sie auf jeden Fall zu denen gehören möchten, die solche Gelegenheiten vor anderen nutzen, empfehle ich Ihnen, sich Projekte wie Babel genauer anzusehen... Diese Projekte bringen viele JS-Sätze hervor (insbesondere solche, die sich auf die Syntax beziehen). Auf diese Weise kann jeder mit den neuesten Funktionen experimentieren, lange bevor sie in Sprachimplementierungen erscheinen.
Welche Funktionen vermissen Sie am meisten in JavaScript?
