JSON vers TypeScript : Générez des interfaces précises à partir de données d'API réelles

Le bug qui m'a finalement fait arrêter d'écrire manuellement les types d'API était embarrassant. Un point de terminaison de paiement est revenu discount: null pour les clients sans, et je l'avais tapé discount: number parce que la seule réponse que j'ai regardée en écrivant l'interface s'est avérée être un client avec une remise TypeScript était parfaitement heureux Le compilateur n'avait aucun moyen de savoir I&#39 ; d lui a menti Trois semaines plus tard a .toFixed(2) dans ce domaine, la production a été lancée pour exactement le sous-ensemble d'utilisateurs qui comptait le moins pour mes tests et le plus pour la facture.

C'est tout le problème de taper une API à la main : vous tapez ce que vous croire le point de terminaison revient, et le compilateur applique consciencieusement votre croyance plutôt que la réalité Chaque garantie que TypeScript vous donne en aval est aussi bonne que cette première interface manuscrite, et il n'y a rien dans la chaîne d'outils qui la vérifie par rapport à une réponse réelle Vous obtenez toute la cérémonie de frappe statique sans aucune des sécurités, ce qui est sans doute pire que aucun type du tout - au moins un code non typé vous rend suspect.

Générer des types à partir d'une charge utile réelle inverse la direction Au lieu de décrire ce que vous pensez être la forme, vous prenez une réponse que le serveur a réellement envoyée et en dérivez la forme La sortie est mécanique : aucun optimisme, aucun champ que vous avez oublié n'existait, non number où les données disent number | null. Je construis [Toolz.dev](/et j'ai mis un navigateur Convertisseur JSON vers TypeScript là, cela fait cela, mais ce guide concerne les règles d'inférence elles-mêmes - ce qu'un générateur peut comprendre, ce qu'il ne peut que deviner et où il faut encore penser.

tl;dr : Pour convertir JSON en TypeScript, déduisez chaque clé&#39 ; s tapez à partir de sa valeur (string, number, boolean, null), extrayez les objets imbriqués dans leurs propres interfaces nommées, et fusionnez les tableaux d'objets dans une interface à élément unique où toute clé manquante de certains membres devient facultative Décidez délibérément si null ressources key?: T ou key: T | null- ce choix dépend si votre API omet les champs absents ou les envoie comme nuls. L'inférence reflète uniquement l'échantillon que vous fournissez, alors utilisez une charge utile représentative avec plusieurs enregistrements et traitez la sortie comme une première ébauche révisée plutôt que comme un contrat fini.

Pourquoi générer des types TypeScript à partir de JSON au lieu de les écrire ?

La réponse honnête est que les types manuscrits dérivent et les types générés don&#39 ; t. Lorsque le backend ajoute un champ, votre interface manuscrite reste silencieusement fausse ; rien d'erreur, car les propriétés supplémentaires dans une réponse sont invisibles pour un type qui ne les mentionne pas. Lorsque le backend change id d'un numéro à une chaîne, votre interface continue d'insister sur & #39 ; c'est un numéro et TypeScript continue d'être d'accord, jusqu'à ce que quelque chose concatène au lieu d'ajouter.

There&#39 ; s aussi l'argument du tedium simple Une réponse REST typique a trente clés sur quatre niveaux d'imbrication Transcrivant que par la main prend dix minutes de travail mécanique pur, et le travail mécanique effectué par les humains a un taux de défauts Vous allez taper un nom de clé Vous allez manquer le seul champ qui&#39 ; est un tableau d'objets plutôt qu'un tableau de chaînes Le générateur ne le fera pas.

Mais la raison la plus forte est que la génération fait la forme visible. Collez une réponse dans un convertisseur et vous voyez immédiatement les choses que vous et #39 ; j'ai passé sous silence la lecture brute de JSON : ça metadata est en fait un objet profondément imbriqué, ça tags est parfois vide, que la moitié des clés de votre liste paginée sont absentes de certains enregistrements L'interface générée est un résumé de la structure réelle de data&#39 ; s, et sa lecture est souvent le moyen le plus rapide de comprendre un point de terminaison que vous avez fait&#39 ; t écrivez I&#39 ; l'avez utilisé comme étape de documentation plus d'une fois sur les API dont les docs étaient un mensonge.

Lorsque cela correspond à vos autres outils de données : si vous et n°39 ; inspectez la charge utile plutôt que de la taper, le Formateur JSON est le meilleur premier arrêt, et si vous et #39 ; comparez deux réponses pour voir ce qui a changé entre les versions, le Diff JSON répond que directement.

Comment fonctionne réellement l'inférence de type de JSON ?

JSON a six types de valeurs, par RFC 8259: objet, tableau, chaîne, nombre, true/false, et null. TypeScript&#39 ; les types primitifs s'adaptent presque directement à quatre d'entre eux. Le travail intéressant se trouve entièrement dans les deux autres.

Les primitives sont triviales. Une valeur de chaîne implique string. Un chiffre implique number- notez que JSON a un type numérique, donc là&#39 ; n'a aucune information dans les données vous indiquant si 1 est un entier ou un flottant, et TypeScript fait & #39 ; je ne distingue pas de toute façon. true ou false implique boolean. Cette partie n'a aucune ambiguïté.

Les objets deviennent des interfaces. Chaque valeur d'objet devient une interface nommée, et la clé sous laquelle elle est apparue fournit le nom, converti en PascalCase Une clé owner produit interface Owner. Le nidification revient : un objet à l'intérieur d'un objet produit une deuxième interface référencée à partir de la première Cela compte plus que cela n'en a l'air L'alternative - inliner chaque forme imbriquée de manière anonyme - produit une seule déclaration illisible et ne vous donne rien d'importable :

// Inlined: technically correct, practically useless
interface Project {
  owner: { id: number; email: string; twoFactor: boolean }
}

// Extracted: you can import and reference Owner on its own
interface Project {
  owner: Owner
}

interface Owner {
  id: number
  email: string
  twoFactor: boolean
}

Une fois Owner existe sous forme de nom, une fonction qui prend uniquement le propriétaire peut être saisie (owner: Owner) => void. Avec la version en ligne, vous et #39 ; serait en train d'écrire Project['owner'] partout, ce qui fonctionne mais lit mal.

Les tableaux sont l’endroit où vivent les véritables décisions. Un tableau&#39 ; s type est l'union de ses types d'éléments, donc [1, 2, 3] donne number[] et [1, "a"] donne (number | string)[]. Notez les parenthèses dans cette seconde - sans elles, number | string[] signifie quelque chose de complètement différent (un nombre ou un tableau de chaînes) et des générateurs qui oublient cela émettent du code qui compile mais décrit la mauvaise chose.

Les tableaux vides sont une impasse honnête. "tags": [] vous dit qu'une clé existe et contient un tableau ; il ne vous dit rien sur ce qui y entre. La sortie correcte est unknown[](en), et vous devriez lire cela comme le générateur refusant de deviner plutôt que comme une réponse finie Remplissez-le en vous-même à partir de la documentation, ou trouvez un échantillon où le tableau est & #39 ; t vide.

Pourquoi les tableaux d’objets sont-ils fusionnés au lieu d’être syndiqués ?

Il s'agit de la décision unique qui sépare un générateur que vous et #39 ; utiliserait à partir d'un que vous et #39 ; abandonnerait après cinq minutes.

Considérons une réponse paginée où les enregistrements sont & #39 ; t parfaitement uniforme - c'est-à-dire, chaque vraie réponse paginée :

{
  "rows": [
    { "id": 1, "name": "Ada", "nickname": "The Countess" },
    { "id": 2, "name": "Grace" }
  ]
}

Traitez chaque élément indépendamment et vous obtenez une union de deux interfaces : rows: (Row1 | Row2)[]. Ceci est techniquement la lecture la plus précise de l'échantillon, et il est inutile Chaque accès à row.nickname maintenant, nécessite un rétrécissement, car TypeScript can&#39 ; ne sait pas quel membre du syndicat vous avez Étendez cela à une réponse de cinquante enregistrements avec plusieurs champs facultatifs et vous obtenez une union de dizaines d'interfaces presque identiques Personne ne veut cela.

La lecture utile est que ces deux objets sont deux instances d'une seule entité, et nickname est un champ Grace does&#39 ;t avoir :

interface Row {
  id: number
  name: string
  nickname?: string
}

interface T {
  rows: Row[]
}

That&#39 ; est une fusion : collectez chaque clé vue sur tous les éléments et marquez une clé facultative si elle&#39 ; est absente de l'un d'entre eux. Il correspond à la façon dont les données sont réellement produites - une table de base de données, un sérialiseur, des colonnes annulables - et il produit des types que vous pouvez utiliser sans cérémonie. Le nom de l'élément de tableau est également singularisé, donc releases rendements Release plutôt que Releases, parce que releases: Releases[] se lit comme un bug même lorsqu'il est & #39 ; t.

Le compromis est réel et mérite d'être clairement énoncé : la fusion suppose que le tableau est homogène. Si vous disposez d'un tableau véritablement hétérogène - un flux d'événements de formes différentes, discriminés par a type field - fusionner aplatit des variantes distinctes en une seule interface où presque tout est facultatif That&#39 ; est le mauvais modèle, et it&#39 ; est un cas où vous devriez prendre la sortie générée comme point de départ et écrire à la main une union discriminée appropriée. Generators don&#39 ; ne pas connaître votre domaine Celui-ci fusionne les objets et unit tout le reste, ce qui est bien la plupart du temps et mal d'une manière que vous pouvez repérer immédiatement.

La valeur nulle doit-elle devenir une clé facultative ou un membre du syndicat ?

Les deux conventions sont défendables et la différence se mord, alors décidez du but plutôt que d'accepter ce à quoi votre outil ne parvient pas.

Étant donné { "retiredAt": null }, il y a deux lectures :

interface A { retiredAt?: string }      // the field may be absent
interface B { retiredAt: string | null } // the field is present and may be null

Ils ne sont pas interchangeables En A, retiredAt est string | undefined et la clé pourrait ne pas exister du tout sur l'objet. Dans B: la clé existe toujours et sa valeur pourrait l'être null. Sous strictNullChecks- lequel le Manuel TypeScript les recommandations et celles que vous devriez avoir - vous obligent toutes deux à traiter le cas absent, mais elles imposent des contrôles différents et elles sérialisent différemment. JSON.stringify omet undefined propriétés entièrement et émet null pour les nuls, le choix se propage jusqu’au fil.

La bonne réponse dépend de l'API&#39 ; son comportement réel, qu'aucun générateur ne peut voir à partir d'un échantillon :

Votre API&#39 ;s comportement	Modèle correct	pourquoi
Omet la clé quand il n'y a & #39 ; n'a aucune valeur	key?: T	La clé est véritablement & #39 ; là ; facultatif est exact
Envoie toujours la clé, null lorsqu'il est vide	key: T | null	La clé est toujours présente ; ? permettrait à tort l'absence
Incohérent - parfois omis, parfois nul	key?: T | null	Les deux cas sont réels ; modélisez les deux
Envoie null uniquement sur les réponses d'erreur	Ni l'un ni l'autre - modélisez l'erreur séparément	Un champ annulable cache une union de formes de réponse

Cette dernière ligne est celle qui mérite une pause Un champ qui devient nul uniquement dans les cas d'échec est un signal que le point final renvoie deux choses différentes en portant une forme, et le correctif est une union discriminée sur un champ d'état, pas une propriété nullable La génération de type fait surface ce modèle ; il ne résout pas le problème & #39 ; pas le résoudre.

Le convertisseur est par défaut key?: T parce que omise-quand-absent est la convention la plus courante dans les API JSON I&#39 ; a travaillé avec, et parce qu'il compose mieux avec la fusion de tableaux décrite ci-dessus (une clé manquante dans certains enregistrements et une clé that&#39 ; les nuls dans certains enregistrements sont modélisés de la même manière).Éteignez l'option et null reste dans le syndicat à la place Ni l'un ni l'autre n'est une astuce ; choisissez celui que votre API fait réellement.

Qu'en est-il des clés qui sont les identifiants TypeScript valides & #39 ; t ?

Les clés d'objet JSON sont des chaînes arbitraires Noms de propriété TypeScript dans un nu key: T position ne sont pas - ils doivent être des identifiants valides Donc "content-type", "2fa", "user.name", et "" sont toutes les clés JSON légales qui ne peuvent pas être écrites sans citation dans une interface.

Le correctif est une citation, et il&#39 ; n'est pas une solution de contournement - les noms de propriétés cités sont ordinaires TypeScript :

interface Headers {
  "content-type": string
  "2fa": boolean
  class: string
}

Ces propriétés sont accessibles avec la notation entre parenthèses (headers["content-type"]), qui est légèrement plus verbeux mais entièrement sûr. Notez que class does&#39 ;t besoin de citer : les mots réservés sont parfaitement légaux comme noms de propriétés[traduction], même s'ils & #39 ; sont illégaux en tant qu'identifiants La restriction ne s'applique que lorsque TypeScript attend un identifiant - c'est pourquoi le même mot a besoin d'être manipulé lorsqu'il devient une interface nom.

Les noms d'interface dérivés de telles clés nécessitent plus de travail que de citation. 2fa Cas Pascal à 2fa(en), qui peut&#39 ; t démarrer un identifiant, donc il obtient un préfixe Deux objets imbriqués différents tous deux sous des clés nommées owner voudraient l'être tous les deux Owner: donc le second devient Owner2. Ce sont des détails peu glamour, et ils&#39 ; sont exactement les détails qui décident si la sortie générée compile ou a besoin de quinze minutes de réparation manuelle avant elle. Le test auquel je maintiens le convertisseur est simple : collez tout ce qui est valide et la sortie doit être compilée ci-dessous strict sans modifications.

Interfaces ou alias de type ?

Le générateur émet soit Les différences pratiques sont étroites mais réelles, et votre base de code a probablement déjà une opinion codée dans sa configuration de peluches.

interface User {} prend en charge la fusion de déclarations - déclarez deux fois le même nom d'interface et TypeScript les combine That&#39 ; est essentiel pour augmenter les types des bibliothèques que vous contrôlez par don&#39 ; t et une arme de pied partout ailleurs, puisque deux déclarations non liées du même nom fusionnent silencieusement au lieu d'erreurs. Les interfaces prennent également en charge extends(en), qui produit des messages d'erreur légèrement meilleurs que les types d'intersection lorsqu'une contrainte échoue.

type User = {} can&#39 ; t fusionner, qui est généralement une fonctionnalité, et it&#39 ;s requis pour tout ce qui est & #39 ; t une forme d'objet : unions, tuples, types mappés, types conditionnels Une racine qui est & #39 ; t un objet JSON - un tableau de nombres, une chaîne nue - ne peut être exprimé que comme un alias, donc type Nums = number[] est ce que vous obtenez quel que soit le paramètre.

Pour les types d'API générés, je penche vers interface[traduction], surtout parce que les messages d'erreur sont légèrement meilleurs et parce que le risque de fusion est théorique lorsque chaque nom vit dans un fichier généré Mais c'est proche d'un tirage au sort, et la cohérence avec le code environnant importe plus que les mérites Si votre configuration ESLint a @typescript-eslint/consistent-type-definitions réglez dans les deux sens, faites-le correspondre et arrêtez d’y penser.

En quoi est-ce différent de JSON Schema à TypeScript ?

Ceux-ci résolvent des problèmes véritablement différents et cela & #39 ; vaut la peine d'être précis, car &quot ; JSON à TypeScript&quot ; et &quot ; JSON Schema à TypeScript&quot ; sont distants d'un mot et fréquemment confondus.

JSON à TypeScript est une inférence à partir d'un exemple. Entrée : une valeur Le générateur observe quoi et #39 ; là et généralise Il ne peut pas savoir si un champ est requis, si une chaîne est contrainte à un énum, si un nombre a un minimum ou si l'échantillon que vous avez collé est représentatif. It&#39 ; s induction à partir d'une seule observation, avec tout ce que cela implique.

JSON Schema to TypeScript est une traduction à partir d'une déclaration. Entrée : a Schéma JSON document, qui indique déjà les types, required tableaux, énumérations, formats et contraintes Le générateur est & #39 ; t devinant - it& #39 ; s translittérant un contrat existant dans la syntaxe TypeScript. required cartes vers des propriétés non facultatives ; un enum mappes à une union littérale de chaîne ; oneOf cartes à un type d'union.

La règle suit directement : si un schéma existe, utilisez-le. Un schéma JSON, une spécification OpenAPI, a .proto fichier, ou un schéma GraphQL fait autorité d'une manière qu'une réponse échantillonnée n'est jamais. L'inférence est ce que vous recherchez lorsqu'aucun schéma n'existe - un point de terminaison interne non documenté, une API tierce dont les documents sont obsolètes, un format de fichier de configuration qui s'est développé de manière organique, un luminaire contre lequel vous et n°39 écrivez. Ce qui, en toute honnêteté, décrit une grande partie du JSON dont chacun d’entre nous traite réellement.

There&#39 ; est un chemin du milieu qui mérite d'être mentionné : utilisez l'inférence pour amortisseur(en anglais), puis maintenez à la main Générez l'interface à partir d'une réponse réelle pour obtenir la forme et les noms de champs corrects, puis modifiez-la - serrez a string dans une union littérale où vous connaissez les valeurs autorisées, fixez un unknown[] l'échantillon laissé vide, divisez une interface fusionnée en une union discriminée appropriée Le générateur fait le 90 % mécanique et vous appliquez la connaissance du domaine qu'il ne peut pas avoir structurellement.

Où l'inférence se trompe-t-elle ?

Une liste courte et honnête Chacun d'entre eux est une limitation de l'approche, pas un bug dans un outil particulier, et les connaître est la différence entre bien utiliser les types générés et se faire brûler par eux.

Des échantillons uniques sous-déterminent le type. Un champ qui's number dans votre échantillon pourrait être null dans 5 % des enregistrements Un champ qui&#39 ; s présent dans les trois enregistrements que vous avez collés pourrait être facultatif sur l'ensemble complet de données Inférence rapporte ce qu'il a vu Coller plus d'enregistrements - idéalement une vraie page de résultats plutôt qu'un objet trié sur le volet - et les optionnels deviennent significativement plus précis.

Les chaînes cachent leurs vrais types. Les horodatages ISO, les UUID, les URL et les adresses e-mail sont tous justes string vers un analyseur JSON. "2026-07-16T09:00:00Z" est sémantiquement une date ; rien dans les données ne le dit Si votre base de code a une marque ISODateString tapez, vous&#39 ; le remplacez à la main.

Les nombres perdent les distinctions de précision. JSON&#39 ; Le type de numéro unique signifie un ID that&#39 ; un entier de 64 bits sur le serveur arrive sous forme de numéro JavaScript et a peut-être déjà perdu en précision avant que votre générateur ne le voie - Number.MAX_SAFE_INTEGER est d'environ 9×10¹5, et Twitter l'a appris à ses dépens. Si votre API envoie de grands entiers sous forme de chaînes, cela&#39 ; c'est pourquoi et le généré string est correct.

Les valeurs littérales ressemblent à leurs types généraux. "status": "active" infère string, pas "active" | "archived" | "pending". Le type plus étroit est plus utile et aucun échantillon ne peut le prouver. C’est la modification manuelle la plus courante que je fais à la sortie générée.

Les conteneurs vides ne disent rien. [] donne unknown[] et {} donne une interface vide Les deux sont le générateur étant honnête.

Rien de tout cela ne rend l’inférence dangereuse - cela en fait un projet. Le flux de travail qui fonctionne est : générer, lire attentivement la sortie, réparer les quatre ou cinq choses que vous savez que l'échantillon pourrait&#39 ; t dire, commit. That&#39 ;s toujours un ordre de grandeur plus rapide et plus précis que transcrire trente clés à la main, qui est la véritable alternative.

Mon JSON est-il téléchargé quelque part ?

Non, et c'est une catégorie d'outil où la question mérite une vraie réponse plutôt qu'un badge.

Pensez à quoi et à quoi #39 ; dans le JSON que vous et #39 ; d coller dans un générateur de types It&#39 ; est une réponse API, ce qui signifie qu'elle contient de manière plausible un jeton support, un identifiant de session, un e-mail client, un identifiant utilisateur interne, un niveau de tarification, un secret de webhook. That&#39 ; n'est pas hypothétique - it&#39 ; est le cas modal, car le point est que vous avez saisi un immeuble réponse à taper contre.

Tout convertisseur côté serveur reçoit nécessairement cette charge utile Il peut ne pas l'enregistrer, et il fait probablement & #39 ; t, mais vous & #39 ; étendez la confiance vous don & #39 ; pas besoin d'étendre, et en fonction des données, vous pouvez créer un problème de conformité pour une tâche qui n'a aucune activité touchant un réseau du tout.

L'inférence de type est un calcul pur sur une valeur analysée Il n'a besoin d'aucun réseau, aucun compte, aucun stockage Le convertisseur sur Toolz.dev est quelques centaines de lignes de TypeScript sans dépendance exécutées dans votre onglet ; la charge utile est une chaîne JavaScript dans votre navigateur&#39 ; s mémoire et il reste là Vous pouvez vérifier cela de la façon dont vous&#39 ; d vérifier une telle affirmation - ouvrir l'onglet réseau et appuyez sur Générer, ou éteignez votre wifi et regardez-le continuer à fonctionner C'est le même principe derrière chaque outil sur le site, et I&#39 ; a écrit sur pourquoi il importe plus largement dans pourquoi les outils basés sur un navigateur battent ceux côté serveur pour les données sensibles.

Un exemple travaillé

Ici et n°39 ; est l'échantillon avec lequel l'outil est livré, qui est délibérément construit pour exercer toutes les règles ci-dessus :

{
  "id": 4821,
  "name": "Toolz",
  "isPublic": true,
  "retiredAt": null,
  "owner": {
    "id": 12,
    "email": "[email protected]",
    "twoFactor": false
  },
  "tags": ["developer", "privacy", "browser"],
  "releases": [
    { "version": "1.0.0", "downloads": 1420, "notes": "First cut" },
    { "version": "1.1.0", "downloads": 3310 }
  ]
}

Avec la racine nommée Project, cela génère:

export interface Project {
  id: number
  name: string
  isPublic: boolean
  retiredAt?: null
  owner: Owner
  tags: string[]
  releases: Release[]
}

export interface Owner {
  id: number
  email: string
  twoFactor: boolean
}

export interface Release {
  version: string
  downloads: number
  notes?: string
}

Lisez ce qui s'est passé. owner a été extrait dans sa propre interface et référencé par son nom. tags s'est effondré string[] parce que chaque élément était une chaîne. releases a fusionné ses deux membres en un seul Release- singularisé - et notes devenu facultatif car la deuxième version n'en avait pas & #39 ; pas d'un. retiredAt devenu facultatif car sa seule valeur observée était nulle.

Et maintenant, lisez ce que vous et le numéro 39 ; j'ai corrigé. retiredAt?: null est-ce que le générateur & #39 ; est un rapport honnête selon lequel il n'a jamais vu de valeur non nulle, et il & #39 ; est inutile en tant que type - vous et #39 ; je le changerai en retiredAt?: string parce que vous le savez, le numéro 39 ; est un horodatage lorsqu'il est présent. Cette seule modification est toute la leçon : le générateur a obtenu la structure à sept touches, l'imbrication, la fusion du tableau et l'optionalité en un seul collet, et vous a laissé la seule décision qui nécessitait de savoir ce que signifie le champ.

FAQ

Comment convertir JSON en une interface TypeScript ?

Collez votre JSON dans le convertisseur, définissez le nom du type racine sur quel que soit le nom de la ressource et appuyez sur Générer. Il infère le type de chaque clé, extrait les objets imbriqués dans leurs propres interfaces nommées, fusionne des tableaux d'objets en un seul type d'élément et génère le code que vous pouvez copier directement dans un .ts fichier. Là et n°39 ; il n'y a pas d'inscription ni de téléchargement - l'inférence s'exécute dans votre navigateur.

Qu'arrive-t-il aux tableaux d'objets ?

Ils&#39 ; sont fusionnés en une seule interface décrivant un seul élément, et la propriété est tapé comme un tableau de celui-ci Toute clé qui apparaît dans certains membres du tableau mais pas dans d'autres devient facultative Cela correspond à la façon dont les données paginées réelles se comportent, où les enregistrements proviennent d'une table et certaines colonnes sont nullables Le seul cas qu'il gère mal est un tableau véritablement hétérogène de différents types d'événements, que vous devriez convertir manuellement en une union discriminée.

Est-ce que null devrait devenir une clé facultative ou une union avec null ?

Cela dépend si votre API omet des champs absents ou les envoie comme null. S'il les omet, key?: T est exact Si la clé est toujours présente et parfois nulle, key: T | null est précis et utilisant ? permettrait à tort que la clé manque. Le convertisseur passe par défaut à facultatif et vous permet de basculer, car les deux sérialisent différemment JSON.stringify abandonne les propriétés indéfinies mais émet des propriétés nulles.

Peut-il déduire des types précis à partir d’un seul échantillon JSON ?

Il en déduit des types précis pour cet échantillon[traduction], qui est & #39 ; t la même chose Un champ qui & #39 ; est un numéro dans votre seul enregistrement pourrait être nul dans d'autres ; un champ présent dans les trois enregistrements que vous avez collés pourrait être facultatif dans l'ensemble complet de données Utilisez une charge utile représentative avec plusieurs enregistrements plutôt qu'un objet trié sur le volet, et traitez la sortie comme une ébauche examinée plutôt que comme un contrat fini.

Quelle est la différence entre JSON à TypeScript et JSON Schema à TypeScript ?

Cet outil infère les types à partir d'une valeur d'exemple ; JSON Schema to TypeScript traduit un schéma formel qui déclare déjà les types, les champs obligatoires et les enums Le schéma fait autorité et l'inférence est une supposition, donc si vous avez un schéma JSON, une spécification OpenAPI ou un schéma GraphQL, utilisez-le L'inférence est pour le cas très courant où aucun schéma n'existe et tout ce que vous avez est un corps de réponse.

Comment gère-t-il les clés qui sont les identifiants valides &#39 ;t ?

Les touches avec tirets, points, espaces ou chiffres principaux sont indiquées dans la sortie, donc "content-type" se transforme "content-type": string. That&#39 ; s valide TypeScript, accessible avec la notation entre crochets Mots réservés comme class don&#39 ; n'ont pas besoin de citer comme noms de propriétés Les noms d'interface dérivés de telles clés sont PascalCased et préfixés s'ils&#39 ; d commencer par un chiffre, et les noms en collision obtiennent un suffixe numérique afin que la sortie compile toujours.

Dois-je générer des interfaces ou taper des alias ?

Correspondre à ce que votre base de code fait déjà - c'est surtout une question de cohérence Interfaces support déclaration fusionner et extends[traduction], et donner des messages d'erreur légèrement plus clairs Les alias de type peuvent&#39 ; t fusionner, ce qui est habituellement souhaitable, et sont requis pour tout ce qui est&#39 ; t une forme d'objet Une racine qui&#39 ; est un tableau ou une primitive est émise comme un alias de toute façon, puisque là&#39 ; n'est aucun objet pour déclarer une interface pour.

Mon JSON est-il téléchargé sur un serveur ?

Non. L'ensemble du moteur d'inférence fonctionne comme JavaScript dans votre navigateur, sans appels réseau, sans journalisation et sans stockage. Cela compte ici plus que pour la plupart des outils, car le collage JSON you&#39 ; d dans un générateur de types est généralement une véritable réponse API contenant des jetons, des enregistrements client ou des identifiants internes. Ouvrez votre onglet réseau tout en générant ou déconnectez-vous d'Internet - il continue de fonctionner.

---

Outils associés : Formateur JSON Pour inspecter la charge utile en premier, JSON vers Yaml et JSON vers XML pour la conversion de format, et Diff JSON Pour repérer ce qui a changé entre deux réponses. Lectures complémentaires : Le guide ultime des outils JSON et Guide des outils de codage du développeur.