JSON vers TypeScript

Exemple

Entrée :

{ "id": 1, "name": "Alice", "age": null, "tags": ["admin", "user"], "address": { "city": "Madrid" } }

Sortie :

interface User {
  id: number;
  name: string;
  age: number | null;
  tags: string[];
  address: Address;
}

interface Address {
  city: string;
}

Mappage des types

Optionnel vs nullable

• foo?: string, le champ peut être absent de l’objet. La vérification undefined s’applique.
• foo: string | null, le champ est toujours présent mais peut explicitement être null.
• foo?: string | null, peut être absent OU null.

JSON lui-même n’a pas undefined, mais les API varient sur la façon dont elles signalent l’absence. Adaptez-vous à la sémantique de votre API :

• Les API REST omettent généralement les champs manquants -> ?:.
• GraphQL renvoie toujours chaque champ demandé -> | null.
• Certains SDK utilisent les deux dans différents contextes.

Types d’union vs types littéraux

Si l’outil voit le même champ de chaîne avec un petit ensemble de valeurs à travers les exemples ("status": "pending", "active", "archived"), il peut émettre une union littérale de chaînes :

status: "pending" | "active" | "archived";

Activez “inférer des unions littérales de chaînes” si vous le souhaitez.

Erreurs courantes

• Inférer à partir d’un seul exemple. Chaque champ devient requis ; la nullabilité ne peut pas être observée. Passez 5-10 exemples variés pour de meilleurs types.
• Tableaux vides. "tags": [] ne donne aucune information de type, le générateur émet unknown[]. Fournissez un exemple avec au moins un élément.
• Tableaux de types mixtes. [1, "deux", true] produit (number | string | boolean)[]. Cela signifie généralement que le JSON devrait être restructuré plutôt que typé.
• Clés de chaîne numériques. JSON {"1": "a", "2": "b"} est toujours un objet en TypeScript (Record<string, string>), pas un tableau. Le générateur gère cela correctement.