Ein JSON-Beispiel wird durchlaufen und daraus ein TypeScript-Interface abgeleitet — aus dem, was tatsächlich vorhanden ist. Verschachtelte Objekte werden zu eigenen benannten Typen statt eingebettet zu werden, das Ergebnis liest sich also wie von Hand geschrieben. Arrays werden über alle ihre Elemente hinweg untersucht statt nur über das erste, und genau das entdeckt ein Feld, das in den meisten Datensätzen eine Zeichenkette ist und in einem null.
Wo die Elemente eines Arrays voneinander abweichen, entsteht ein Union-Typ statt einer Vermutung. Schlüssel, die keine gültigen Bezeichner sind, werden in Anführungszeichen gesetzt, und Schlüssel, die mit reservierten Wörtern kollidieren, werden behandelt. Die Einstellung für optionale Eigenschaften markiert ein Feld als optional, wenn es in manchen Objekten eines Arrays fehlt — meist näher an der Wahrheit, als es als erforderlich zu deklarieren und es später herauszufinden.
Was sich aus einem Beispiel ableiten lässt und was nicht
-
Ein Beispiel ist ein Beleg, keine Spezifikation:
Ein Feld, das in Ihrem Beispiel zufällig eine Zeichenkette ist, wird als Zeichenkette typisiert. Ob die API dort auch null liefern kann, sagt Ihnen nur deren Dokumentation.
-
Geben Sie ihm mehrere Datensätze statt einem:
Ein Array von Objekten gibt der Ableitung etwas zum Vergleichen — nur so werden optionale Felder und Unions überhaupt entdeckt.
-
Zahlen verlieren ihre Unterscheidungen:
JSON kennt nur einen Zahlentyp, eine ganzzahlige Kennung und ein Dezimalpreis werden also beide zu number. Das nachzuschärfen ist Handarbeit.
-
Datumsangaben kommen als Zeichenketten an:
JSON hat keinen Datumstyp. Ein Feld, das wie ein Zeitstempel aussieht, wird als Zeichenkette typisiert, und es umzuwandeln ist eine Entscheidung Ihres Codes.
A sample is evidence, not a specification
The [msm_tool slug="json-to-typescript"] infers a TypeScript interface from what is actually present in the JSON handed to it, which means a field that happens to be a string in the sample is typed as a string — full stop. If the real API can also return null for that field on some other request, nothing in the sample can reveal that, and only the API's own documentation will.
Feed it several records, not one
An array of objects gives the inference something to compare across, which is the only way optional fields and union types get discovered at all. A single object shows only one version of the shape; comparing many is what reveals that a field is sometimes missing, or sometimes a different type entirely.
Numbers lose their distinctions on the way in
JSON has exactly one numeric type, so an integer identifier and a decimal price both arrive as the same kind of value and both become `number` in the generated interface. Narrowing that back into something more specific is a manual step afterwards, since nothing in a JSON sample carries the distinction to infer from.
Dates arrive as strings, because JSON has no date type
A field that looks exactly like a timestamp is typed as a string regardless, since JSON itself has no native date representation for the inference to detect. Converting that string into an actual date remains a decision made in code, not something the generated type can express on its own.
Nested objects become their own named types
Rather than inlining a nested object's shape directly into its parent, each one is given its own named interface, which reads closer to what a person would actually write by hand and makes the resulting type reusable elsewhere rather than trapped inside a single larger definition.
Where the elements of an array disagree
When different objects in the same array show a field taking different types, the result is a union type rather than a guess at which one is "correct" — both possibilities are represented rather than one being silently discarded. Keys that are not valid identifiers are quoted, and keys that collide with reserved words are handled rather than left to produce invalid TypeScript.