Typen ableiten, statt dieselben Felder dreimal zu pflegen

Pick und Omit sind nicht spiegelbildlich

Beide erzeugen aus einem Typ einen kleineren, und das ist auch schon die ganze Gemeinsamkeit. Pick verlangt, dass die angegebenen Namen tatsächlich im Quelltyp vorkommen, denn sein zweiter Parameter ist auf keyof des ersten eingeschränkt. Ein Tippfehler wird gemeldet, und die Entwicklungsumgebung schlägt beim Tippen die vorhandenen Felder vor. Omit dagegen nimmt jede Zeichenkette entgegen. Wer versehentlich 'kennnung' statt 'kennung' schreibt, entfernt nichts, bekommt keine Meldung und arbeitet ab diesem Moment mit einem Typ, der ein Feld enthält, das er nicht enthalten sollte.

Daraus folgt eine einfache Faustregel: Wenn die Auswahl kurz ist, nimm Pick. Wenn du aus zwölf Feldern eines entfernen willst, ist Omit natürlich kürzer, und dann lohnt sich ein eigener Hilfstyp im Projekt, dessen zweiter Parameter auf keyof eingeschränkt ist. Diese drei Zeilen schreibst du einmal, und ab dann meldet auch das Weglassen einen falschen Namen.

Die zweite Eigenheit von Omit betrifft Typen mit mehreren Varianten, also Vereinigungen, die über ein Feld unterschieden werden. Omit arbeitet nicht auf jeder Variante einzeln, sondern auf der Vereinigung als Ganzem, und übrig bleibt eine einzige Form mit den gemeinsamen Feldern. Wer danach über das unterscheidende Feld verzweigen will, stellt fest, dass der Compiler die Varianten nicht mehr auseinanderhalten kann. Der Ausweg ist ein verteilender Hilfstyp, der über einen bedingten Typ jede Variante einzeln behandelt.

typeof und as const: wenn der Wert die bessere Quelle ist

Manchmal ist die Wahrheit über eine Struktur kein Typ, sondern ein Objekt, das ohnehin im Code steht: die Voreinstellungen einer Komponente, eine Konfiguration, eine Liste erlaubter Werte. Dann ist es unnötig, den passenden Typ danebenzuschreiben, denn genau dieses Nebeneinander läuft auseinander. Mit type Konfiguration = typeof standardKonfiguration holst du den Typ aus dem Wert. Ändert sich der Wert, ändert sich der Typ mit, und zwar ohne dass irgendwer daran denken muss.

Ohne Zusatz verallgemeinert der Compiler dabei allerdings. Aus einem Feld mit dem Wert 'kompakt' wird string, denn ein Objektfeld ist veränderlich und könnte morgen etwas anderes enthalten. Mit as const hinter dem Objekt bleiben alle Felder unveränderlich und die Werte in ihrer engen Form erhalten. Diese Kombination ist die Grundlage für ein Muster, das häufig gebraucht wird: eine Liste erlaubter Werte als Konstante schreiben, mit as const festhalten und daraus über den Zugriff mit [number] den Vereinigungstyp gewinnen. Damit stehen die erlaubten Werte genau einmal im Projekt, und sie stehen dort, wo sie zur Laufzeit ohnehin gebraucht werden.

Zu diesem Muster gehört keyof als Gegenstück. Wo du Feldnamen brauchst, etwa um Spalten einer Tabelle oder Felder eines Formulars zu benennen, schreibst du keyof Kunde statt einer zweiten Liste mit denselben Namen. Der Unterschied zeigt sich beim Umbenennen: Mit keyof meldet der Compiler jede Stelle, ohne keyof bleibt eine Zeichenkette stehen, die zu nichts mehr passt und still eine leere Spalte erzeugt.

Ableiten aus Funktionen und Schemas

Neben Feldern lassen sich auch Signaturen als Quelle nutzen. ReturnType<typeof erzeugeSpeicher> liefert den Rückgabetyp einer Funktion, ohne dass du ihn benennen musst, Parameters<typeof f> die Parameter als Tupel, und Awaited<T> holt den Typ aus einem Promise heraus. Zusammengesetzt ergibt das Awaited<ReturnType<typeof ladeKunden>>, also den Typ dessen, was am Ende tatsächlich ankommt. Für Funktionen, deren Rückgabewert aus mehreren Schritten zusammengesetzt ist, spart das eine Deklaration, die sonst zwangsläufig hinterherhinkt.

Denselben Gedanken verfolgen Schemabibliotheken. Du beschreibst die Struktur einmal als Schema, bekommst daraus eine Prüfung zur Laufzeit und leitest den TypeScript-Typ aus demselben Schema ab. Damit ist ausgeschlossen, dass Prüfung und Typ auseinanderlaufen, denn beide stammen aus einer Zeile. Wo Daten aus dem Netz oder aus Formularen kommen, ist das die konsequenteste Form der Ableitung, weil sie über die Grenze der Übersetzungszeit hinausreicht.

Bei aller Ableitung gibt es eine Grenze, die man kennen sollte. Ein Typ, der über fünf Ecken aus etwas anderem entsteht, ist beim Lesen kaum noch zu erfassen, und in Fehlermeldungen erscheint er ausgeschrieben in voller Länge. Wenn du beim Hovern nicht mehr erkennst, welche Felder ein Typ hat, ist das der Punkt, an dem eine ausdrückliche Deklaration die bessere Wahl ist. Ableiten spart Pflege, aber es ersetzt nicht die Verständlichkeit.

Der Unterschied zwischen Weglassen und Verbieten

Eine Feinheit, die im Alltag Zeit kostet: Ein optionales Feld und ein Feld, das undefined enthalten darf, sind für TypeScript standardmäßig fast dasselbe. Partial macht aus name: string das Feld name?: string, und damit ist auch die ausdrückliche Übergabe von undefined erlaubt. In vielen Fällen ist das egal. Wo es nicht egal ist, etwa bei einer Änderung, bei der ein fehlendes Feld unverändert lässt und ein ausdrückliches undefined löschen soll, brauchst du die Option exactOptionalPropertyTypes, die genau diesen Unterschied wieder herstellt. Sie gehört nicht zu strict und muss einzeln eingeschaltet werden.

Verwandt ist die Frage, ob ein Zugriff über einen Index oder einen dynamischen Schlüssel undefined liefern kann. Standardmäßig behauptet der Compiler, dass hinter jedem Schlüssel ein Wert steht, obwohl das offensichtlich nicht stimmt. noUncheckedIndexedAccess ändert das und macht aus jedem solchen Zugriff eine Vereinigung mit undefined. In Code, der viel mit Nachschlagetabellen arbeitet, ist das die Option mit dem größten Ehrlichkeitsgewinn und gleichzeitig die mit den meisten neuen Meldungen. Auch sie ist bewusst nicht Teil von strict.