Convertisseur JSON vers TypeScript | Générez des types à partir d'un échantillon

Collez un échantillon JSON et l'outil parcourt ses clés et valeurs pour déduire des définitions interface ou type TypeScript. Les objets imbriqués et les tableaux deviennent des types nommés, et vous pouvez ajouter readonly ou rendre tous les champs optionnels en un clic.

💡 À propos de cet outil

Brancher une API tierce mène toujours à la même corvée : la documentation reste floue, on interroge l'endpoint, on récupère un JSON de quarante champs, et il faut écrire l'interface à la main. Un objet imbriqué oublié et TypeScript proteste ; une clé mal orthographiée et l'on hérite d'un any silencieux. Pour une charge utile profondément imbriquée, ce travail manuel est lent et sujet aux erreurs de recopie.

Déposez une réponse JSON représentative et le convertisseur déduit la forme. Les chaînes deviennent string, les nombres (entiers ou décimaux) number, les booléens boolean, null reste null, et les tableaux prennent le type de l'élément suivi de []. Chaque objet imbriqué est extrait dans sa propre définition : une chaîne user.address.geo donne Root, Address et Geo, de sorte que le modèle se lit de haut en bas. Si la racine est un tableau d'objets, vous obtenez un type RootItem et un alias type Root = RootItem[].

Basculez entre interface et type avec le commutateur. Ajoutez readonly pour les modèles immuables, ou cochez « tous les champs optionnels » pour apposer ? sur chaque propriété quand vous typez un objet partiel. La sortie est un point de départ propre que vous collez directement dans votre éditeur, puis affinez.

🧐 Questions fréquentes

Q. Comment les objets imbriqués sont-ils traités ? Chacun est extrait dans un type distinct portant le nom de sa clé avec une majuscule initiale. Un objet profile dans user devient une définition Profile autonome, et le type parent y fait référence par son nom plutôt que de l'incorporer.

Q. Comment le type des tableaux est-il déduit ? À partir du premier élément. [1, 2, 3] donne number[] ; un tableau d'objets produit un type QuelqueChoseItem enveloppé en tableau. Un tableau vide ne peut être déduit et retombe sur unknown[].

Q. interface ou type : lequel choisir ? Utilisez interface si vous comptez sur extends ou la fusion de déclarations ; utilisez type si vous ajoutez des unions, des intersections ou des signatures de fonction. Pour de simples formes d'objet, ils sont interchangeables : suivez la convention de votre équipe.

Q. Pourquoi tous les nombres sont-ils number ? TypeScript n'a pas de type entier : 1 et 1.5 sont tous deux number. De même, les dates et les identifiants sortent en string. Considérez la sortie comme un brouillon et restreignez-la à Date ou à des types littéraux là où c'est utile.

Q. Et les champs parfois null ? Si la valeur de l'échantillon est null, vous obtenez le type null. En pratique cela signifie souvent « chaîne ou null » : après génération, élargissez ces champs à la main vers une union comme string | null, car un échantillon ne montre qu'une forme à la fois.

📚 Le saviez-vous

TypeScript utilise un typage structurel, non nominal : deux types sont compatibles si leurs formes correspondent, peu importe leur nom. C'est pourquoi une interface Root générée s'insère partout où le type réel est attendu tant que les champs concordent — pratique, mais cela signifie aussi que deux objets de sens différent mais de même forme sont interchangeables sans avertissement. La parade de la communauté, ce sont les types « marqués » comme type UserId = string & { __brand: 'UserId' }, qui ajoutent une propriété fantôme pour qu'une string quelconque ne se glisse pas. Les types tirés d'un échantillon sont une ligne de départ, pas d'arrivée : il reste à ajouter la sûreté face à null, les unions littérales et les conversions en Date avant qu'ils ne soient prêts pour la production.