13 Alternativen zu Enums in TypeScript

Das vorherige Kapitel untersuchte, wie TypeScript-Enums funktionieren. In diesem Kapitel betrachten wir Alternativen zu Enums.

13.1 Vereinigungen von Singleton-Werten

Ein Enum ordnet Mitgliedsnamen Mitgliedswerten zu. Wenn wir die Indirektion nicht benötigen oder wollen, können wir eine Vereinigung von sogenannten primitiven Literal-Typen verwenden – einen pro Wert. Bevor wir ins Detail gehen, müssen wir etwas über primitive Literal-Typen lernen.

13.1.1 Primitive Literal-Typen

Kurze Wiederholung: Wir können Typen als Mengen von Werten betrachten.

Ein Singleton-Typ ist ein Typ mit einem Element. Primitive Literal-Typen sind Singleton-Typen

type UndefinedLiteralType = undefined;
type NullLiteralType = null;

type BooleanLiteralType = true;
type NumericLiteralType = 123;
type BigIntLiteralType = 123n; // --target must be ES2020+
type StringLiteralType = 'abc';

UndefinedLiteralType ist der Typ mit dem einzelnen Element undefined, usw.

Es ist wichtig, sich der beiden Sprachebenen bewusst zu sein, die hier im Spiel sind (wir sind diesen Ebenen bereits früher in diesem Buch begegnet). Betrachten wir die folgende Variablendeklaration

const abc: 'abc' = 'abc';

• Das erste 'abc' repräsentiert einen Typ (einen String-Literal-Typ).
• Das zweite 'abc' repräsentiert einen Wert.

Zwei Anwendungsfälle für primitive Literal-Typen sind

• Überladung basierend auf String-Parametern, was es dem ersten Argument des folgenden Methodenaufrufs ermöglicht, den Typ des zweiten Arguments zu bestimmen

  elem.addEventListener('click', myEventHandler);

• Wir können eine Vereinigung von primitiven Literal-Typen verwenden, um einen Typ zu definieren, indem wir seine Mitglieder aufzählen

  type IceCreamFlavor = 'vanilla' | 'chocolate' | 'strawberry';

Lesen Sie weiter für weitere Informationen über den zweiten Anwendungsfall.

13.1.2 Vereinigungen von String-Literal-Typen

Wir beginnen mit einem Enum und wandeln es in eine Vereinigung von String-Literal-Typen um.

enum NoYesEnum {
  No = 'No',
  Yes = 'Yes',
}
function toGerman1(value: NoYesEnum): string {
  switch (value) {
    case NoYesEnum.No:
      return 'Nein';
    case NoYesEnum.Yes:
      return 'Ja';
  }
}
assert.equal(toGerman1(NoYesEnum.No), 'Nein');
assert.equal(toGerman1(NoYesEnum.Yes), 'Ja');

NoYesStrings ist die Union-Typ-Version von NoYesEnum

type NoYesStrings = 'No' | 'Yes';

function toGerman2(value: NoYesStrings): string {
  switch (value) {
    case 'No':
      return 'Nein';
    case 'Yes':
      return 'Ja';
  }
}
assert.equal(toGerman2('No'), 'Nein');
assert.equal(toGerman2('Yes'), 'Ja');

Der Typ NoYesStrings ist die Vereinigung der String-Literal-Typen 'No' und 'Yes'. Der Union-Typ-Operator | ist mit dem mengentheoretischen Vereinigungsoperator ∪ verwandt.

13.1.2.1 Vereinigungen von String-Literal-Typen können auf Vollständigkeit geprüft werden

Der folgende Code zeigt, dass Vollständigkeitsprüfungen für Vereinigungen von String-Literal-Typen funktionieren

// @ts-expect-error: Function lacks ending return statement and
// return type does not include 'undefined'. (2366)
function toGerman3(value: NoYesStrings): string {
  switch (value) {
    case 'Yes':
      return 'Ja';
  }
}

Wir haben den Fall für 'No' vergessen, und TypeScript warnt uns, dass die Funktion Werte zurückgeben kann, die keine Strings sind.

Wir hätten die Vollständigkeit auch expliziter prüfen können

class UnsupportedValueError extends Error {
  constructor(value: never) {
    super('Unsupported value: ' + value);
  }
}

function toGerman4(value: NoYesStrings): string {
  switch (value) {
    case 'Yes':
      return 'Ja';
    default:
      // @ts-expect-error: Argument of type '"No"' is not
      // assignable to parameter of type 'never'. (2345)
      throw new UnsupportedValueError(value);
  }
}

Nun warnt uns TypeScript, dass wir den default-Fall erreichen, wenn value 'No' ist.

13.1.2.2 Nachteil: Vereinigungen von String-Literalen sind weniger typsicher

Ein Nachteil von String-Literal-Vereinigungen ist, dass Nicht-Mitgliedswerte fälschlicherweise für Mitglieder gehalten werden können

type Spanish = 'no' | 'sí';
type English = 'no' | 'yes';

const spanishWord: Spanish = 'no';
const englishWord: English = spanishWord;

Das ist logisch, da das spanische 'no' und das englische 'no' derselbe Wert sind. Das eigentliche Problem ist, dass es keine Möglichkeit gibt, ihnen unterschiedliche Identitäten zu geben.

13.1.3 Vereinigungen von Symbol-Singleton-Typen

13.1.3.1 Beispiel: LogLevel

Anstelle von Vereinigungen von String-Literal-Typen können wir auch Vereinigungen von Symbol-Singleton-Typen verwenden. Beginnen wir diesmal mit einem anderen Enum

enum LogLevel {
  off = 'off',
  info = 'info',
  warn = 'warn',
  error = 'error',
}

In eine Vereinigung von Symbol-Singleton-Typen übersetzt sieht es wie folgt aus

const off = Symbol('off');
const info = Symbol('info');
const warn = Symbol('warn');
const error = Symbol('error');

// %inferred-type: unique symbol | unique symbol |
// unique symbol | unique symbol
type LogLevel =
  | typeof off
  | typeof info
  | typeof warn
  | typeof error
;

Warum brauchen wir hier typeof? off usw. sind Werte und können nicht in Typgleichungen vorkommen. Der Typoperator typeof behebt dieses Problem, indem er Werte in Typen umwandelt.

Betrachten wir zwei Variationen des vorherigen Beispiels.

13.1.3.2 Variation #1: Inline-Symbole

Können wir die Symbole inline definieren (anstatt auf separate const-Deklarationen zu verweisen)? Leider muss der Operand des Typoperators typeof ein Bezeichner oder ein "Pfad" von Bezeichnern sein, die durch Punkte getrennt sind. Daher ist diese Syntax illegal

type LogLevel = typeof Symbol('off') | ···

13.1.3.3 Variation #2: let statt const

Können wir let anstelle von const verwenden, um die Variablen zu deklarieren? (Das ist nicht unbedingt eine Verbesserung, aber dennoch eine interessante Frage.)

Das können wir nicht, da wir die engeren Typen benötigen, die TypeScript für const-deklarierte Variablen ableitet

// %inferred-type: unique symbol
const constSymbol = Symbol('constSymbol');

// %inferred-type: symbol
let letSymbol1 = Symbol('letSymbol1');

Mit let wäre LogLevel einfach ein Alias für symbol gewesen.

const-Assertions lösen normalerweise diese Art von Problem. Aber sie funktionieren in diesem Fall nicht

// @ts-expect-error: A 'const' assertions can only be applied to references to enum
// members, or string, number, boolean, array, or object literals. (1355)
let letSymbol2 = Symbol('letSymbol2') as const;

13.1.3.4 Verwendung von LogLevel in einer Funktion

Die folgende Funktion wandelt Mitglieder von LogLevel in Strings um

function getName(logLevel: LogLevel): string {
  switch (logLevel) {
    case off:
      return 'off';
    case info:
      return 'info';
    case warn:
      return 'warn';
    case error:
      return 'error';
  }
}

assert.equal(
  getName(warn), 'warn');

13.1.3.5 Vereinigungen von Symbol-Singleton-Typen vs. Vereinigungen von String-Literal-Typen

Wie schneiden sich die beiden Ansätze?

• Vollständigkeitsprüfungen funktionieren für beide.
• Die Verwendung von Symbolen ist umständlicher.
• Jedes Symbol-"Literal" erzeugt ein eindeutiges Symbol, das nicht mit einem anderen Symbol verwechselt werden kann. Das gilt nicht für String-Literale. Lesen Sie weiter für Details.

Erinnern Sie sich an dieses Beispiel, bei dem das spanische 'no' mit dem englischen 'no' verwechselt wurde

type Spanish = 'no' | 'sí';
type English = 'no' | 'yes';

const spanishWord: Spanish = 'no';
const englishWord: English = spanishWord;

Wenn wir Symbole verwenden, haben wir dieses Problem nicht

const spanishNo = Symbol('no');
const spanishSí = Symbol('sí');
type Spanish = typeof spanishNo | typeof spanishSí;

const englishNo = Symbol('no');
const englishYes = Symbol('yes');
type English = typeof englishNo | typeof englishYes;

const spanishWord: Spanish = spanishNo;
// @ts-expect-error: Type 'unique symbol' is not assignable to type 'English'. (2322)
const englishWord: English = spanishNo;

13.1.4 Schlussfolgerung dieses Abschnitts: Union-Typen vs. Enums

Union-Typen und Enums haben einige Gemeinsamkeiten

• Wir können Mitgliedswerte automatisch vervollständigen. Allerdings tun wir dies auf unterschiedliche Weise
  • Bei Enums erhalten wir Auto-Vervollständigung nach dem Enum-Namen und einem Punkt.
  • Bei Union-Typen müssen wir die Auto-Vervollständigung explizit auslösen.
• Vollständigkeitsprüfungen funktionieren auch für beide.

Aber sie unterscheiden sich auch. Nachteile von Vereinigungen von Symbol-Singleton-Typen sind

• Sie sind etwas umständlich.
• Es gibt keinen Namensraum für ihre Mitglieder.
• Es ist etwas schwieriger, sie auf andere Konstrukte zu migrieren (sollte dies notwendig sein): Es ist einfacher zu finden, wo Enum-Mitgliedswerte erwähnt werden.

Vorteile von Vereinigungen von Symbol-Singleton-Typen sind

• Sie sind kein benutzerdefiniertes TypeScript-Sprachkonstrukt und daher näher am reinen JavaScript.
• String-Enums sind nur zur Kompilierzeit typsicher. Vereinigungen von Symbol-Singleton-Typen sind zusätzlich zur Laufzeit typsicher.
  • Das ist besonders wichtig, wenn unser kompilierter TypeScript-Code mit reinem JavaScript-Code interagiert.

13.2 Diskriminierte Vereinigungen

Diskriminierte Vereinigungen sind mit algebraischen Datentypen in funktionalen Programmiersprachen verwandt.

Um zu verstehen, wie sie funktionieren, betrachten wir die Datenstruktur Syntaxbaum, die Ausdrücke wie diese repräsentiert

1 + 2 + 3

Ein Syntaxbaum ist entweder

• Eine Zahl
• Die Addition zweier Syntaxbäume

Nächste Schritte

1. Wir beginnen mit der Erstellung einer objektorientierten Klassenhierarchie für Syntaxbäume.
2. Dann wandeln wir sie in etwas Funktionaleres um.
3. Und schließlich landen wir bei einer diskriminierten Vereinigung.

13.2.1 Schritt 1: Der Syntaxbaum als Klassenhierarchie

Dies ist eine typische objektorientierte Implementierung eines Syntaxbaums

// Abstract = can’t be instantiated via `new`
abstract class SyntaxTree1 {}
class NumberValue1 extends SyntaxTree1 {
  constructor(public numberValue: number) {
    super();
  }
}
class Addition1 extends SyntaxTree1 {
  constructor(public operand1: SyntaxTree1, public operand2: SyntaxTree1) {
    super();
  }
}

SyntaxTree1 ist die Oberklasse von NumberValue1 und Addition1. Das Schlüsselwort public ist eine syntaktische Zucker für

• Deklarieren der Instanz-Eigenschaft .numberValue
• Initialisieren dieser Eigenschaft über den Parameter numberValue

Dies ist ein Beispiel für die Verwendung von SyntaxTree1

const tree = new Addition1(
  new NumberValue1(1),
  new Addition1(
    new NumberValue1(2),
    new NumberValue1(3), // trailing comma
  ), // trailing comma
);

Hinweis: Nachgestellte Kommas in Argumentlisten sind in JavaScript seit ECMAScript 2016 erlaubt.

13.2.2 Schritt 2: Der Syntaxbaum als Union-Typ von Klassen

Wenn wir den Syntaxbaum über einen Union-Typ definieren (Zeile A), benötigen wir keine objektorientierte Vererbung

class NumberValue2 {
  constructor(public numberValue: number) {}
}
class Addition2 {
  constructor(public operand1: SyntaxTree2, public operand2: SyntaxTree2) {}
}
type SyntaxTree2 = NumberValue2 | Addition2; // (A)

Da NumberValue2 und Addition2 keine Oberklasse haben, müssen sie super() in ihren Konstruktoren nicht aufrufen.

Interessanterweise erstellen wir Bäume auf die gleiche Weise wie zuvor

const tree = new Addition2(
  new NumberValue2(1),
  new Addition2(
    new NumberValue2(2),
    new NumberValue2(3),
  ),
);

13.2.3 Schritt 3: Der Syntaxbaum als diskriminierte Vereinigung

Schließlich kommen wir zu diskriminierten Vereinigungen. Dies sind die Typdefinitionen für SyntaxTree3

interface NumberValue3 {
  kind: 'number-value';
  numberValue: number;
}
interface Addition3 {
  kind: 'addition';
  operand1: SyntaxTree3;
  operand2: SyntaxTree3;
}
type SyntaxTree3 = NumberValue3 | Addition3;

Wir sind von Klassen zu Interfaces und damit von Instanzen von Klassen zu einfachen Objekten gewechselt.

Die Interfaces einer diskriminierten Vereinigung müssen mindestens eine gemeinsame Eigenschaft haben, und diese Eigenschaft muss für jede einzelne einen anderen Wert haben. Diese Eigenschaft wird als Diskriminante oder Tag bezeichnet. Die Diskriminante von SyntaxTree3 ist .kind. Ihre Typen sind String-Literal-Typen.

Vergleichen Sie

• Die direkte Klasse einer Instanz wird durch ihren Prototyp bestimmt.
• Der Typ eines Mitglieds einer diskriminierten Vereinigung wird durch seine Diskriminante bestimmt.

Dies ist ein Objekt, das SyntaxTree3 entspricht

const tree: SyntaxTree3 = { // (A)
  kind: 'addition',
  operand1: {
    kind: 'number-value',
    numberValue: 1,
  },
  operand2: {
    kind: 'addition',
    operand1: {
      kind: 'number-value',
      numberValue: 2,
    },
    operand2: {
      kind: 'number-value',
      numberValue: 3,
    },
  }
};

Wir brauchen die Typannotation in Zeile A nicht, aber sie hilft sicherzustellen, dass die Daten die korrekte Struktur haben. Wenn wir dies hier nicht tun, werden wir später auf Probleme stoßen.

Im nächsten Beispiel ist der Typ von tree eine diskriminierte Vereinigung. Jedes Mal, wenn wir seine Diskriminante überprüfen (Zeile C), aktualisiert TypeScript seinen statischen Typ entsprechend

function getNumberValue(tree: SyntaxTree3) {
  // %inferred-type: SyntaxTree3
  tree; // (A)

  // @ts-expect-error: Property 'numberValue' does not exist on type 'SyntaxTree3'.
  // Property 'numberValue' does not exist on type 'Addition3'.(2339)
  tree.numberValue; // (B)

  if (tree.kind === 'number-value') { // (C)
    // %inferred-type: NumberValue3
    tree; // (D)
    return tree.numberValue; // OK!
  }
  return null;
}

In Zeile A haben wir die Diskriminante .kind noch nicht überprüft. Daher ist der aktuelle Typ von tree immer noch SyntaxTree3, und wir können die Eigenschaft .numberValue in Zeile B nicht zugreifen (da nur einer der Typen der Vereinigung diese Eigenschaft hat).

In Zeile D weiß TypeScript, dass .kind 'number-value' ist, und kann daher den Typ NumberValue3 für tree ableiten. Deshalb ist der Zugriff auf .numberValue in der nächsten Zeile diesmal in Ordnung.

13.2.3.1 Implementieren von Funktionen für diskriminierte Vereinigungen

Wir schließen diesen Schritt mit einem Beispiel ab, wie Funktionen für diskriminierte Vereinigungen implementiert werden.

Wenn es eine Operation gibt, die auf Mitglieder aller Untertypen angewendet werden kann, unterscheiden sich die Ansätze für Klassen und diskriminierte Vereinigungen

• Objektorientierter Ansatz: Bei Klassen ist es üblich, eine polymorphe Methode zu verwenden, bei der jede Klasse eine andere Implementierung hat.
• Funktionaler Ansatz: Bei diskriminierten Vereinigungen ist es üblich, eine einzelne Funktion zu verwenden, die alle möglichen Fälle behandelt und durch Untersuchung der Diskriminante ihres Parameters entscheidet, was zu tun ist.

Das folgende Beispiel demonstriert den funktionalen Ansatz. Die Diskriminante wird in Zeile A untersucht und bestimmt, welcher der beiden switch-Fälle ausgeführt wird.

function syntaxTreeToString(tree: SyntaxTree3): string {
  switch (tree.kind) { // (A)
    case 'addition':
      return syntaxTreeToString(tree.operand1)
        + ' + ' + syntaxTreeToString(tree.operand2);
    case 'number-value':
      return String(tree.numberValue);
  }
}

assert.equal(syntaxTreeToString(tree), '1 + 2 + 3');

Beachten Sie, dass TypeScript Vollständigkeitsprüfungen für diskriminierte Vereinigungen durchführt: Wenn wir einen Fall vergessen, wird uns TypeScript warnen.

Dies ist die objektorientierte Version des vorherigen Codes

abstract class SyntaxTree1 {
  // Abstract = enforce that all subclasses implement this method:
  abstract toString(): string;
}
class NumberValue1 extends SyntaxTree1 {
  constructor(public numberValue: number) {
    super();
  }
  toString(): string {
    return String(this.numberValue);
  }
}
class Addition1 extends SyntaxTree1 {
  constructor(public operand1: SyntaxTree1, public operand2: SyntaxTree1) {
    super();
  }
  toString(): string {
    return this.operand1.toString() + ' + ' + this.operand2.toString();
  }
}

const tree = new Addition1(
  new NumberValue1(1),
  new Addition1(
    new NumberValue1(2),
    new NumberValue1(3),
  ),
);

assert.equal(tree.toString(), '1 + 2 + 3');

13.2.3.2 Erweiterbarkeit: objektorientierter Ansatz vs. funktionaler Ansatz

Jeder Ansatz bewältigt eine Art von Erweiterbarkeit gut

• Mit dem objektorientierten Ansatz müssen wir jede Klasse ändern, wenn wir eine neue Operation hinzufügen wollen. Das Hinzufügen eines neuen Typs erfordert jedoch keine Änderungen am bestehenden Code.

• Mit dem funktionalen Ansatz müssen wir jede Funktion ändern, wenn wir einen neuen Typ hinzufügen wollen. Das Hinzufügen neuer Operationen ist dagegen einfach.

13.2.4 Diskriminierte Vereinigungen vs. normale Union-Typen

Diskriminierte Vereinigungen und normale Union-Typen haben zwei Gemeinsamkeiten

• Es gibt keinen Namensraum für Mitgliedswerte.
• TypeScript führt Vollständigkeitsprüfungen durch.

Die nächsten beiden Unterabschnitte untersuchen zwei Vorteile von diskriminierten Vereinigungen gegenüber normalen Vereinigungen

13.2.4.1 Vorteil: beschreibende Eigenschaftsnamen

Bei diskriminierten Vereinigungen erhalten Werte beschreibende Eigenschaftsnamen. Vergleichen wir

Normale Vereinigung

type FileGenerator = (webPath: string) => string;
type FileSource1 = string|FileGenerator;

Diskriminierte Vereinigung

interface FileSourceFile {
  type: 'FileSourceFile',
  nativePath: string,
}
interface FileSourceGenerator {
  type: 'FileSourceGenerator',
  fileGenerator: FileGenerator,
}
type FileSource2 = FileSourceFile | FileSourceGenerator;

Nun wissen die Leser des Quellcodes sofort, was der String ist: ein nativer Pfadname.

13.2.4.2 Vorteil: Wir können es auch verwenden, wenn die Teile nicht unterscheidbar sind

Die folgende diskriminierte Vereinigung kann nicht als normale Vereinigung implementiert werden, da wir die Typen der Vereinigung in TypeScript nicht unterscheiden können.

interface TemperatureCelsius {
  type: 'TemperatureCelsius',
  value: number,
}
interface TemperatureFahrenheit {
  type: 'TemperatureFahrenheit',
  value: number,
}
type Temperature = TemperatureCelsius | TemperatureFahrenheit;

13.3 Objekt-Literale als Enums

Das folgende Muster zur Implementierung von Enums ist in JavaScript verbreitet

const Color = {
  red: Symbol('red'),
  green: Symbol('green'),
  blue: Symbol('blue'),
};

Wir können versuchen, es in TypeScript wie folgt zu verwenden

// %inferred-type: symbol
Color.red; // (A)

// %inferred-type: symbol
type TColor2 = // (B)
  | typeof Color.red
  | typeof Color.green
  | typeof Color.blue
;

function toGerman(color: TColor): string {
  switch (color) {
    case Color.red:
      return 'rot';
    case Color.green:
      return 'grün';
    case Color.blue:
      return 'blau';
    default:
      // No exhaustiveness check (inferred type is not `never`):
      // %inferred-type: symbol
      color;

      // Prevent static error for return type:
      throw new Error();
  }
}

Leider hat jede Eigenschaft von Color den Typ symbol (Zeile A) und TColor (Zeile B) ist ein Alias für symbol. Infolgedessen können wir toGerman() jeden beliebigen Symbol übergeben, und TypeScript wird zur Kompilierzeit keine Beschwerde erheben

assert.equal(
  toGerman(Color.green), 'grün');
assert.throws(
  () => toGerman(Symbol())); // no static error!

Eine const-Assertion hilft oft in dieser Art von Situation, aber nicht dieses Mal

const ConstColor = {
  red: Symbol('red'),
  green: Symbol('green'),
  blue: Symbol('blue'),
} as const;

// %inferred-type: symbol
ConstColor.red;

Der einzige Weg, dies zu beheben, sind Konstanten

const red = Symbol('red');
const green = Symbol('green');
const blue = Symbol('blue');

// %inferred-type: unique symbol
red;

// %inferred-type: unique symbol | unique symbol | unique symbol
type TColor2 = typeof red | typeof green | typeof blue;

13.3.1 Objekt-Literale mit String-Werten

const Color = {
  red: 'red',
  green: 'green',
  blue: 'blue',
} as const; // (A)

// %inferred-type: "red"
Color.red;

// %inferred-type: "red" | "green" | "blue"
type TColor =
  | typeof Color.red
  | typeof Color.green
  | typeof Color.blue
;

Wir benötigen as const in Zeile A, damit die Eigenschaften von Color nicht den allgemeineren Typ string haben. Dann hat TColor auch einen Typ, der spezifischer als string ist.

Im Vergleich zur Verwendung eines Objekts mit Symbol-Werten als Enum sind String-Werte

• Besser zur Entwicklungszeit, da wir Vollständigkeitsprüfungen erhalten und einen engeren Typ für die Werte ableiten können (ohne externe Konstanten zu verwenden).
• Schlechter zur Laufzeit, da Strings fälschlicherweise für Enum-Werte gehalten werden können.

13.3.2 Vorteile und Nachteile der Verwendung von Objekt-Literalen als Enums

Vorteile

• Wir haben einen Namensraum für die Werte.
• Wir verwenden kein benutzerdefiniertes Konstrukt und sind näher am reinen JavaScript.
• Wir können einen engeren Typ für Enum-Werte ableiten (wenn wir String-Werte verwenden).
• Vollständigkeitsprüfungen werden für einen solchen Typ durchgeführt.

Nachteile

• Keine dynamische Mitgliedschaftsprüfung möglich (ohne zusätzliche Arbeit).
• Nicht-Enum-Werte können fälschlicherweise für Enum-Werte gehalten werden, statisch oder zur Laufzeit (wenn wir String-Werte verwenden).

13.4 Enum-Pattern

Das folgende Beispiel demonstriert ein von Java inspiriertes Enum-Pattern, das in reinem JavaScript und TypeScript funktioniert

class Color {
  static red = new Color();
  static green = new Color();
  static blue = new Color();
}

// @ts-expect-error: Function lacks ending return statement and return type
// does not include 'undefined'. (2366)
function toGerman(color: Color): string { // (A)
  switch (color) {
    case Color.red:
      return 'rot';
    case Color.green:
      return 'grün';
    case Color.blue:
      return 'blau';
  }
}

assert.equal(toGerman(Color.blue), 'blau');

Leider führt TypeScript keine Vollständigkeitsprüfungen durch, weshalb wir in Zeile A einen Fehler erhalten.

13.5 Zusammenfassung von Enums und Enum-Alternativen

Die folgende Tabelle fasst die Eigenschaften von Enums und ihren Alternativen in TypeScript zusammen

Titel der Tabellenspalten

• Eindeutige Werte: Kein Nicht-Enum-Wert kann mit einem Enum-Wert verwechselt werden.
• Namensraum für Enum-Schlüssel
• Ist es möglich, über Enum-Werte zu iterieren?
• Mitgliedschaftsprüfung für Werte zur Kompilierzeit: Gibt es einen engeren Typ für die Enum-Werte?
• Mitgliedschaftsprüfung für Werte zur Laufzeit
  • Für das Enum-Pattern ist der Laufzeit-Mitgliedschaftstest instanceof.
  • Beachten Sie, dass ein Mitgliedschaftstest relativ einfach implementiert werden kann, wenn es möglich ist, über Enum-Werte zu iterieren.
• Vollständigkeitsprüfung (statisch durch TypeScript)

Fußnoten in Tabellenzellen

1. Diskriminierte Vereinigungen sind nicht wirklich eindeutig, aber die Verwechslung von Werten mit Vereinigungsmitgliedern ist relativ unwahrscheinlich (insbesondere wenn wir einen eindeutigen Namen für die Diskriminanten-Eigenschaft verwenden).
2. Wenn die Diskriminanten-Eigenschaft einen ausreichend eindeutigen Namen hat, kann sie zur Prüfung der Mitgliedschaft verwendet werden.

13.6 Danksagung

• Danke an Kirill Sukhomlin für seinen Vorschlag, wie TColor für ein Objekt-Literal definiert werden kann.