Convertisseur JSON en Dactylographié

Le convertisseur mappe les types JSON aux types TypeScript comme suit: les chaînes JSON deviennent des chaînes; Les nombres JSON deviennent des nombres (avec un avertissement concernant le manque de types spécifiques aux entiers dans TypeScript); Les booléens JSON deviennent booléens; JSON null devient nul ou indéfini en fonction de votre configuration (avec null affirmant que la valeur peut être nulle, ce qui signifie que la valeur doit être explicitement définie, tandis que undefined signifie que la propriété peut être absente); Les tableaux JSON deviennent Array<T> ou T[] où T est le type d'élément déduit (les tableaux mixtes utilisent des types d'union); Les objets JSON deviennent des interfaces imbriquées avec Noms PascalCase dérivés du contexte. Le convertisseur détecte également: les candidats enum (les champs de chaîne qui ont toujours le même ensemble de valeurs deviennent des types d'union littéraux de chaîne), les candidats en lecture seule (champs inchangés d'un échantillon à l'autre) et les champs facultatifs (propriétés présentes uniquement dans certains éléments du tableau).

L'interface et l'alias de type ont tous deux leurs avantages. L'interface est préférée pour les types en forme d'objet car: elle peut être étendue (étend le mot-clé pour l'héritage), elle prend en charge la fusion de déclarations (utile lors de l'augmentation des types existants), elle produit des messages d'erreur plus clairs dans la plupart des compilateurs et c'est le choix conventionnel pour les formes de données API. L'alias de type (type) est préféré lorsque vous avez besoin de: types d'union (A | B), types d'intersection( A & B), types mappés, types conditionnels, ou pour nommer des primitives et des tuples. Pour la modélisation des données d'API (le cas d'utilisation le plus courant), l'interface est généralement le meilleur choix car les formes de réponse d'API sont généralement des types d'objets qui bénéficient de capacités d'extension. Toutefois, si vous envisagez de combiner vos types générés avec des types union ou conditionnels, l'alias de type peut être plus flexible. Le convertisseur peut générer l'un ou l'autre formulaire en fonction de vos préférences.

Le convertisseur utilise une distinction entre facultatif (peut être absent) et nullable (présent mais peut être nul) en fonction des exemples de données JSON. Si une propriété apparaît dans certains objets mais pas dans d'autres de votre exemple de tableau, elle est marquée facultative avec le ? modificateur en TypeScript (adresse?: chaîne). Si une propriété contient parfois null, le type devient une union avec null (adresse: string / null|. Si une propriété est à la fois éventuellement présente ET peut être nulle lorsqu'elle est présente, elle devient address?: chaîne / null. Pour les projets utilisant des vérifications null strictes dans tsconfig.json (fortement recommandé), ces distinctions sont cruciales: les propriétés facultatives doivent être vérifiées avec if (obj.adresse) ou chaînage facultatif (obj.adresse?.city), tandis que les propriétés non facultatives nullables doivent être vérifiées même lorsque la propriété est définitivement présente dans l'objet.

Oui, vous pouvez coller plusieurs objets JSON dans un tableau pour aider le convertisseur à détecter les variations. Lorsque vous fournissez plusieurs exemples: les propriétés présentes dans tous les objets sont marquées comme requises, les propriétés présentes dans certains objets seulement sont marquées comme facultatives avec ?, les propriétés avec différents types à travers les échantillons sont marquées avec des types d'union, et les types d'éléments de tableau sont déterminés à partir de tous les éléments de tous les échantillons plutôt que d'un seul. Par exemple, avec un échantillon {name: string, age: number} vous obtenez tous les champs obligatoires; avec deux échantillons où l'un a {name: string, email: string} et l'autre {name: string, phone: string}, le convertisseur produit name: string (obligatoire), email?: chaîne (facultatif), téléphone?: chaîne (facultatif). Ceci est particulièrement utile pour les API où différents points de terminaison ou conditions de réponse renvoient différents sous-ensembles de champs.

Les types générés peuvent être utilisés avec des bibliothèques clientes HTTP pour des appels d'API de type sécurisé. Avec fetch: définissez le type de réponse et utilisez la réponse await.json () comme ApiResponseType. Avec axios: utilisez des génériques comme axios.obtenez<ApiResponseType>(url). Avec React Query ou SWR: passez le type au crochet useQuery<ApiResponseType>(clé, récupérateur). Avec le codegen GraphQL: les types générés peuvent servir de base à vos types de schéma GraphQL. Après avoir copié les types dans votre projet, vous obtenez: des erreurs de compilation si vous accédez à des propriétés inexistantes sur les réponses de l'API, l'auto-complétion IDE pour tous les champs de réponse avec une documentation en ligne, une refactorisation sécurisée par type( renommer un champ une fois et toutes les utilisations mises à jour), et la confiance qui correspond à la structure réelle de l'API. N'oubliez pas de mettre à jour vos types lorsque l'API change — le convertisseur rend cela rapide en collant simplement le dernier exemple JSON.