100 % locale — i tuoi dati non lasciano mai il tuo browser

JSON in TypeScript — basta scrivere interfacce

Trasforma un campione JSON in interfacce TypeScript. Gli oggetti annidati ricevono un tipo con nome: un payload diventa un file da incollare e compilare.

Istantaneo Privato Zero cookie
Stile

Input JSON

Output TypeScript

Che cosa fa questo strumento

Un campione JSON diventa tipi TypeScript, un’interfaccia con nome per oggetto.

{ "id": 1, "name": "Ada", "address": { "city": "Paris" } }
export interface Root {
  id: number;
  name: string;
  address: Address;
}

export interface Address {
  city: string;
}

interface o type, esportato o no, e il nome della radice: li imposti tu.

Una lista alla radice ha finalmente un nome

Un array di oggetti è il campione più comune che ci sia: è ciò che restituisce un endpoint di elenco. L’uscita dava solo l’interfaccia dell’elemento:

export interface UsersItem {
  id: number;
}

e il nome radice che avevi scritto non andava da nessuna parte. Ora la lista stessa ha un nome:

export type Users = UsersItem[];

export interface UsersItem {
  id: number;
}

Era un difetto, trovato scrivendo questa pagina e corretto. I generatori Zod e io-ts di questo sito emettevano già la loro radice; TypeScript no.

Stesso nome, forma diversa

I nomi dei tipi vengono dalle chiavi: due rami possono volere entrambi Address. Quando le forme differiscono, la seconda diventa Address2 invece di fondersi in un tipo che non va bene per nessuna. Quando le forme sono identiche, una sola definizione è condivisa: un Address referenziato due volte.

Ciò che un campione non può dire

Nulla è segnato opzionale, ed è voluto: una chiave vista una volta dice che può comparire, non che compaia sempre. "nickname": null dà nickname: null, perché è tutto ciò che il campione contiene — allargalo tu a string | null quando lo saprai.

Un identificatore di venti cifre è tipato number, e un numero JavaScript non lo contiene: oltre 2^53 il valore cambia all’analisi. Il tipo non mente sul campione, eredita un limite del linguaggio: se il campo è un identificatore snowflake, mettilo string e tienilo fuori da JSON.parse.

Una chiave ripetuta è rifiutata

{"a": 1, "a": "x"} dava a: string, con l’ultima occorrenza che vinceva in silenzio. Due valori, una chiave, nessun modo di dire che tipo abbia il campo: la conversione ora si ferma e dichiara il documento ambiguo. È la stessa risposta che il validatore JSON di qui dava già allo stesso documento.

Privato per progettazione

Tutto viene eseguito localmente nel browser con JavaScript. I tuoi dati non vengono mai caricati, quindi lo strumento è sicuro per contenuti sensibili e funziona anche offline.

Domande frequenti

Perché nessun campo è opzionale?
Perché un documento non può dirlo. Una chiave presente prova che può esserci, non che ci sia sempre. Segnare tutto obbligatorio è almeno un’affermazione verificabile su un secondo campione; inventare un `?` sarebbe affermare qualcosa su dati che non hai mai mostrato allo strumento.
La mia lista di utenti ha prodotto solo `UsersItem`. Dov’è il tipo della lista?
Ora c’è. Un array alla radice dava solo l’interfaccia dell’elemento: bisognava scrivere `UsersItem[]` a mano, e il nome radice richiesto veniva ignorato in silenzio. L’uscita ora comincia con `export type Users = UsersItem[];`. Era un difetto vero, trovato scrivendo questa pagina.
Due oggetti diversi si chiamano entrambi `Address`. Che succede?
Il secondo diventa `Address2`. I nomi vengono dalle chiavi, e due chiavi di rami diversi possono portare lo stesso nome con forme diverse. Fonderle darebbe un tipo sbagliato per entrambe; il suffisso tiene onesta ciascuna, e forme identiche continuano a condividere una definizione.

Convertitori correlati