JSON zu TypeScript
Eine Beispiel-Nutzlast in TypeScript-Interfaces verwandeln — verschachtelte Objekte bekommen einen eigenen Typ, gemischte Arrays werden zu Unions, und Schlüssel, die in manchen Zeilen fehlen, kommen als optional heraus.
JSON
TypeScript
Über dieses Tool
Eine API-Antwort von Hand zu typisieren ist mühsam und schnell subtil falsch. Eine echte Nutzlast einfügen genügt, und die Interfaces dazu entstehen: Jedes verschachtelte Objekt wird zu einem eigenen benannten Typ, Arrays von Objekten werden zu einer einzigen Form zusammengeführt, sodass ein in manchen Zeilen fehlender Schlüssel als optional markiert wird, und gemischte Arrays werden zu Unions. Identische Formen werden einmal ausgegeben und geteilt. Was nicht geht, ist über das Beispiel hinaus zu raten — ein Feld, das in deinem Beispiel null ist, wird als null typisiert, weil nichts in den Daten etwas anderes sagt.
So wird es benutzt
- 1Eine repräsentative JSON-Antwort einfügen — je mehr Zeilen ein Array hat, desto besser die Erkennung optionaler Felder.
- 2Den Wurzeltyp benennen und interface oder type wählen, passend zur eigenen Codebasis.
- 3Das Ergebnis in eine .d.ts-Datei kopieren und danach jedes Feld weiten, das das Beispiel zu eng beschrieben hat.
Häufige Fragen
›Wie wird entschieden, welche Felder optional sind?
Durch Vergleich der Objekte in einem Array. Ist ein Schlüssel in manchen Elementen vorhanden und in anderen nicht, wird er als optional markiert; ein überall vorhandener Schlüssel ist Pflicht. Ein einzelnes Objekt liefert dafür keinen Anhaltspunkt, dort kommt jeder Schlüssel als Pflichtfeld heraus.
›Warum ist ein Feld als null statt als string | null typisiert?
Weil null alles war, was das Beispiel gezeigt hat. Inferenz kann nur beschreiben, was sie gesehen hat — solche Felder von Hand weiten oder ein Beispiel einfügen, das einen belegten Wert enthält.
›Warum teilen sich zwei verschiedene Schlüssel ein Interface?
Identische Formen werden einmal ausgegeben und wiederverwendet, das hält die Ausgabe kurz. Das Interface umbenennen, wenn die beiden konzeptionell verschiedene Typen sind, die heute nur zufällig gleich aussehen.
›interface oder type — was soll ich nehmen?
Interfaces lassen sich erweitern und per Deklaration zusammenführen, was zu Objektformen und öffentlichen APIs passt. Type-Aliase decken zusätzlich Unions und Mapped Types ab. Für schlichte generierte Nutzlastformen verhalten sich beide gleich, nimm also das, was deine Codebasis ohnehin verwendet.
›Validiert das die Daten zur Laufzeit?
Nein. TypeScript-Typen werden beim Kompilieren gelöscht, nichts prüft also, ob eine API-Antwort tatsächlich passt. Wer Laufzeitgarantien braucht, generiert stattdessen ein Schema mit Zod oder Valibot und leitet den Typ daraus ab.