JSON naar TypeScript: genereer nauwkeurige interfaces van echte API-gegevens

De bug die me uiteindelijk deed stoppen met het handschrijven van API-types was beschamend klein Een betalingseindpunt keerde terug discount: null voor klanten zonder, en ik had het getypt discount: number want de enige reactie waar ik naar keek tijdens het schrijven van de interface was toevallig een klant met korting TypeScript was perfect blij De compiler had geen manier om I' d er tegen gelogen te weten Drie weken later a .toFixed(2) op dat veld werd de productie ingevoerd voor precies de subset van gebruikers die het minst belangrijk waren voor mijn tests en het meest voor de factuur.

Dat is het hele probleem met het met de hand typen van een API: je typt wat je believe het eindpunt keert terug, en de compiler dwingt plichtsgetrouw je overtuiging af in plaats van de realiteit Elke garantie die TypeScript je downstream geeft is slechts zo goed als die eerste handgeschreven interface, en er is niets in de toolchain dat het controleert op een daadwerkelijke reactie Je krijgt alle ceremonies van statisch typen zonder de veiligheid, wat aantoonbaar slechter is dan helemaal geen typen - in ieder geval ongetypeerde code maakt je verdacht.

Het genereren van types uit een echte payload draait de richting om In plaats van te beschrijven wat je denkt dat de vorm is, neem je een reactie die de server daadwerkelijk heeft verzonden en leid je de vorm daaruit af De uitvoer is mechanisch: geen optimisme, geen velden waarvan je vergeten bent dat ze bestonden, nee number waar de gegevens zeggen number | null. Ik bouw [Toolz.dev] (/en zet een browser-based JSON naar TypeScript-converter daar doet dat dit, maar deze gids gaat over de gevolgtrekkingsregels zelf - wat een generator kan uitzoeken, waar hij alleen maar naar kan raden en waar je nog moet nadenken.

tl;dr: Om JSON naar TypeScript te converteren, leidt u elke toets af en #39; s typt u uit de waarde ervan (string, number, boolean, null), extraheer geneste objecten in hun eigen benoemde interfaces, en voeg arrays van objecten samen in een interface met één element waar elke sleutel die ontbreekt bij sommige leden optioneel wordt. Bepaal opzettelijk of null inkomsten key?: T of key: T | null- die keuze hangt af van het feit of uw API afwezige velden weglaat of als nul verzendt. Inferentie weerspiegelt alleen het monster dat u verstrekt, dus gebruik een representatieve payload met verschillende records en behandel de uitvoer als een beoordeeld eerste concept in plaats van als een voltooid contract.

Waarom TypeScript-typen genereren van JSON in plaats van ze te schrijven?

Het eerlijke antwoord is dat handgeschreven types driften en gegenereerde types don' t. Wanneer de backend een veld toevoegt, blijft je handgeschreven interface stil fout; niets fouten, want extra eigenschappen in een reactie zijn onzichtbaar voor een type dat doet' ze niet vermeldt Wanneer de backend verandert id van een getal tot een tekenreeks, uw interface blijft erop aandringen ' is een getal en TypeScript blijft akkoord gaan, totdat er iets aaneenschakelt in plaats van toevoegt.

There' s ook het effen tedium argument Een typische REST reactie heeft dertig toetsen over vier niveaus van nesting Transcriberen dat met de hand kost tien minuten puur mechanisch werk, en mechanisch werk uitgevoerd door mensen heeft een defectpercentage Je zal een sleutelnaam typen Je zult het ene veld missen dat' is een array van objecten in plaats van een array van strings De generator zal dat niet doen.

Maar de sterkste reden is dat generatie de vorm maakt zichtbaar. Plak een reactie in een converter en je ziet meteen dingen die je ' had verdoezeld door het lezen van rauwe JSON: dat metadata is eigenlijk een diep genest object, dat tags is soms leeg, dat de helft van de sleutels in uw gepagineerde lijst ontbreken in sommige records De gegenereerde interface is een samenvatting van de gegevens' s echte structuur, en het lezen ervan is vaak de snelste manier om een eindpunt te begrijpen dat u hebt gedaan ' t schrijven. I ' heb het meer dan eens gebruikt als documentatiestap op API's waarvan de documenten een leugen waren.

Waar dit past naast uw andere datatools: als u ' de payload opnieuw inspecteren in plaats van deze te typen, de JSON-formatter is de betere eerste stop, en als je ' vergelijk twee reacties om te zien wat er tussen versies veranderde, de JSON-differentiatie antwoordt dat direct.

Hoe werkt type-inferentie van JSON eigenlijk?

JSON heeft zes waardetypen, per RFC 8259: object, array, string, nummer, true/false, en null. TypeScript's primitieve typen worden vrijwel direct op vier daarvan afgebeeld. Het interessante werk bevindt zich volledig in de andere twee.

Primitieven zijn triviaal. Een tekenreekswaarde impliceert string. Een getal impliceert number- merk op dat JSON één numeriek type heeft, dus there' bevat geen informatie in de gegevens die u vertelt of 1 is een geheel getal of een float, en TypeScript doet ' onderscheid toch niet. true of false impliceert boolean. Dit deel kent geen dubbelzinnigheid.

Objecten worden interfaces. Elke objectwaarde wordt een benoemde interface, en de sleutel die het verscheen onder levert de naam, omgezet naar PascalCase. Een sleutel owner produceert interface Owner. Het nestelen komt terug: een object binnenin een object produceert een tweede interface waarnaar wordt verwezen vanaf de eerste Dit doet er meer toe dan het klinkt Het alternatief - elke geneste vorm anoniem inlijnen - levert één enkele onleesbare verklaring op en geeft je niets importeerbaars:

// 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
}

Once Owner bestaat als een naam, een functie die alleen de eigenaar neemt, kan worden getypt (owner: Owner) => void. Met de inline versie schrijven jij ' zou schrijven Project['owner'] overal, wat werkt maar slecht leest.

Arrays zijn waar de echte beslissingen leven. Een array's-type is de vereniging van de elementtypen, dus [1, 2, 3] geeft number[] en [1, "a"] geeft (number | string)[]. Let op de haakjes in die tweede - zonder deze, number | string[] betekent iets heel anders (een getal of een reeks strings) en generatoren die deze vergeten, zenden code uit die compileert maar het verkeerde beschrijft.

Lege arrays zijn een eerlijke doodlopende weg. "tags": [] vertelt u dat er een sleutel bestaat en een array bevat; het vertelt u niets over wat erin zit De juiste uitvoer is unknown[], en je zou dat moeten lezen als de generator die weigert te raden in plaats van als een voltooid antwoord. Vul het zelf in uit documentatie, of zoek een voorbeeld waarbij de array is't leeg.

Waarom worden arrays van objecten samengevoegd in plaats van samengevoegd?

Dit is de enige beslissing die een generator scheidt die u ' gebruikt van één you'd na vijf minuten verlaten.

Beschouw een gepagineerd antwoord waarbij records zijn't perfect uniform - dat wil zeggen, elke echte gepagineerde reactie:

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

Behandel elk element onafhankelijk en je krijgt een vereniging van twee interfaces: rows: (Row1 | Row2)[]. Dit is technisch de meest nauwkeurige lezing van het monster, en het is nutteloos Elke toegang tot row.nickname nu is vernauwing nodig, want TypeScript can't weet welk lid van de vakbond je hebt Breid dat uit naar een vijftig-record antwoord met verschillende optionele velden en je krijgt een vereniging van tientallen bijna-identieke interfaces Niemand wil dat.

De nuttige lezing is dat deze twee objecten twee exemplaren van één entiteit zijn, en nickname is een veld Grace doesn't hebben

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

interface T {
  rows: Row[]
}

That' is een samenvoeging: verzamel elke sleutel die je over alle elementen ziet, en markeer een sleutel optioneel als deze ' afwezig is in een van hen. Het komt overeen met hoe de gegevens daadwerkelijk worden geproduceerd - één databasetabel, één serialiser, enkele vernietigbare kolommen - en het produceert typen die je zonder ceremonie kunt gebruiken. De naam van het array-element is ook enkelvoud, dus releases rendementen Release eerder Releases, omdat releases: Releases[] leest als een bug, zelfs als het is't.

De afweging is reëel en de moeite waard om duidelijk te zeggen: bij het samenvoegen wordt ervan uitgegaan dat de array homogeen is. Als je een werkelijk heterogene array hebt - een feed van gebeurtenissen met verschillende vormen, gediscrimineerd door a type veld - samenvoegen maakt verschillende varianten platter tot één interface waar bijna alles optioneel is Dat' is het verkeerde model, en het' is een geval waarin u de gegenereerde uitvoer als uitgangspunt moet nemen en met de hand een correct gediscrimineerde unie moet schrijven Generatoren don't ken uw domein Deze voegt objecten samen en verenigt al het andere, wat meestal goed en fout is op een manier die u onmiddellijk kunt herkennen.

Moet null een optionele sleutel of een vakbondslid worden?

Beide conventies zijn verdedigbaar en het verschil is bijt, dus beslis met opzet in plaats van te accepteren waar uw tool standaard naar toe gaat.

Gegeven { "retiredAt": null }, er zijn twee lezingen:

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

Ze zijn niet uitwisselbaar In A, retiredAt is string | undefined en de sleutel bestaat misschien helemaal niet op het object. In B, de sleutel bestaat altijd, en de waarde ervan kan dat ook zijn null. Onder strictNullChecks- welke de TypeScript-handboek aanbevelingen en die u zou moeten doen - beide dwingen u om de afwezige zaak te behandelen, maar ze dwingen verschillende controles af en serialiseren anders. JSON.stringify weglaat undefined eigenschappen volledig en emitteert null voor nul-en, dus de keuze plant zich helemaal terug naar de draad.

Het juiste antwoord hangt af van de API's feitelijk gedrag, dat geen enkele generator uit één monster kan zien:

Uw API's gedrag	Correct model	waarom
Laat de sleutel weg wanneer er' geen waarde is	key?: T	De sleutel is echt & # 39; t daar; optioneel is nauwkeurig
Stuurt altijd de sleutel, null wanneer leeg	key: T | null	De sleutel is altijd aanwezig; ? afwezigheid ten onrechte zou toestaan
Inconsistent - soms weggelaten, soms nul	key?: T | null	Beide gevallen zijn echt; model beide
Verzendt null alleen op foutreacties	Geen van beide - modelleer de fout afzonderlijk	Een nullabel veld verbergt een vereniging van antwoordvormen

Die laatste rij is degene die het waard is om op te pauzeren Een veld dat alleen in faalgevallen nul wordt, is een signaal dat het eindpunt twee verschillende dingen retourneert die één vorm dragen, en de fix is een gediscrimineerde unie op een statusveld, geen nullable eigenschap Typegeneratie komt dit patroon naar boven; het doet 't los het op.

De converter standaard naar key?: T omdat weggelaten-wanneer-afwezig is de meer gebruikelijke conventie in de JSON API's I & #39; hebben gewerkt met, en omdat het beter samenstelt met de array samenvoegen hierboven beschreven (een sleutel ontbreekt in sommige records en een sleutel die & #39; s null in sommige records worden gemodelleerd op dezelfde manier) Zet de optie uit en null blijft in plaats daarvan in de vakbond. Geen van beide is een truc; kies degene die uw API daadwerkelijk doet.

Hoe zit het met sleutels die zijn't geldige TypeScript-identificatoren?

JSON objecttoetsen zijn willekeurige tekenreeksen TypeScript-eigenschapsnamen in een kale key: T positie is dat niet - het moeten geldige identificatiegegevens zijn. Dus "content-type", "2fa", "user.name", en "" zijn alle legale JSON-sleutels die niet zonder aanhalingstekens in een interface kunnen worden geschreven.

De oplossing citeert, en het ' is geen oplossing - geciteerde eigendomsnamen zijn gewoon TypeScript:

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

Deze eigenschappen zijn toegankelijk met haakjesnotatie (headers["content-type"]), die iets uitgebreider is maar volledig typeveiliger Let op dat class doesn't hoeft te worden geciteerd: gereserveerde woorden zijn volkomen legaal als eigendomsnamen0, ook al zijn ze & #39; illegaal als identificatiegegevens De beperking is alleen van toepassing wanneer TypeScript een identificatie verwacht - daarom moet hetzelfde woord wel worden verwerkt wanneer het een interface wordt name.

Interfacenamen die van dergelijke sleutels zijn afgeleid, hebben meer werk nodig dan citeren. 2fa PascalCases naar 2fa, die kan't start een identificatie, dus het krijgt een voorvoegsel Twee verschillende geneste objecten beide onder sleutels genaamd owner zou het allebei willen zijn Owner, dus de tweede wordt Owner2. Dit zijn niet-glamoureuze details, en ze & # 39; zijn precies de details die beslissen of de gegenereerde uitvoer compileert of vijftien minuten handreparatie nodig heeft voordat dit gebeurt. De test waaraan ik de converter vasthoud is eenvoudig: plak alles wat geldig is, en de uitvoer moet worden gecompileerd onder strict zonder bewerkingen.

Interfaces of type aliassen?

De generator zendt ofwel uit De praktische verschillen zijn smal maar reëel, en je codebase heeft waarschijnlijk al een mening gecodeerd in zijn pluisconfiguratie.

interface User {} ondersteunt het samenvoegen van declaraties - declareer dezelfde interfacenaam twee keer en TypeScript combineert ze Dat' is essentieel voor het uitbreiden van typen uit bibliotheken die u don't-besturing en overal elders een voetgeweer, aangezien twee niet-gerelateerde declaraties met dezelfde naam stilletjes samenvoegen in plaats van fouten Interfaces ondersteunen ook extends, wat iets betere foutmeldingen oplevert dan intersectietypen wanneer een beperking mislukt.

type User = {} can't samenvoegen, wat meestal een functie is, en it's vereist voor alles wat is' t een objectvorm: unies, tupels, mapted types, voorwaardelijke types Een root die isn' t een JSON object - een array van getallen, een kale string - kan alleen worden uitgedrukt als een alias, dus type Nums = number[] is wat je krijgt, ongeacht de instelling.

Voor gegenereerde API-typen neig ik naar interface, meestal omdat de foutmeldingen marginaal beter zijn en omdat het samenvoegrisico theoretisch is wanneer elke naam in één gegenereerd bestand leeft Maar dit is dicht bij een muntje omdraaien, en consistentie met de omringende code is belangrijker dan de voordelen Als uw ESLint-configuratie dat heeft @typescript-eslint/consistent-type-definitions stel beide kanten op, match het en denk er niet meer over na.

Hoe verschilt dit van JSON Schema tot TypeScript?

Deze lossen echt verschillende problemen op en it's zijn het waard om nauwkeurig te zijn, omdat "JSON naar TypeScript" en "JSON Schema naar TypeScript" zijn één woord uit elkaar en vaak verward.

JSON naar TypeScript is een gevolgtrekking uit een voorbeeld. Invoer: een waarde De generator observeert wat' is daar en generaliseert Het kan niet weten of een veld nodig is, of een string beperkt is tot een enum, of een getal een minimum heeft, of dat het ene monster dat je hebt geplakt representatief is. It's inductie uit een enkele waarneming, met alles wat dat inhoudt.

JSON Schema to TypeScript is een vertaling van een declaratie. Invoer: a JSON Schema document, waarin al typen worden vermeld, required arrays, enums, formaten en beperkingen De generator is't gissen - it's translitereert een bestaand contract naar TypeScript-syntaxis. required kaarten naar niet-optionele eigenschappen; een enum kaarten naar een letterlijke unie van een string; oneOf kaarten naar een unietype.

De regel volgt direct als er een schema bestaat, gebruik het dan. Een JSON Schema, een OpenAPI spec, een .proto bestand, of een GraphQL-schema is gezaghebbend op een manier die een voorbeeldantwoord nooit is. Inferentie is waar u naar reikt als er geen schema bestaat: een ongedocumenteerd intern eindpunt, een API van derden waarvan de documenten verouderd zijn, een configuratiebestandsformaat dat organisch is gegroeid, een onderdeel waar u ' waartegen u tests schrijft. Wat eerlijk gezegd een groot deel van de JSON beschrijft waar iemand van ons daadwerkelijk mee te maken heeft.

There' is een middenweg die het vermelden waard is: gebruik gevolgtrekking naar bootstrap, dan met de hand onderhouden Genereer de interface uit een echte reactie om de vorm en de veldnamen goed te krijgen, bewerk het dan - draai een string naar een letterlijke unie waar je de toegestane waarden kent, fixeer een unknown[] de steekproef leeg gelaten, splitste een samengevoegde interface in een juiste gediscrimineerde unie De generator doet de mechanische 90% en je past de domeinkennis toe die het structureel niet kan hebben.

Waar haalt gevolgtrekking het verkeerd?

Een korte, eerlijke lijst. Elk van deze is een beperking van de aanpak, geen bug in een bepaald hulpmiddel, en als je ze kent, is dit het verschil tussen het goed gebruiken van gegenereerde typen en het verbranden ervan.

Enkele monsters bepalen het type te weinig. Een veld dat's number in uw monster kan dat zijn null in 5% van de records Een veld dat' s aanwezig in alle drie records die u geplakt hebt, kan optioneel zijn in de volledige dataset Inferentie rapporteert wat het zag Plak meer records - idealiter een echte pagina met resultaten in plaats van één handgepikt object - en de optionals worden betekenisvol nauwkeuriger.

Snaren verbergen hun echte types. ISO-tijdstempels, UUID's, URL's en e-mailadressen zijn allemaal rechtvaardig string naar een JSON-parser. "2026-07-16T09:00:00Z" is semantisch een datum; niets in de gegevens zegt het. Als uw codebase een merk heeft ISODateString type, u' Ik vervang het met de hand.

Getallen verliezen precisieonderscheid. JSON's single number type betekent een ID that's een 64-bit integer op de server arriveert als een JavaScript nummer en kan al precisie verloren hebben voordat uw generator het ooit ziet - Number.MAX_SAFE_INTEGER is ongeveer 9×10¹5, en Twitter heeft dit op beroemde wijze op de harde manier geleerd Als uw API grote gehele getallen als tekenreeksen verzendt, dan zal ' waarom, en de gegenereerde string klopt.

Letterlijke waarden lijken op hun algemene typen. "status": "active" afleidt string, niet "active" | "archived" | "pending". Het smallere type is nuttiger en geen enkel monster kan het bewijzen. Dit is de meest voorkomende handbewerking die ik maak om output te genereren.

Lege containers zeggen niets. [] geeft unknown[] en {} geeft een lege interface Beide zijn de generator eerlijk.

Niets van dit alles maakt gevolgtrekkingen onveilig - het maakt het tot een ontwerp. De workflow die werkt is: genereer, lees de uitvoer zorgvuldig, repareer de vier of vijf dingen waarvan u weet dat de steekproef kon & # 39; zeg, commit. Dat en # 39; is nog steeds een orde van grootte sneller en nauwkeuriger dan het met de hand transcriberen van dertig sleutels, wat het daadwerkelijke alternatief is.

Wordt mijn JSON ergens geüpload?

Nee, en dit is een categorie van gereedschap waarbij de vraag een echt antwoord verdient in plaats van een badge.

Denk na over wat' s in de JSON you' d plakken in een type generator. It' s een API-antwoord, wat betekent dat het plausibel een dragertoken, een sessie-ID, een klant-e-mail, een interne gebruikers-ID, een prijsniveau, een webhook geheim bevat Dat' is niet hypothetisch - het' is het modale geval, omdat het hele punt is dat je een hebt gepakt daadwerkelijk reactie op type tegen.

Elke server-side converter ontvangt noodzakelijkerwijs die payload. Het kan zijn dat het niet logt, en dat doet het waarschijnlijk ook. 't, maar jij ' breidt het vertrouwen uit dat je don't moet uitbreiden, en afhankelijk van de gegevens creëer je mogelijk een complianceprobleem voor een taak waarbij je helemaal geen zaken hebt met het aanraken van een netwerk.

Type-inferentie is pure berekening over een geparseerde waarde Het heeft geen netwerk, geen account, geen opslag nodig De converter op Toolz.dev is een paar honderd regels afhankelijkheidsvrij TypeScript die in uw tabblad draaien; de payload is een JavaScript-tekenreeks in uw browser' s geheugen en het blijft daar U kunt dit verifiëren zoals u ' d een dergelijke claim verifieert - open het netwerktabblad en druk op Genereren, of schakel uw wifi uit en kijk hoe deze blijft werken Dit is hetzelfde principe achter elke tool op de site, en I' hebben geschreven over waarom het er breder toe doet waarom browsergebaseerde tools de serverzijde verslaan voor gevoelige gegevens.

Een uitgewerkt voorbeeld

Here' is het monster waarmee het gereedschap wordt geleverd, dat opzettelijk is geconstrueerd om elke bovenstaande regel uit te oefenen:

{
  "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 }
  ]
}

Met de wortel genaamd Project, dat genereert:

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
}

Lees wat er gebeurd is. owner werd in zijn eigen interface geëxtraheerd en met naam genoemd. tags ingestort tot string[] omdat elk element een string was. releases de twee leden samengevoegd tot één Release- singulariseerd - en notes werd optioneel omdat de tweede release ' Ik heb er een. retiredAt werd optioneel omdat de enige waargenomen waarde nul was.

En lees nu wat jij'd fix. retiredAt?: null is de generator's eerlijk rapport dat het nog nooit een niet-nulwaarde heeft gezien, en het's nutteloos als type - jij'd verander het in retiredAt?: string omdat je het weet ' is een tijdstempel als deze aanwezig is Die enkele bewerking is de hele les: de generator kreeg de structuur met zeven toetsen, het nestelen, het samenvoegen van de array en de optionaliteit in één pasta, en liet je achter met de enige beslissing die vereiste dat je wist wat het veld betekent.

FAQ

Hoe converteer ik JSON naar een TypeScript-interface?

Plak uw JSON in de converter, stel de naam van het stamtype in op hoe de bron ook wordt aangeroepen en druk op Genereren. Het leidt het type van elke toets af, trekt geneste objecten naar hun eigen benoemde interfaces, voegt arrays van objecten samen tot één enkel elementtype en voert code uit die u rechtstreeks naar een kunt kopiëren .ts bestand. There's geen aanmelding en geen upload - de gevolgtrekking wordt uitgevoerd in uw browser.

Wat gebeurt er met arrays van objecten?

Zij' worden samengevoegd tot één interface die een enkel element beschrijft, en de eigenschap wordt getypt als een array ervan Elke sleutel die in sommige arrayleden voorkomt, maar in andere niet, wordt optioneel Dit komt overeen met hoe echte gepagineerde gegevens zich gedragen, waarbij records uit één tabel komen en sommige kolommen nietig zijn. Het enige geval dat slecht wordt afgehandeld is een werkelijk heterogene reeks van verschillende gebeurtenistypen, die je met de hand moet omzetten in een gediscrimineerde unie.

Moet null een optionele sleutel worden of een unie met null?

Het hangt ervan af of uw API afwezige velden weglaat of als nul verzendt Als het ze weglaat, key?: T is nauwkeurig Als de sleutel altijd aanwezig is en soms nul, dan key: T | null is nauwkeurig en gebruikt ? zou ten onrechte toestaan dat de sleutel ontbreekt De converter is standaard optioneel en laat u schakelen, omdat de twee anders serialiseren - JSON.stringify laat ongedefinieerde eigenschappen vallen, maar zendt nul-eigenschappen uit.

Kan het nauwkeurige typen afleiden uit een enkel JSON-monster?

Het leidt nauwkeurige typen af voor dat monster, wat is't hetzelfde. Een veld dat' een getal in uw ene record kan in andere nul zijn; een veld dat aanwezig is in alle drie de records die u hebt geplakt, kan optioneel zijn in de volledige dataset. Gebruik een representatieve payload met verschillende records in plaats van één met de hand uitgekozen object, en behandel de uitvoer als een beoordeeld concept in plaats van als een voltooid contract.

Wat' Is het verschil tussen JSON naar TypeScript en JSON Schema naar TypeScript?

Deze tool leidt typen af uit een voorbeeldwaarde; JSON Schema naar TypeScript vertaalt een formeel schema dat al typen, verplichte velden en opsommingen declareert Het schema is gezaghebbend en gevolgtrekking is een gok, dus als je een JSON Schema, een OpenAPI-specificatie of een GraphQL-schema hebt, gebruik het dan Inferentie is voor het zeer gebruikelijke geval waarin geen schema bestaat en het enige dat je hebt een antwoordlichaam is.

Hoe gaat het om met sleutels die geldig zijn't identifiers?

Sleutels met streepjes, stippen, spaties of leidende cijfers worden in de uitvoer vermeld, dus "content-type" HALD "content-type": string. That's geldige TypeScript, toegankelijk met haakjesnotatie Gereserveerde woorden zoals class don't moet worden geciteerd als eigenschap namen Interfacenamen afgeleid van dergelijke sleutels zijn PascalCased en voorafgegaan als ze'd beginnen met een cijfer, en botsende namen krijgen een numeriek achtervoegsel zodat de uitvoer altijd compileert.

Moet ik interfaces genereren of aliassen typen?

Match wat uw codebase al doet - dit is meestal een consistentievraag Interfaces ondersteuning declaratie samenvoegen en extends, en geef marginaal duidelijkere foutmeldingen Type aliassen can't samenvoegen, wat meestal wenselijk is, en vereist zijn voor alles wat is't een objectvorm. Een root that's een array of een primitief wordt hoe dan ook als alias uitgezonden, aangezien there' geen object is om een interface voor te declareren.

Is mijn json geüpload naar een server?

Nee. De hele inferentie-engine draait als JavaScript in uw browser, zonder netwerkaanroepen, geen logboekregistratie en geen opslag. Dit is hier belangrijker dan voor de meeste tools, omdat de JSON you'd-plak in een typegenerator meestal een echt API-antwoord is dat tokens, klantgegevens of interne ID's bevat. Open uw netwerktab tijdens het genereren of verbreken van internet - het blijft werken.

---

Verwante hulpmiddelen: JSON-formatter Om eerst de laadstroom te inspecteren, json naar yaml en JSON naar XML voor formaatconversie en JSON-differentiatie Om te spotten wat er veranderde tussen twee reacties. Verder lezen: De ultieme gids voor JSON-tools en De handleiding voor codeerhulpmiddelen voor ontwikkelaars.