JSON a TypeScript: genera interfacce accurate da dati API reali

Il bug che alla fine mi ha fatto smettere di scrivere a mano i tipi di API era imbarazzantemente piccolo Un endpoint di pagamenti restituito discount: null per i clienti senza uno, e l'avevo digitato discount: number perché l'unica risposta che ho guardato mentre scrivevo l'interfaccia era un cliente con uno sconto TypeScript era perfettamente felice Il compilatore non aveva modo di conoscere I & #39; ci ha mentito Tre settimane dopo a .toFixed(2) in quel campo la produzione è stata destinata esattamente al sottoinsieme di utenti che contavano meno per i miei test e più per la fattura.

Questo è l'intero problema con la digitazione manuale di un'API: digiti quello che vuoi credere l'endpoint ritorna e il compilatore impone diligentemente la tua convinzione piuttosto che la realtà. Ogni garanzia che TypeScript ti offre a valle è valida solo quanto quella prima interfaccia scritta a mano, e non c'è nulla nella catena degli strumenti che la controlli rispetto a una risposta effettiva. Ottieni tutta la cerimonia della digitazione statica senza alcuna sicurezza, il che è probabilmente peggiore di nessun tipo: almeno il codice non tipizzato ti rende sospettoso.

Generare tipi da un payload reale capovolge la direzione Invece di descrivere quale pensi sia la forma, prendi una risposta che il server ha effettivamente inviato e ne ricavi la forma L'output è meccanico: nessun ottimismo, nessun campo che hai dimenticato esistesse, nessun number dove dicono i dati number | null. Costruisco [Toolz.dev](/e metto un browser-based Convertitore da JSON a TypeScript questo fa questo, ma questa guida riguarda le regole di inferenza stesse: cosa può capire un generatore, cosa può solo indovinare e dove devi ancora pensare.

tl; dr: Per convertire JSON in TypeScript, deduci ogni tipo di chiave 's dal suo valore (string, number, boolean, null), estrarre gli oggetti nidificati nelle proprie interfacce con nome e unire gli array di oggetti in un'interfaccia a elemento singolo in cui qualsiasi chiave mancante da alcuni membri diventa opzionale Decidere deliberatamente se null mezzi key?: T oppure key: T | null- tale scelta dipende dal fatto che la tua API ometta campi assenti o li invii come nulli L'inferenza riflette solo il campione fornito, quindi utilizza un payload rappresentativo con diversi record e tratta l'output come una prima bozza rivista piuttosto che come un contratto finito.

Perché generare tipi TypeScript da JSON invece di scriverli?

La risposta onesta è che i tipi scritti a mano vanno alla deriva e i tipi generati don' t. Quando il backend aggiunge un campo, la tua interfaccia scritta a mano rimane silenziosamente sbagliata; niente errori, perché le proprietà extra in una risposta sono invisibili a un tipo che fa' t menzionarli Quando il backend cambia id da un numero a una stringa, la tua interfaccia continua a insistere su it's un numero e TypeScript continua a concordare, fino a quando qualcosa non si concatena invece di aggiungere.

There's anche il semplice argomento tedio Una tipica risposta REST ha trenta chiavi su quattro livelli di annidamento Trascrivendo che a mano richiede dieci minuti di puro lavoro meccanico, e il lavoro meccanico eseguito dagli esseri umani ha un tasso di difetti Si digiterà un nome chiave Ti mancherà l'unico campo che's una matrice di oggetti piuttosto che una matrice di stringhe Il generatore non lo farà.

Ma la ragione più forte è che la generazione fa la forma visibile. Incolla una risposta in un convertitore e vedi immediatamente le cose che tu' ho sorvolato sulla lettura grezza di JSON: quello metadata è in realtà un oggetto profondamente annidato, quello tags a volte è vuoto, che metà delle chiavi nella tua lista impaginata mancano da alcuni record L'interfaccia generata è un riepilogo della struttura reale di data's, e leggerla è spesso il modo più veloce per capire un endpoint che hai fatto' t write. I' l'ho usata come passaggio di documentazione più di una volta su API i cui documenti erano una bugia.

Dove questo si adatta agli altri tuoi strumenti di dati: se tu' stai ispezionando il carico utile anziché digitarlo, il Formattatore JSON è la prima fermata migliore e se tu' confronti due risposte per vedere cosa è cambiato tra le versioni, il JSON DIFF risponde direttamente.

Come funziona effettivamente l'inferenza del tipo da JSON?

JSON ha sei tipi di valore, per RFC 8259: oggetto, matrice, stringa, numero, true/false, e null. TypeScript's tipi primitivi mappa su quattro di quelli quasi direttamente L'opera interessante è interamente negli altri due.

I primitivi sono banali. Un valore stringa implica string. Un numero implica number- tieni presente che JSON ha un tipo numerico, quindi non c'è alcuna informazione nei dati che ti dica se 1 è un numero intero o un float e TypeScript lo fa' comunque distingui. true oppure false sottigliezza boolean. Questa parte non ha ambiguità.

Gli oggetti diventano interfacce. Ogni valore dell'oggetto diventa un'interfaccia con nome e la chiave sotto cui appariva fornisce il nome, convertito in PascalCase Una chiave owner produce interface Owner. Il nesting ricorre: un oggetto all'interno di un oggetto produce una seconda interfaccia referenziata dalla prima Questo conta più di quanto sembri L'alternativa - inlining ogni forma annidata in modo anonimo - produce una singola dichiarazione illeggibile e non ti dà nulla di importabile:

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

Una volta Owner esiste come nome, una funzione che richiede solo il proprietario può essere digitata (owner: Owner) => void. Con la versione inlined you' starebbe scrivendo Project['owner'] ovunque, che funziona ma legge male.

Gli array sono dove vivono le vere decisioni. Un tipo array's è l'unione dei suoi tipi di elementi, quindi [1, 2, 3] dà number[] e [1, "a"] dà (number | string)[]. Nota le parentesi in quella seconda - senza di esse, number | string[] significa qualcosa di completamente diverso (un numero oppure una serie di stringhe) e generatori che dimenticano questo emettono codice che compila ma descrive la cosa sbagliata.

Gli array vuoti sono un vicolo cieco onesto. "tags": [] ti dice che una chiave esiste e contiene un array; non ti dice nulla su ciò che contiene L'output corretto è unknown[], e dovresti leggerlo come il generatore che rifiuta di indovinare piuttosto che come risposta finita. Riempilo da solo dalla documentazione o trova un campione in cui l'array è & #39; t vuoto.

Perché gli array di oggetti vengono uniti invece che uniti?

Questa è l'unica decisione che separa un generatore che tu'd utilizzare da uno you'd abbandonare dopo cinque minuti.

Consideriamo una risposta impaginata in cui i record sono & #39;t perfettamente uniforme - vale a dire, ogni risposta impaginata reale:

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

Tratta ogni elemento in modo indipendente e ottieni un'unione di due interfacce: rows: (Row1 | Row2)[]. Questo è tecnicamente la lettura più accurata del campione, ed è inutile Ogni accesso a row.nickname ora richiede un restringimento, perché TypeScript can' t sapere quale membro del sindacato hai Estendilo a una risposta di cinquanta record con diversi campi opzionali e ottieni un'unione di dozzine di interfacce quasi identiche Nessuno lo vuole.

La lettura utile è che questi due oggetti sono due istanze di un'entità e nickname è un campo che Grace fa't ha:

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

interface T {
  rows: Row[]
}

That's a merge: raccogli ogni chiave vista su tutti gli elementi, e contrassegna una chiave opzionale se it's assente da uno qualsiasi di essi Corrisponde a come i dati vengono effettivamente prodotti - una tabella di database, un serializzatore, alcune colonne nullabili - e produce tipi che puoi usare senza cerimonia Anche il nome dell'elemento array è singolarizzato, quindi releases rese Release anziché Releases, perché releases: Releases[] si legge come un bug anche quando è't.

Il compromesso è reale e vale la pena affermarlo chiaramente: l'unione presuppone che l'array sia omogeneo. Se si dispone di un array veramente eterogeneo, un feed di eventi con forme diverse, discriminati da a type campo - fondendo appiattisce varianti distinte in un'unica interfaccia in cui quasi tutto è opzionale That' è il modello sbagliato, e it' è un caso in cui dovresti prendere l'output generato come punto di partenza e scrivere a mano un'unione discriminata corretta I generatori don' t conoscono il tuo dominio Questo fonde oggetti e unisce tutto il resto, il che è giusto la maggior parte delle volte e sbagliato in un modo che puoi individuare immediatamente.

Null dovrebbe diventare una chiave opzionale o un membro del sindacato?

Entrambe le convenzioni sono difendibili e la differenza morde, quindi decidi di proposito piuttosto che accettare qualunque cosa il tuo strumento sia predefinito.

Dato { "retiredAt": null }, ci sono due letture:

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

Non sono intercambiabili In A, retiredAt è string | undefined e la chiave potrebbe non esistere affatto sull'oggetto In B, la chiave esiste sempre, e il suo valore potrebbe essere null. Sotto strictNullChecks- quale Manuale TypeScript consiglia e cosa dovresti indossare: entrambi ti costringono a gestire il caso assente, ma impongono controlli diversi e si serializzano in modo diverso. JSON.stringify omette undefined proprietà interamente ed emette null per quelli nulli, quindi la scelta si propaga fino al filo.

La risposta giusta dipende dal comportamento effettivo di API's, che nessun generatore può vedere da un campione:

Il tuo comportamento API's	Modello corretto	perché
Omette la chiave quando c'è' non ha valore	key?: T	La chiave è veramente & #39; t lì; opzionale è accurato
Invia sempre la chiave, null quando vuoto	key: T | null	La chiave è sempre presente; ? permetterebbe erroneamente l'assenza
Inconsistente - a volte omesso, a volte nullo	key?: T | null	Entrambi i casi sono reali; modella entrambi
Invio null solo sulle risposte agli errori	Nessuno dei due: modella l'errore separatamente	Un campo annullabile nasconde un'unione di forme di risposta

Quell'ultima riga è quella su cui vale la pena soffermarsi Un campo che diventa nullo solo nei casi di fallimento è un segnale che l'endpoint restituisce due cose diverse indossando una forma e la correzione è un'unione discriminata su un campo di stato, non una proprietà annullabile. La generazione del tipo fa emergere questo modello; non lo risolve't.

Il convertitore predefinito su key?: T perché omesso-quando-assente è la convenzione più comune nelle API JSON I & #39; ho lavorato con, e perché si compone meglio con l'array fusione descritta sopra (una chiave mancante da alcuni record e una chiave che & #39;s null in alcuni record ottenere modellato allo stesso modo) Disattiva l'opzione e null resta invece nell'unione Nemmeno un trucco; scegli quello che fa effettivamente la tua API.

E le chiavi che sono & #39; t identificatori TypeScript validi?

Le chiavi oggetto JSON sono stringhe arbitrarie Nomi di proprietà TypeScript in un bare key: T posizione non sono - devono essere identificatori validi Così "content-type", "2fa", "user.name", e "" sono tutte le chiavi JSON legali che non possono essere scritte senza virgolette in un'interfaccia.

La correzione è quotata e it' non è una soluzione alternativa: i nomi delle proprietà citati sono normali TypeScript:

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

A tali proprietà si accede con la notazione tra parentesi (headers["content-type"]), che è leggermente più prolisso ma del tutto sicuro per i tipi. Nota che class does't ha bisogno di citazione: le parole riservate sono perfettamente legali come nomi proprietàanche se loro & #39; sono illegali come identificatori. La restrizione si applica solo laddove TypeScript si aspetta un identificatore, motivo per cui la stessa parola necessita di essere gestita quando diventa un'interfaccia nome di nome.

I nomi delle interfacce derivati da tali chiavi necessitano di più lavoro che di citazioni. 2fa PascalCases a 2fa, che può't avviare un identificatore, in modo da ottenere un prefisso. Due diversi oggetti nidificati entrambi sotto chiavi denominate owner entrambi vorrebbero esserlo Owner, quindi il secondo diventa Owner2. Questi sono dettagli poco affascinanti e loro' sono esattamente i dettagli che decidono se l'output generato viene compilato o necessita di quindici minuti di riparazione manuale prima di farlo. Il test a cui tengo il convertitore è semplice: incolla qualsiasi cosa valida e l'output dovrebbe essere compilato sotto strict senza modifiche.

Interfacce o alias di tipo?

Il generatore emette entrambi Le differenze pratiche sono strette ma reali, e la tua base di codice probabilmente ha già un'opinione codificata nella sua configurazione lint.

interface User {} supporta l'unione delle dichiarazioni: dichiara due volte lo stesso nome dell'interfaccia e TypeScript li combina. That' è essenziale per aumentare i tipi dalle librerie che fai' t controllare e una pistola ovunque, poiché due dichiarazioni non correlate con lo stesso nome si uniscono silenziosamente invece di commettere errori. Supportano anche le interfacce extends, che produce messaggi di errore leggermente migliori rispetto ai tipi di intersezione quando un vincolo fallisce.

type User = {} can' t unisci, che di solito è una funzionalità, e it's richiesto per qualsiasi cosa che sia & #39; t una forma di oggetto: unioni, tuple, tipi mappati, tipi condizionali Una radice che è & #39; t un oggetto JSON - un array di numeri, una stringa nuda - può essere espressa solo come alias, quindi type Nums = number[] è ciò che ottieni indipendentemente dall'impostazione.

Per i tipi di API generati verso cui mi propendo interface, soprattutto perché i messaggi di errore sono leggermente migliori e perché il rischio di fusione è teorico quando ogni nome vive in un file generato Ma questo è vicino a un lancio di moneta, e la coerenza con il codice circostante conta più dei meriti Se la tua configurazione ESLint ha @typescript-eslint/consistent-type-definitions imposta in entrambi i casi, abbinalo e smetti di pensarci.

In cosa questo è diverso da JSON Schema a TypeScript?

Questi risolvono problemi veramente diversi e vale la pena essere precisi, perché & quot;JSON a TypeScript" e & quot;JSON Schema a TypeScript" sono a una parola di distanza e spesso confusi.

JSON a TypeScript è la deduzione da un esempio. Input: un valore Il generatore osserva what' ss lì e generalizza Non può sapere se un campo è richiesto, se una stringa è vincolata a un enum, se un numero ha un minimo, o se l'unico campione che hai incollato è rappresentativo It's induzione da una singola osservazione, con tutto ciò che implica.

JSON Schema to TypeScript è la traduzione da una dichiarazione. Ingresso: a Schema JSON documento, che già indica i tipi, required array, enumerazioni, formati e vincoli Il generatore è & #39; t indovinare - it& #39; s traslitterare un contratto esistente in sintassi TypeScript. required mappe di proprietà non opzionali; UN enum mappe di un'unione letterale di stringa; oneOf mappe a un tipo di unione.

La regola segue direttamente: se esiste uno schema, usalo. Uno schema JSON, una specifica OpenAPI, a .proto file, o uno schema GraphQL è autorevole in un modo che una risposta campionata non è mai Inferenza è ciò che si raggiunge per quando non esiste schema - un endpoint interno non documentato, un'API di terze parti i cui docs sono stantii, un formato di file di configurazione che è cresciuto organicamente, un fixture you're test di scrittura contro il quale, in equità, descrive una grande frazione del JSON che ognuno di noi ha effettivamente a che fare.

There' è una via di mezzo degna di nota: usa l'inferenza a bootstrap, quindi mantenere a mano Generare l'interfaccia da una risposta reale per ottenere la forma e i nomi dei campi a destra, quindi modificarlo - stringere un string a un'unione letterale in cui conosci i valori consentiti, fissa un unknown[] il campione lasciato vuoto, divide un'interfaccia unita in un'unione discriminata corretta Il generatore esegue il 90% meccanico e si applica la conoscenza del dominio che strutturalmente non può avere.

Dove sbaglia l'inferenza?

Una lista breve e onesta Ognuno di questi è una limitazione dell'approccio, non un bug in un particolare strumento, e conoscerli è la differenza tra usare bene i tipi generati e scottarsi da loro.

I singoli campioni sottodeterminano il tipo. Un campo che's number nel tuo campione potrebbe essere null nel 5% dei record Un campo che's presenti in tutti e tre i record che hai incollato potrebbe essere facoltativo attraverso il set di dati completo L'inferenza riporta ciò che ha visto Incolla più record - idealmente una vera pagina di risultati piuttosto che un oggetto selezionato a mano - e gli optional diventano significativamente più accurati.

Le corde nascondono i loro veri tipi. i timestamp ISO, gli UUID, gli URL e gli indirizzi e-mail sono tutti giusti string a un parser JSON. "2026-07-16T09:00:00Z" è semanticamente una data; nulla nei dati lo dice Se il tuo codice base ha un marchio ISODateString digita, tu're sostituendola a mano.

I numeri perdono distinzioni di precisione. JSON's tipo di numero singolo significa un ID che's un numero intero a 64 bit sul server arriva come numero JavaScript e potrebbe già aver perso precisione prima che il tuo generatore lo veda - Number.MAX_SAFE_INTEGER è circa 9×10¹5, e Twitter notoriamente lo ha imparato nel modo più duro Se la tua API invia numeri interi grandi come stringhe, quello's perché, e il generato string è corretto.

I valori letterali assomigliano ai loro tipi generali. "status": "active" inferisce string, no "active" | "archived" | "pending". Il tipo più stretto è più utile e nessun campione può dimostrarlo Questo è il più comune hand-edit che faccio all'output generato.

I contenitori vuoti non dicono nulla. [] dà unknown[] e {} dà un'interfaccia vuota Entrambi sono il generatore di essere onesti.

Niente di tutto ciò rende l'inferenza non sicura: la rende a progetto di legge. Il flusso di lavoro che funziona è: generare, leggere attentamente l'output, correggere le quattro o cinque cose che sai che il campione potrebbe' t dire, commit. That' è ancora un ordine di grandezza più veloce e più accurato della trascrizione manuale di trenta chiavi, che è l'alternativa effettiva.

Il mio JSON viene caricato ovunque?

No, e questa è una categoria di strumenti in cui la domanda merita una risposta reale piuttosto che un badge.

Pensa a cosa's nel JSON you'd incolla in un generatore di tipi It's una risposta API, il che significa che contiene plausibilmente un token portante, un identificatore di sessione, un'e-mail del cliente, un ID utente interno, un livello di prezzo, un segreto webhook That's non ipotetico - it's il caso modale, perché il punto è che hai afferrato un vero risposta a digitare contro.

Qualsiasi convertitore lato server riceve necessariamente quel payload. Potrebbe non registrarlo e probabilmente lo fa' t, ma tu' stai estendendo la fiducia, non devi estenderlo e, a seconda dei dati, potresti creare un problema di conformità per un'attività che non ha alcuna attività che tocca una rete.

L'inferenza del tipo è puro calcolo su un valore analizzato Non ha bisogno di rete, nessun account, nessuna memoria Il convertitore su Toolz.dev è un poche centinaia di linee di TypeScript senza dipendenze in esecuzione nella scheda; il payload è una stringa JavaScript nel browser's memoria e rimane lì È possibile verificare questo modo il vostro'd verificare qualsiasi affermazione di questo tipo - aprire la scheda di rete e premere Genera, o spegnere il wifi e guardare continuare a funzionare Questo è lo stesso principio dietro ogni strumento sul sito, e I & #39;ve scritto sul motivo per cui è più ampiamente importante in perché gli strumenti basati su browser battono quelli lato server per i dati sensibili.

Un esempio lavorato

Qui & #39;s il campione con cui viene spedito l'utensile, che è deliberatamente costruito per esercitare ogni regola di cui sopra:

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

Con la radice nominata Project, che genera:

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
}

Leggi cosa è successo. owner è stato estratto nella propria interfaccia e indicato per nome. tags collassato a string[] perché ogni elemento era una stringa. releases unito i suoi due membri in uno solo Release- singolarizzato - e notes è diventato opzionale perché la seconda versione lo ha fatto't ne aveva uno. retiredAt divenne facoltativo perché il suo unico valore osservato era nullo.

E ora leggi cosa risolvi. retiredAt?: null è il generatore's onesto rapporto che non ha mai visto un valore non nullo, e it's inutile come tipo - you'd cambiarlo in retiredAt?: string perché lo sai' ha un timestamp quando presente Quella singola modifica è l'intera lezione: il generatore ha ottenuto la struttura a sette chiavi, il nesting, l'unione dell'array e l'opzionalità direttamente in un'unica pasta e ti ha lasciato con l'unica decisione che richiedeva di sapere cosa significa il campo.

FAQ

Come faccio a convertire JSON in un'interfaccia TypeScript?

Incolla il tuo JSON nel convertitore, imposta il nome del tipo root su qualunque sia la risorsa chiamata e premi Genera. Induce il tipo di ogni tasto, estrae oggetti nidificati nelle proprie interfacce denominate, unisce array di oggetti in un singolo tipo di elemento e restituisce codice che puoi copiare direttamente in un .ts file. Là' non si iscrive e non carica: l'inferenza viene eseguita nel tuo browser.

Cosa succede agli array di oggetti?

Loro' sono fusi in un'unica interfaccia che descrive un singolo elemento e la proprietà è digitata come un array di esso Qualsiasi chiave che appare in alcuni membri dell'array ma non in altri diventa opzionale Questo corrisponde a come si comportano i dati impaginati reali, dove i record provengono da una tabella e alcune colonne sono annullabili L'unico caso che gestisce male è un array genuinamente eterogeneo di diversi tipi di eventi, che dovresti convertire manualmente in un'unione discriminata.

Null dovrebbe diventare una chiave opzionale o un'unione con null?

Dipende se la tua API omette campi assenti o li invia come null Se li omette, key?: T è accurato Se la chiave è sempre presente e talvolta nulla, key: T | null è accurato e utilizzabile ? permetterebbe erroneamente che la chiave manchi. Il convertitore diventa opzionale e ti consente di passare, perché i due si serializzano in modo diverso JSON.stringify elimina le proprietà indefinite ma ne emette di nulle.

Può dedurre tipi accurati da un singolo campione JSON?

Ne deduce tipi accurati per quel campione, che è & #39; t la stessa cosa Un campo che & #39; s un numero nel tuo record unico potrebbe essere nullo in altri; un campo presente in tutti e tre i record che hai incollato potrebbe essere facoltativo nel set di dati completo Usa un payload rappresentativo con diversi record anziché un oggetto selezionato manualmente, e tratta l'output come una bozza rivista piuttosto che come un contratto finito.

Cosa' è la differenza tra JSON a TypeScript e JSON Schema a TypeScript?

Questo strumento deduce i tipi da un valore di esempio; JSON Schema to TypeScript traduce uno schema formale che dichiara già tipi, campi obbligatori ed enum. Lo schema è autorevole e l'inferenza è un'ipotesi, quindi se hai uno schema JSON, una specifica OpenAPI o uno schema GraphQL, usalo L'inferenza è per il caso molto comune in cui non esiste uno schema e tutto ciò che hai è un corpo di risposta.

Come gestisce le chiavi che sono & #39; t identificatori validi?

Le chiavi con trattini, punti, spazi o cifre iniziali sono citate nell'output, quindi "content-type" diventa "content-type": string. That's valido TypeScript, accessibile con la notazione a parentesi Parole riservate come class don' t bisogno di quotare come nomi di proprietà Nomi di interfaccia derivati da tali chiavi sono PascalCased e prefissato se loro' d iniziare con una cifra, e i nomi in collisione ottenere un suffisso numerico in modo che l'output sempre compila.

Devo generare interfacce o digitare alias?

Corrisponde a qualunque cosa faccia già il tuo codice base: questa è principalmente una questione di coerenza. Le interfacce supportano la fusione delle dichiarazioni e extends, e dare marginalmente messaggi di errore più chiari Tipo alias can' t unione, che di solito è desiderabile, e sono richiesti per tutto ciò che è' t una forma di oggetto Una radice che' s un array o una primitiva è emesso come alias in entrambi i casi, dal momento che there's nessun oggetto per cui dichiarare un'interfaccia per.

Il mio JSON è stato caricato su un server?

No. L'intero motore di inferenza funziona come JavaScript nel browser, senza chiamate di rete, senza registrazione e senza archiviazione Questo è importante qui più che per la maggior parte degli strumenti, perché il JSON you' d incolla in un generatore di tipi è di solito una vera risposta API contenente token, record dei clienti o ID interni Apri la scheda di rete durante la generazione o disconnettiti da Internet: continua a funzionare.

---

Strumenti correlati: Formattatore JSON Per prima ispezionare il carico utile, JSON a Yaml e JSON a XML per la conversione del formato e JSON DIFF per individuare ciò che è cambiato tra due risposte. Ulteriori letture: La guida definitiva agli strumenti JSON e La guida agli strumenti di codifica dello sviluppatore.