Standardtypen für generische TypeScript-Parameter und neue Option zur strikten Kompilierung

Überblick

TypeScript 2.3 fügt Unterstützung für die Deklaration von Standardtypen für generische Parameter hinzu, sodass Sie Standardtypen für Typparameter in generischen Typen angeben können.

Als Nächstes sehen wir uns an, wie die folgende React-Komponente mithilfe generischer Parameterstandards von js (und jsX) nach TypeScript (und TSX) migriert wird:

Klasse Greeting erweitert react.Component {
  rendern() {
    return <span>Hallo, {this.props.name}!</span>;
  }
}

Erstellen Sie eine Typdefinition für die Komponentenklasse

Beginnen wir mit der Erstellung einer Typdefinition für die Komponentenklasse. Jede klassenbasierte React-Komponente hat zwei Eigenschaften: Props und State. Die Typdefinitionsstruktur sieht ungefähr so ​​aus:

Namespace deklarieren React {
  Klasse Komponente {
    Requisiten: alle;
    Zustand: beliebig;
  }
}

Beachten Sie, dass dies ein stark vereinfachtes Beispiel ist, da wir den Inhalt generischer Typparameter und ihrer Standardwerte demonstrieren.

Jetzt können Sie die oben definierte Komponente durch Vererbung aufrufen:

Klasse Greeting erweitert React.Component {
  rendern() {
    return <span>Hallo, {this.props.name}!</span>
  }
}

Wir können eine Instanz der Komponente wie folgt erstellen:

<Begrüßung name="world" />

Das Rendern der obigen Komponente generiert das folgende HTML:

<span>Hallo Welt!</span>

Schön, weiter so.

Definieren von Props und State mithilfe generischer Typen

Während das obige Beispiel problemlos kompiliert und ausgeführt wird, ist unsere Komponententypdefinition nicht sehr präzise. Da wir die Props und Statustypen auf „any“ gesetzt haben, kann uns der TypeScript-Compiler nicht viel helfen.

Lassen Sie uns spezifischer sein und zwei generische Typen verwenden: Props und State, damit wir die Struktur von Props- und State-Eigenschaften genau beschreiben können.

Namespace deklarieren React {
  Klasse Komponente<Props, Status> {
    Requisiten: Requisiten;
    Staat: Staat;
  }
}

Erstellen Sie als Nächstes einen GreetingProps-Typ, der eine Namenseigenschaft vom Typ „String“ definiert und diese als Typparameter des Props-Typparameters übergibt:

Typ GreetingProps = {Name: Zeichenfolge};

Klasse Greeting erweitert React.Component<GreetingProps, any> {
  rendern() {
    return <span>Hallo, {this.props.name}!</span>;
  }
}

1) GreetingProps ist ein Typparameter vom Typparameter Props

2) Ebenso ist any ein Typparameter des Typparameters State

Mit diesen Typen erhalten unsere Komponenten eine bessere Typprüfung und Auto-Hinting:

Wenn Sie jetzt jedoch die Klasse React.Component verwenden, müssen Sie beide Typen angeben. Im ersten Codebeispiel, das wir geöffnet haben, wird die Typprüfung nicht mehr korrekt durchgeführt:

// Fehler: generischer Typ Component<Props, State>
// Erfordert 2 Typparameter.
Klasse Greeting erweitert React.Component {
  rendern() {
    return <span>Hallo, {this.props.name}!</span>;
  }
}

Wenn wir den Typ nicht wie GreetingProps angeben möchten, können wir den Code korrigieren, indem wir für die Typparameter „Props“ und „State“ den beliebigen Typ angeben:

Klasse Greeting erweitert React.Component<any, any> {
  rendern() {
    return <span>Hallo, {this.props.name}!</span>;
  }
}

Diese Methode lässt der Compiler durch, wir haben jedoch einen eleganteren Ansatz: den Standardtyp generischer Parameter.

Generischer Parameter-Standardtyp

Ab TypeScript 2.3 können wir jedem generischen Typparameter einen Standardtyp hinzufügen. Wenn im folgenden Beispiel keine Typparameter explizit angegeben werden, sind sowohl Props als auch State vom Typ any:

Namespace deklarieren React {
  Klasse Komponente<Props = beliebig, Status = beliebig> {
    Requisiten: Requisiten;
    Staat: Staat;
  }
}

Jetzt können wir die Prüfung des Compilers bestehen, ohne den generischen Typ anzugeben:

Klasse Greeting erweitert React.Component {
  rendern() {
    return <span>Hallo, {this.props.name}!</span>;
  }
}

Natürlich können wir immer noch explizit einen Typ für den Props-Typparameter angeben und den Standardtyp „any“ wie folgt überschreiben:

Typ GreetingProps = {Name: Zeichenfolge};

Klasse Greeting erweitert React.Component<GreetingProps, any> {
  rendern() {
    return <span>Hallo, {this.props.name}!</span>;
  }
}

Beide Typparameter haben jetzt einen Standardtyp, daher sind sie optional und wir können explizite Typparameter nur für Props angeben:

Typ GreetingProps = {Name: Zeichenfolge};

Klasse Greeting erweitert React.Component<GreetingProps> {
  rendern() {
    return <span>Hallo, {this.props.name}!</span>;
  }
}

Beachten Sie, dass wir nur einen Typparameter bereitstellen. Allerdings muss der Typ des optionalen Typparameters vor dem ausgelassenen angegeben werden, sonst kann er nicht weggelassen werden.

Weitere Beispiele

Im vorherigen Artikel über Mixin-Klassen in TypeScript 2.2 haben wir zunächst die folgenden beiden Typaliase deklariert:

Typkonstruktor <T> = neu (...args: any[]) => T;
Typ konstruierbar = Konstruktor<{}>;

Konstruierbare Typen sind rein syntaktischer Zucker. Es kann den Typ Constructor<{}> ersetzen, sodass Sie die generischen Typparameter nicht jedes Mal schreiben müssen. Durch die Verwendung von Standardwerten für generische Parameter können Sie den zusätzlichen konstruierbaren Typ vollständig entfernen und {} als Standardtyp festlegen.

Typ Konstruktor <T = {}> = neu (...args: any[]) => T;

Die Syntax ist etwas komplizierter, aber der generierte Code ist prägnanter. Gut.

Neue Hauptkompilierungsoption --strict

TypeScript 2.3 führt eine neue Compileroption --strict ein, die eine Reihe weiterer Compileroptionen im Zusammenhang mit einer strengeren Typprüfung aktiviert.

Neue, von TypeScript hinzugefügte Prüfungen sind normalerweise standardmäßig deaktiviert, um Inkompatibilitäten mit vorhandenen Projekten zu vermeiden. Das Vermeiden von Inkompatibilitäten ist zwar eine gute Sache, ein Nachteil dieser Strategie besteht jedoch darin, dass die Konfiguration für maximale Typsicherheit zunehmend komplexer wird, da mit jeder TypeScript-Version explizit neue Optionen hinzugefügt werden müssen. Mit der Kompilierungsoption --strict können Sie die höchste Stufe der Typsicherheit auswählen (wobei Sie beachten müssen, dass neue Fehler gemeldet werden können, da neuere Versionen des Compilers erweiterte Funktionen zur Typprüfung hinzufügen).

Die neue Compileroption --strict enthält einige vorgeschlagene Konfigurationsoptionen zur Typprüfung. Insbesondere ist die Angabe von --strict gleichbedeutend mit der Angabe aller folgenden Optionen (und möglicherweise in Zukunft noch mehr):

• --strictNullChecks
• --noImplicitAny
• --noImplicitThis
• --alwaysStrict

Zukünftige Versionen von TypeScript werden diesem Set möglicherweise weitere Optionen zur Typprüfung hinzufügen. Das bedeutet, dass wir nicht jede TypeScript-Version überwachen müssen, um neue Strengheitsoptionen zu erhalten, die in unserem Projekt aktiviert werden sollten. Wenn den oben genannten Optionssätzen neue Optionen hinzugefügt werden, werden diese nach dem Upgrade der TypeScript-Version Ihres Projekts automatisch aktiviert.

Die Compileroption --strict legt Standardwerte für die oben aufgeführten Compileroptionen fest. Somit sind diese Optionen auch einzeln steuerbar. Zum Beispiel:

--strict --noImplicitThis false

Oder geben Sie es in der Datei tsconfig.json an:

{
  "streng": wahr,
  "alwaysStrict": falsch
}

Dadurch werden alle strengen Prüfoptionen außer der Compileroption --noImplicitThis aktiviert. Mit diesem Ansatz können Sie strenge Prüfungen für alle Elemente mit Ausnahme einiger explizit aufgeführter Elemente durchführen. Mit anderen Worten ist es jetzt möglich, einige Prüfungen auf der höchsten Ebene der Typsicherheit standardmäßig auszuschließen.

Verbesserte --init-Ausgabe

Zusätzlich zur Standardeinstellung --strict bietet tsc --init eine verbesserte Ausgabe. Die standardmäßig von tsc --init generierte Datei tsconfig.json enthält derzeit einige häufig verwendete Compileroptionen, die mit Beschreibungen auskommentiert sind. Sie können die relevanten Optionen auskommentieren, um die erwarteten Ergebnisse zu erhalten. Wir hoffen, dass die neue Ausgabe die Konfiguration neuer Projekte vereinfacht und die Konfigurationsdateien lesbarer hält, während Ihr Projekt wächst.

Der Compiler tsc --init kann eine Konfigurationsdatei für den Build erstellen:

$ tsc --init

Nachricht TS6071: Eine tsconfig.json-Datei wurde erfolgreich erstellt.

Nach dem Ausführen dieses Befehls wird im aktuellen Arbeitsverzeichnis eine tsconfig.json-Datei generiert. Die generierte Konfiguration sieht wie folgt aus:

{
  "Compileroptionen": {
    /* Grundlegende Optionen */
    "target": "es5", /* Geben Sie die ECMAScript-Zielversion an: „ES3“ (Standard), „ES5“, „ES2015“, „ES2016“, „ES2017“ oder „ESNEXT“. */
    "module": "commonjs", /* Geben Sie die Modulcodegenerierung an: „commonjs“, „amd“, „system“, „umd“ oder „es2015“. */
    // "lib": [], /* Geben Sie die Bibliotheksdateien an, die in die Kompilierung einbezogen werden sollen: */
    // "allowJs": true, /* Erlaubt das Kompilieren von JavaScript-Dateien. */
    // "checkJs": true, /* Fehler in .js-Dateien melden. */
    // "jsx": "preserve", /* Geben Sie die JSX-Codegenerierung an: „preserve“, „react-native“ oder „react“. */
    // "declaration": true, /* Generiert die entsprechende '.d.ts'-Datei. */
    // "sourceMap": true, /* Generiert die entsprechende '.map'-Datei. */
    // "outFile": "./", /* Verketten und Ausgabe in eine einzelne Datei ausgeben. */
    // "outDir": "./", /* Ausgabestruktur in das Verzeichnis umleiten. */
    // "rootDir": "./", /* Geben Sie das Stammverzeichnis der Eingabedateien an. Verwenden Sie --outDir, um die Ausgabeverzeichnisstruktur zu steuern. */
    // "removeComments": true, /* Keine Kommentare in die Ausgabe ausgeben. */
    // "noEmit": true, /* Keine Ausgaben ausgeben. */
    // "importHelpers": true, /* Importiere Emit-Helfer aus „tslib“. */
    // "downlevelIteration": true, /* Vollständige Unterstützung für Iterables in „for-of“, Spread und Destrukturierung bei Ausrichtung auf „ES5“ oder „ES3“. */
    // "isolatedModules": true, /* Jede Datei als separates Modul transpilieren (ähnlich wie „ts.transpileModule“). */

    /* Optionen zur strengen Typprüfung */
    "strict": true /* Aktiviere alle Optionen zur strengen Typprüfung. */
    // "noImplicitAny": true, /* Bei Ausdrücken und Deklarationen mit implizitem „any“-Typ einen Fehler auslösen. */
    // "strictNullChecks": true, /* Aktiviere strenge Nullprüfungen. */
    // "noImplicitThis": true, /* Bei 'this'-Ausdrücken mit implizitem 'any'-Typ einen Fehler auslösen. */
    // „alwaysStrict“: true, /* Im strikten Modus analysieren und „use strict“ für jede Quelldatei ausgeben. */

    /* Zusätzliche Prüfungen */
    // "noUnusedLocals": true, /* Fehler bei nicht verwendeten lokalen Variablen melden. */
    // "noUnusedParameters": true, /* Fehler bei nicht verwendeten Parametern melden. */
    // "noImplicitReturns": true, /* Fehler melden, wenn nicht alle Codepfade in der Funktion einen Wert zurückgeben. */
    // "noFallthroughCasesInSwitch": true, /* Fehler für Fallthrough-Fälle in der Switch-Anweisung melden. */

    /* Modulauflösungsoptionen */
    // "moduleResolution": "node", /* Modulauflösungsstrategie angeben: „node“ (Node.js) oder „classic“ (TypeScript vor 1.6). */
    // "baseUrl": "./", /* Basisverzeichnis zum Auflösen nicht absoluter Modulnamen. */
    // "Pfade": {}, /* Eine Reihe von Einträgen, die Importe den Nachschlageorten relativ zur „Basis-URL“ neu zuordnen. */
    // "rootDirs": [], /* Liste von Stammordnern, deren kombinierter Inhalt die Struktur des Projekts zur Laufzeit darstellt. */
    // "typeRoots": [], /* Liste der Ordner, aus denen Typdefinitionen einbezogen werden sollen. */
    // "types": [], /* Typdeklarationsdateien, die in die Kompilierung einbezogen werden sollen. */
    // "allowSyntheticDefaultImports": true, /* Erlaube Standardimporte aus Modulen ohne Standardexport. Dies hat keine Auswirkungen auf die Codeausgabe, sondern nur auf die Typprüfung. */

    /* Quellzuordnungsoptionen */
    // "sourceRoot": "./", /* Geben Sie den Speicherort an, an dem der Debugger TypeScript-Dateien statt Quellspeicherorte suchen soll. */
    // "mapRoot": "./", /* Geben Sie den Speicherort an, an dem der Debugger die Map-Dateien statt der generierten Speicherorte suchen soll. */
    // "inlineSourceMap": true, /* Gibt eine einzelne Datei mit Quellzuordnungen aus, anstatt eine separate Datei zu haben. */
    // "inlineSources": true, /* Gibt die Quelle zusammen mit den Sourcemaps in einer einzigen Datei aus; erfordert die Festlegung von '--inlineSourceMap' oder '--sourceMap'. */

    /* Experimentelle Optionen */
    // "experimentalDecorators": true, /* Aktiviert experimentelle Unterstützung für ES7-Dekoratoren. */
    // "emitDecoratorMetadata": true, /* Aktiviert experimentelle Unterstützung für die Ausgabe von Typmetadaten für Dekoratoren. */
  }
}

Beachten Sie, dass --strict standardmäßig aktiviert ist. Dies bedeutet, dass Sie beim Starten eines neuen TypeScript-Projekts automatisch in den Standardmodus versetzt werden.

Fehler in .js-Dateien mit der Option --checkJS

Selbst mit --allowJs meldet der TypeScript-Compiler standardmäßig keine Fehler in .js-Dateien. In TypeScript 2.3 können Typprüfungsfehler in .js-Dateien auch mit der Option --checkJs gemeldet werden.

Sie können die Überprüfung bestimmter Dateien überspringen, indem Sie ihnen den Kommentar // @ts-nocheck hinzufügen. Umgekehrt können Sie durch Hinzufügen des Kommentars // @ts-check festlegen, dass nur einige .js-Dateien überprüft werden, ohne die Kompilieroption --checkJs festzulegen. Sie können Fehler in einer bestimmten Zeile auch ignorieren, indem Sie vor der Zeile // @ts-ignore hinzufügen.

.js-Dateien werden weiterhin überprüft, um sicherzustellen, dass nur Standard-ECMAScript-Funktionen vorhanden sind. Typanmerkungen sind nur in .ts-Dateien zulässig und werden in .js-Dateien als Fehler gekennzeichnet. JSDoc-Kommentare können verwendet werden, um Ihrem JS-Code einige Typinformationen hinzuzufügen.

Oben sind die Details der Standardtypen für generische Parameter von TypeScript und der neuen strikten Kompilierungsoption aufgeführt. Weitere Informationen zu TypeScript finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!