Eine kurze Diskussion über 3 bemerkenswerte neue Features in TypeScript 3.7

Vorwort

Es ist eine Weile her, seit TypeScript 3.7 offiziell veröffentlicht wurde. Während dieser Zeit migriere ich mein aktuelles Projekt zu TypeScript, daher werde ich jeder Veröffentlichung besondere Aufmerksamkeit schenken.

Was die in 3.7 enthaltenen neuen Funktionen betrifft, handelt es sich im Vergleich zu den vorherigen Versionen tatsächlich um eine relativ kleine Version, die verschiedenen darin enthaltenen Funktionen werden jedoch erhebliche Verbesserungen der Codequalität selbst mit sich bringen.

Optionale Verkettung

Die erste Funktion ist die Unterstützung für den optionalen Verkettungsoperator, der als optionaler Verkettungsoperator übersetzt werden sollte. Natürlich finde ich diese Übersetzung immer noch etwas seltsam, also verwenden wir vorerst einfach Englisch.

Diese Funktion ist zunächst einmal eine neue Funktion, die in es2019 enthalten ist. Wer sich für die Funktion selbst interessiert, kann hier nachlesen.

Da TypeScript eine Obermenge von JavaScript ist, wird erwartet, dass diese Funktion im Voraus implementiert wird. Die Verwendung ist ungefähr wie folgt:

a?.b();

ist gleichbedeutend mit:

wenn(a) ab();
// oder a && ab()

Wenn es sich um eine mehrschichtige Verschachtelung handelt, z. B. b auch ein Objekt ist und Sie weiterhin c() aufrufen möchten, können Sie dies folgendermaßen tun:

ABC()

Aber auch wenn es so geschrieben ist, ist es nicht sicher, da das b in b() auch ein Nullwert sein kann und bei einem direkten Aufruf eine Ausnahme ausgelöst wird. Zur absoluten Sicherheit können Sie schreiben:

a?.b?.();

Es ist wichtig zu beachten, dass wir hier die Bedeutung von „optional“ richtig verstehen müssen. „Optional“ bedeutet, dass es in der Typdeklaration durch ein ?“ geändert wird, was darauf hinweist, dass ein Typ eine Eigenschaft enthält, die null sein kann. Das bedeutet, dass ?. nicht für Eigenschaften aufgerufen wird, die nicht der Typdeklaration selbst entsprechen, zum Beispiel:

Schnittstelle A {}

Konstante a: A = {};

a?.b?.(); // Eigenschaft ‚b‘ existiert beim Typ ‚A‘ nicht

Sofern die Deklaration der Schnittstelle A nicht wie folgt geändert wird:

Schnittstelle A {
  b?: beliebig
}

Diese Funktion hat im Projekt große praktische Bedeutung. Wir können weniger if-Assertion-Anweisungen oder &&-Operatoren schreiben, erzielen aber den gleichen Effekt.

Nullish-Koaleszenz

Aus dem Chinesischen übersetzt wird er als Operator für doppelte Fragezeichen bezeichnet, was eigentlich recht aussagekräftig ist, da seine Syntax genau ?? lautet.

Die Funktion dieses Operators besteht, vereinfacht ausgedrückt, darin, einen Standardwert für einen Nullwert anzugeben, ähnlich dem folgenden Code:

sei a = b || 'foo'

Wenn b null ist, wird aufgrund der Natur des ||-Operators der Wert von a foo zugewiesen. Wenn wir den ??-Operator zum Umschreiben verwenden, sähe es folgendermaßen aus:

sei a = b ?? 'foo'

Oberflächlich betrachtet scheint es zwischen den beiden keinen Unterschied zu geben, aber tatsächlich liegt hier ein verstecktes Problem vor: Das Konzept des Nullwerts bezieht sich nicht nur auf null und undefiniert, sondern auch auf eine Reihe logisch falscher Werte wie falsch und 0, die als Nullwerte gezählt werden, was offensichtlich problematisch ist, zum Beispiel:

Konstante b = 0
sei a = b || 'foo'
// a ist „foo“

In diesem Beispiel erwarten wir, dass a nur dann ein Standardwert zugewiesen wird, wenn b ein wirklich leerer Wert (null oder undefiniert) ist. a sollte gleich 0 sein, aber das tatsächliche Laufergebnis ist foo, da b = 0, was während der Ausführung des ||-Operators als falsch interpretiert wird. Ich habe einmal in einem echten Projekt eine Verifizierungscodekomponente geschrieben. Leider bin ich in diese Falle getappt und habe viel Zeit damit verbracht, dieses Problem zu debuggen.

Bei Verwendung des ??-Operators besteht dieses Problem jedoch nicht.

Nicht aufgerufene Funktionsprüfungen

Ich glaube, viele Leute sind auf ähnliche Probleme gestoßen. Aufgrund fehlender effektiver Namenskonventionen werden Assertion-Attribute und Assertion-Methoden in tatsächlichen Projekten vermischt, wie zum Beispiel:

Klasse A {
    isFoo(): boolean {
        gibt false zurück;
    }
}

Funktionstest(a: A) {
    wenn (a.isFoo) { 
        ...
    } 
}

Wenn wir hier durch den Aufruf von a.isFoo einen Assertion-Wert erhalten möchten, haben wir offensichtlich einen Fehler gemacht. Wir sollten if (a.isFoo()) anstelle von if (a.isFoo) direkt verwenden, denn obwohl letzteres auf syntaktischer Ebene nicht falsch ist, wird es im logischen Sinne als wahr behauptet. Aber nach der Veröffentlichung von 3.7 wird TypeScript versuchen, uns bei der Suche nach diesem Problem zu helfen.

Trotzdem empfehle ich Ihnen, eine einheitliche Namenskonvention für Assertion-Methoden und Assertion-Attribute zu entwickeln, beispielsweise isXXX für Attribute und assertXXX für Methoden.

andere

Einige weitere Änderungen betreffen die Benutzerfreundlichkeit, wie zum Beispiel:

• Flachere Fehlerberichterstattung: Ein großer Teil der wiederholten Fehlerprotokolle wird so weit wie möglich in ein einziges, genaueres und prägnanteres Fehlerprotokoll komprimiert.
• @ts-nocheck auf Dateiebene: In früheren Versionen unterstützte diese Annotation nur die Inline-Ebene
• Rekursive Typdeklaration: Sie können rekursive Syntax in der Typdeklaration verwenden, um komplexere Typen zu deklarieren, wie z. B. den JSON-Typ
• Bieten Sie Deklarationsunterstützung für JS-Dateien, um die Migrationskosten von JS-Projekten zu senken

Oben finden Sie eine kurze Erläuterung der Details zu drei neuen Funktionen, die in TypeScript 3.7 erwähnenswert sind. Weitere Informationen zu den neuen Funktionen von TypeScript 3.7 finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!