TypeScript-interfaces genereren vanuit JSON _

Hoe JSON-naar-TypeScript-inferentie werkt

Inferentie is een enkele doorgang over de geparseerde JSON-boom. De tool leest elke waarde, kiest er een TypeScript-type voor en schrijft vervolgens één interface per gevonden object.

1. Parseer het JSON-voorbeeld met de native parser van de browser en wijs misvormde invoer af met een regel/kolom-hint.
2. Stel een TypeScript-type vast voor elke waarde — string, number, boolean, null, array of genest object.
3. Geef elk genest object een interfacenaam afgeleid van de sleutel van de bovenliggende eigenschap (zodat user.address een Address-interface wordt).
4. Voeg itemtypes samen over elke array zodat een lijst van {id: 1} en {id: 2, label: "x"} een union met de juiste optionele velden oplevert.
5. Pas je opties toe (interface vs. type, readonly, optioneel-nullable) en zend declaraties uit in afhankelijkheidsvolgorde zodat het bestand compileert zonder voorwaartse verwijzingen.

Waarom TypeScript-types genereren vanuit JSON?

• De meeste shapebugs zijn afvangbaar tijdens compilatie als het responstype is opgeschreven. Een interface afleiden vanuit een echte payload schrijft het meeste voor je, en `strict`-modus pakt het veld op dat de documentatie vergat te vermelden.
• Afgeleide interfaces koppelen aan een runtime-validator zoals Zod of io-ts geeft dezelfde shape twee taken: editor-autocompletion tijdens ontwikkeling en een 400 aan de edge wanneer productie iets onverwachts stuurt.
• De taalserver van TypeScript toont alleen velden die hij kent. Zodra je de afgeleide interface importeert, werkt autocompletion op het moment dat je de punt typt — geen `as any`-cast meer op de respons en een gefrustreerde grep door de repo.
• Als je op het punt staat een OpenAPI-specificatie te schrijven, is een afgeleide interface een snel eerste concept van het responschema. Je wilt nog steeds handgeschreven voorbeelden en beperkingen, maar de eigendomsnamen en types zijn al correct.

Veelvoorkomende toepassingen

Inferentie helpt het meest wanneer een echte payload bestaat maar een schema niet.

• Externe webhook-payloads van Stripe, GitHub of Twilio typen vóór het schrijven van een handler.
• Types bootstrappen voor een interne REST API zodat het frontend-team op dezelfde dag kan beginnen te coderen als de backend gereed is.
• Een startpunt genereren voor een Zod-, io-ts- of Valibot-schema vanuit een waargenomen API-respons.

Hoe ziet de uitvoer eruit?

Gegeven een voorbeeld-JSON-document en een rootnaam produceert de generator een boom van interfaces, één per genest object. Voor de onderstaande invoer met rootnaam User:

Plak {"id":1,"name":"Alice","tags":["a","b"],"address":{"city":"Paris"}} met rootnaam User en de generator produceert:

export interface User {
  id: number;
  name: string;
  tags: string[];
  address: Address;
}

export interface Address {
  city: string;
}

Generatoropties

Declaratiestijl

Kies interface (de standaard TypeScript-idioom voor objectshapes) of type (handig als je later gemapte types, conditionele types of kruisingen nodig hebt). Beide produceren identiek runtimegedrag; de keuze is een codestijlvoorkeur.

Optionele null-bare velden

Wanneer een bemonsterde waarde null is, wordt het type van het veld T | null. Deze optie inschakelen voegt ook een ?-modifier toe zodat het veld optioneel is aan de TypeScript-kant — handig wanneer de API de sleutel soms volledig weglaat in plaats van null terug te sturen.

Readonly-modifier

Voegt readonly toe aan elke eigenschapsdeclaratie zodat de uitgestuurde interface een onveranderlijk datamodel matcht. Handig voor Redux-toestandsslices, bevroren API-reacties of overal waar je wilt dat de compiler toevallige mutatie markeert.

Ondersteunt dit geneste objecten en arrays?

Ja. Elk genest object wordt een benoemde interface afgeleid van de sleutel van de bovenliggende eigenschap, en arrays leiden het itemtype af uit hun inhoud. Arrays van objecten krijgen één interface per objectshape, met union-types waar de shapes niet overeenkomen.

Hoe worden optionele velden afgeleid?

Schakel de knop "Null-bare velden optioneel markeren" in en elk veld waarvan de bemonsterde waarde null is, krijgt een ?-modifier op de sleutel plus | null in het type. Zonder de knop blijft het veld verplicht en is het type gewoon T | null.

Ondersteunt dit gediscrimineerde unions?

Eenvoudige union-types komen eruit wanneer een array items van gemengde shape bevat of wanneer een veld zowel een waarde als null draagt. Volledige gediscrimineerde-union-inferentie (het kiezen van type of kind als tag en het splitsen van varianten) vereist meerdere voorbeelden — dat is gepland maar zit niet in de huidige versie.

Kan ik types afleiden uit meerdere JSON-voorbeelden?

Nog niet — de huidige infereerder leest één voorbeeld tegelijk. Als je twee payloads hebt die een interface moeten delen (zeg, een lijsteindpunt en een enkel-item-eindpunt), is de praktische oplossing ze samen te voegen in één array, daaruit te genereren en vervolgens de resulterende union-types te hernoemen. Meerdere-voorbeelden-inferentie staat op de roadmap omdat het de enige manier is om velden te detecteren die in één respons aanwezig zijn en in een andere ontbreken.

Plak een payload, noem de root, kopieer de interfaces. De volledige pipeline draait in je browser, zodat een niet-uitgebrachte API of een ondertekende webhook-body op je machine blijft.