Command Palette

Search for a command to run...

JSON a TypeScript: Genere interfaces precisas a partir de datos de API reales

JSON a TypeScript: Genere interfaces precisas a partir de datos de API reales

T
Toolz Team
|Jul 21, 2026|24 Min Lectura

Parte de la colección Herramientas de datos

JSON a mecanografiado

Genere interfaces TypeScript a partir de cualquier ejemplo de JSON. Infiere tipos anidados, combina matrices de objetos en una única interfaz, marca las teclas anulables y faltan de forma opcional y emite código limpio exportable. 100% del lado del cliente.

Usar JSON a mecanografiado

El error que finalmente me hizo dejar de escribir a mano tipos de API fue vergonzosamente pequeño. Se devolvió un punto final de pagos discount: null para clientes sin uno, y lo había escrito discount: number porque la única respuesta que miré mientras escribía la interfaz resultó ser un cliente con descuento. TypeScript estaba perfectamente contento. El compilador no tenía forma de saberlo ' le mintió. Tres semanas después a .toFixed(2) en ese campo se puso en producción exactamente para el subconjunto de usuarios que menos importaban para mis pruebas y más para la factura.

Ese es el problema de escribir una API a mano: escribes lo que escribes creer el punto final regresa y el compilador hace cumplir obedientemente su creencia más que la realidad. Cada garantía que TypeScript le ofrece en sentido descendente es tan buena como la primera interfaz escrita a mano, y no hay nada en la cadena de herramientas que lo compare con una respuesta real. Obtienes toda la ceremonia de escritura estática sin nada de seguridad, lo que posiblemente sea peor que ningún tipo: al menos el código sin tipo te hace sospechar.

Generar tipos a partir de una carga útil real cambia la dirección. En lugar de describir cuál cree que es la forma, toma una respuesta que el servidor realmente envió y deriva la forma de ella. La salida es mecánica: no hay optimismo, no existen campos que hayas olvidado, no number donde dicen los datos number | null. Construyo [Toolz.dev](/ y pongo un navegador basado en Convertidor JSON a TypeScript eso hace esto, pero esta guía trata sobre las reglas de inferencia en sí mismas: qué puede descubrir un generador, qué sólo puede adivinar y dónde todavía hay que pensar.

TL;Dr: Para convertir JSON a TypeScript, infiera cada clave y tipo #39;s a partir de su valor (string, number, boolean, null), extraiga objetos anidados en sus propias interfaces con nombre y fusione matrices de objetos en una interfaz de un solo elemento donde cualquier clave que falte en algunos miembros se vuelva opcional. Decidir deliberadamente si null dinero a pagar key?: T investigaciones operacionales key: T | null- esa elección depende de si su API omite campos ausentes o los envía como nulos. La inferencia refleja solo la muestra que usted proporciona, así que use una carga útil representativa con varios registros y trate la salida como un primer borrador revisado en lugar de un contrato terminado.

¿por qué generar tipos TypeScript desde JSON en lugar de escribirlos?

La respuesta honesta es que los tipos escritos a mano se desvían y los tipos generados don't. Cuando el backend agrega un campo, su interfaz escrita a mano permanece silenciosamente incorrecta; nada falla, porque las propiedades adicionales en una respuesta son invisibles para un tipo que no lo hace'no los mencione. Cuando cambia el backend id de un número a una cadena, su interfaz sigue insistiendo en ello 's un número y TypeScript sigue estando de acuerdo, hasta que algo concatena en lugar de suma.

Allí 's también el argumento del tedio simple. Una respuesta REST típica tiene treinta claves en cuatro niveles de anidamiento. Transcribir eso a mano requiere diez minutos de trabajo mecánico puro, y el trabajo mecánico realizado por humanos tiene una tasa de defectos. Escribirás un nombre clave. Te perderás un campo que ' es una matriz de objetos en lugar de una matriz de cadenas. El generador no lo hará.

Pero la razón más fuerte es que la generación da forma visible. Pegue una respuesta en un convertidor e inmediatamente verá cosas que 'd ha pasado por alto leyendo JSON sin formato: eso metadata en realidad, es un objeto profundamente anidado tags a veces está vacío, ya que en algunos registros faltan la mitad de las claves de su lista paginada. La interfaz generada es un resumen de la estructura real de los datos ' y leerla suele ser la forma más rápida de comprender un punto final que no escribió 't. Yo y #39; Lo he usado como paso de documentación más de una vez en API cuyos documentos eran mentira.

Donde esto encaja con sus otras herramientas de datos: si usted 'está inspeccionando la carga útil en lugar de escribirla, el Formateador JSON es la mejor primera parada, y si usted & 39;Estamos comparando dos respuestas para ver qué cambió entre versiones, la Diferencia de JSON responde eso directamente.

¿cómo funciona realmente la inferencia de tipos de JSON?

JSON tiene seis tipos de valores, por RFC 8259: objeto, matriz, cadena, número, true/falsey null. TypeScript' Los tipos primitivos se asignan a cuatro de ellos casi directamente. El interesante trabajo se encuentra íntegramente en los otros dos.

Los primitivos son triviales. Un valor de cadena implica string. Un numero implica number- tenga en cuenta que JSON tiene un tipo numérico, por lo que no hay información en los datos que le indique si 1 es un número entero o un flotante, y TypeScript no distingue 't de todos modos. true investigaciones operacionales false implica boolean. Esta parte no tiene ambigüedad.

Los objetos se convierten en interfaces. Cada valor de objeto se convierte en una interfaz con nombre y la clave bajo la que apareció proporciona el nombre, convertida a PascalCase. Una clave owner produce interface Owner. La anidación se repite: un objeto dentro de un objeto produce una segunda interfaz a la que se hace referencia desde la primera. Esto importa más de lo que parece. La alternativa, alinear cada forma anidada de forma anónima, produce una única declaración ilegible y no le da nada importable:

// 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 vez Owner existe como nombre, se puede escribir una función que toma solo el propietario (owner: Owner) => void. Con la versión en línea que estabas escribiendo Project['owner'] en todas partes, lo cual funciona pero se lee mal.

Las matrices son donde viven las decisiones reales. Un tipo array's es la unión de sus tipos de elementos, entonces [1, 2, 3] da number[] y [1, "a"] da (number | string)[]. Tenga en cuenta los paréntesis de ese segundo, sin ellos, number | string[] significa algo completamente diferente (un número investigaciones operacionales una serie de cadenas) y generadores que olvidan esto emiten código que compila pero describe algo incorrecto.

Las matrices vacías son un callejón sin salida honesto. "tags": [] le dice que existe una clave y que contiene una matriz; no le dice nada sobre lo que contiene. La salida correcta es unknown[], y deberías leerlo como el generador que se niega a adivinar en lugar de como una respuesta terminada. Llénelo usted mismo a partir de la documentación o encuentre una muestra donde la matriz esté 't vacía.

¿por qué las matrices de objetos se fusionan en lugar de unirse?

Esta es la única decisión que separa un generador you'd use de uno you'd abandone después de cinco minutos.

Considere una respuesta paginada donde los registros son 't perfectamente uniforme, es decir, cada respuesta paginada real:

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

Trata cada elemento de forma independiente y obtendrás una unión de dos interfaces: rows: (Row1 | Row2)[]. Asta este técnicamente la lectura más precisa de la muestra, y es inútil. Cada acceso a row.nickname ahora requiere estrechamiento, porque TypeScript puede ' No sé qué miembro del sindicato tienes. Extiende eso a una respuesta de cincuenta registros con varios campos opcionales y obtendrás una unión de docenas de interfaces casi idénticas. Nadie quiere eso.

La lectura útil es que estos dos objetos son dos instancias de una entidad, y nickname es un campo Grace no 't have:

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

interface T {
  rows: Row[]
}

That's una combinación: recopile todas las claves vistas en todos los elementos y marque una clave opcional si está ausente en cualquiera de ellos. Coincide con la forma en que se producen realmente los datos (una tabla de base de datos, un serializador, algunas columnas anulables) y produce tipos que puede usar sin ceremonia. El nombre del elemento de matriz también está singularizado, por lo que releases rendimientos Release más bien que Releases, porque releases: Releases[] se lee como un error incluso cuando es 't.

La compensación es real y vale la pena decirla claramente: la fusión supone que la matriz es homogénea. Si tiene una matriz genuinamente heterogénea, una fuente de eventos con diferentes formas, discriminados por a type campo: la fusión aplana distintas variantes en una interfaz donde casi todo es opcional. Eso' es el modelo equivocado, y es' es un caso en el que debes tomar la salida generada como punto de partida y escribir a mano una unión discriminada adecuada. Los generadores no lo hacen ' No conozco tu dominio. Este fusiona objetos y une todo lo demás, lo cual es correcto la mayor parte del tiempo y incorrecto de una manera que puedes detectar de inmediato.

¿null debería convertirse en una clave opcional o en un miembro del sindicato?

Ambas convenciones son defendibles y la diferencia muerde, así que decida a propósito en lugar de aceptar lo que sea que su herramienta incumpla.

Dado { "retiredAt": null }, hay dos lecturas:

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

No son intercambiables. En A, retiredAt es string | undefined y es posible que la clave no exista en absoluto en el objeto. En B, la clave siempre existe y su valor podría serlo null. Sub strictNullChecks- que el Manual de TypeScript recomienda y qué debería tener: ambos lo obligan a manejar el caso ausente, pero obligan a realizar diferentes comprobaciones y se serializan de manera diferente. JSON.stringify omite undefined propiedades íntegramente y emite null para los nulos, la elección se propaga hasta el cable.

La respuesta correcta depende del comportamiento real de API's, que ningún generador puede ver en una muestra:

Su comportamiento API's Modelo correcto porque
Omite la clave cuando está ahí 's sin valor key?: T La clave realmente es 't allí; opcional es preciso
Siempre envía la clave, null cuando está vacío key: T | null La clave siempre está presente; ? permitiría erróneamente la ausencia
Inconsistente - a veces omitido, a veces nulo key?: T | null Ambos casos son reales; modelar ambos
Envía null sólo en respuestas a errores Ninguno de los dos: modele el error por separado Un campo anulable oculta una unión de formas de respuesta

Esa última fila es aquella en la que vale la pena hacer una pausa. Un campo que se vuelve nulo sólo en casos de falla es una señal de que el punto final devuelve dos cosas diferentes que llevan una forma, y la solución es una unión discriminada en un campo de estado, no una propiedad anulable. La generación de tipos supera este patrón; no lo resuelve.

El convertidor establece de forma predeterminada key?: T debido a que omitir cuando está ausente es la convención más común en las API JSON con las que I' He trabajado y porque se compone mejor con la combinación de matrices descrita anteriormente (falta una clave en algunos registros y una clave que ' es nula en algunos registros se modelan de la misma manera). Desactive la opción y null en cambio, permanece en la unión. Ninguno de los dos es un truco; Elija el que realmente hace su API.

¿qué pasa con las claves que son identificadores TypeScript válidos 't?

Las claves de objetos JSON son cadenas arbitrarias. Nombres de propiedades TypeScript en un archivo desnudo key: T los puestos no lo son; tienen que ser identificadores válidos. Entonces "content-type", "2fa", "user.name"y "" son todas las claves JSON legales que no se pueden escribir sin comillas en una interfaz.

La solución es citar, y ' no es una solución alternativa: los nombres de propiedades citados son TypeScript ordinarios:

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

Se accede a esas propiedades con notación entre corchetes (headers["content-type"]), que es un poco más detallado pero completamente seguro para escribir. Tenga en cuenta eso class no es necesario citar ' No es necesario citar: las palabras reservadas son perfectamente legales como nombres de propiedades, aunque ellos'son ilegales como identificadores. La restricción solo se aplica cuando TypeScript espera un identificador, razón por la cual la misma palabra necesita manejo cuando se convierte en una interfaz nombre.

Los nombres de interfaces derivados de dichas claves necesitan más trabajo que citar. 2fa PascalCases a 2fa, que puede 't iniciar un identificador, por lo que obtiene un prefijo. Dos objetos anidados diferentes, ambos bajo claves nombradas owner ambos querrían serlo Owner, entonces el segundo se convierte Owner2. Estos son detalles poco glamorosos, y ellos ' son exactamente los detalles que deciden si la salida generada se compila o necesita quince minutos de reparación manual antes de que lo haga. La prueba a la que sostengo el convertidor es simple: pegar cualquier cosa válida y la salida debe compilarse debajo strict sin ediciones.

¿interfaces o alias de tipo?

El generador emite cualquiera de los dos. Las diferencias prácticas son estrechas pero reales, y su base de código probablemente ya tenga una opinión codificada en su configuración de pelusa.

interface User {} admite la fusión de declaraciones: declare el mismo nombre de interfaz dos veces y TypeScript los combine. Eso's esencial para aumentar los tipos de bibliotecas que no tienes't control, y un arma de pie en el resto, ya que dos declaraciones no relacionadas del mismo nombre se fusionan silenciosamente en lugar de generar errores. Las interfaces también son compatibles extends, que produce mensajes de error ligeramente mejores que los tipos de intersección cuando falla una restricción.

type User = {} can't fusionar, que suele ser una característica, y it's requerido para cualquier cosa que sea 't una forma de objeto: uniones, tuplas, tipos mapeados, tipos condicionales. Una raíz que es 't un objeto JSON - una matriz de números, una cadena simple - sólo se puede expresar como un alias, por lo que type Nums = number[] es lo que obtienes independientemente de la configuración.

Para los tipos de API generados me inclino interface, principalmente porque los mensajes de error son marginalmente mejores y porque el riesgo de fusión es teórico cuando cada nombre vive en un archivo generado. Pero esto está cerca de lanzar una moneda al aire, y la coherencia con el código circundante importa más que los méritos. Si su configuración ESLint lo tiene @typescript-eslint/consistent-type-definitions configúrelo de cualquier manera, combínelo y deje de pensar en ello.

¿en qué se diferencia esto de JSON Schema a TypeScript?

Estos resuelven problemas genuinamente diferentes y vale la pena ser preciso, porque "JSON a TypeScript" y "Esquema JSON a TypeScript" están separados por una palabra y se confunden con frecuencia.

JSON a TypeScript es una inferencia de un ejemplo. Entrada: un valor. El generador observa qué' está ahí y generaliza. No puede saber si se requiere un campo, si una cadena está restringida a una enumeración, si un número tiene un mínimo o si la muestra que pegó es representativa. It's inducción a partir de una sola observación, con todo lo que eso implica.

JSON Schema to TypeScript es la traducción de una declaración. Entrada: a Esquema JSON documento, que ya indica tipos, required matrices, enumeraciones, formatos y restricciones. El generador es 't adivinando - it's transliterando un contrato existente a la sintaxis TypeScript. required mapas de propiedades no opcionales; un enum mapas para una unión literal de cadena; oneOf mapas a un tipo de unión.

La regla sigue directamente: si existe un esquema, úselo. Un esquema JSON, una especificación OpenAPI, a .proto el archivo o esquema GraphQL tiene autoridad de una manera que nunca lo tiene una respuesta muestreada. La inferencia es a lo que busca cuando no existe ningún esquema: un punto final interno no documentado, una API de terceros cuyos documentos están obsoletos, un formato de archivo de configuración que creció orgánicamente, un elemento con el que usted & # 39; estamos escribiendo pruebas. Lo cual, para ser justos, describe una gran fracción del JSON con el que cualquiera de nosotros realmente trata.

There' es un camino intermedio que vale la pena mencionar: use inferencia para arranque, luego manténgalo a mano. Genere la interfaz a partir de una respuesta real para obtener la forma y los nombres de los campos correctos, luego edítela y apriete a string a una unión literal donde conoces los valores permitidos, fija un unknown[] la muestra se dejó vacía, se dividió una interfaz fusionada en una unión discriminada adecuada. El generador hace el 90% mecánico y se aplica el conocimiento del dominio que estructuralmente no puede tener.

¿Dónde se equivoca la inferencia?

Una lista breve y honesta. Cada uno de estos es una limitación del enfoque, no un error en una herramienta en particular, y conocerlos es la diferencia entre usar bien los tipos generados y quemarse con ellos.

Las muestras individuales subdeterminan el tipo. Un campo que's number en tu muestra podría estar null en el 5% de los registros. Un campo que 's presente en los tres registros que pegó podría ser opcional en todo el conjunto de datos completo. La inferencia informa lo que vio. Pegue más registros (idealmente una página real de resultados en lugar de un objeto seleccionado manualmente) y las opciones se vuelven significativamente más precisas.

Las cuerdas ocultan sus tipos reales. Las marcas de tiempo ISO, los UUID, las URL y las direcciones de correo electrónico son justas string a un analizador JSON. "2026-07-16T09:00:00Z" es semánticamente una fecha; nada en los datos lo dice. Si su código base tiene una marca ISODateString escribe, tú'lo sustituyremos a mano.

Los números pierden distinciones de precisión. JSON's tipo de número único significa un ID que's un número entero de 64 bits en el servidor llega como un número de JavaScript y es posible que ya haya perdido precisión antes de que su generador lo vea - Number.MAX_SAFE_INTEGER se trata de 9×10¹5, y Twitter aprendió esto de la manera más difícil. Si su API envía números enteros grandes como cadenas, eso y #39; es por qué y el generado string es correcto.

Los valores literales se parecen a sus tipos generales. "status": "active" infiere string, no "active" | "archived" | "pending". El tipo más estrecho es más útil y ninguna muestra puede demostrarlo. Esta es la edición manual más común que hago para generar resultados.

Los contenedores vacíos no dicen nada. [] da unknown[] y {} da una interfaz vacía. Ambos son el generador siendo honesto.

Nada de esto hace que la inferencia sea insegura, lo convierte en un borrador. El flujo de trabajo que funciona es: generar, leer la salida atentamente, arreglar las cuatro o cinco cosas que sabes que la muestra podría 't decir, comprometer. Eso ' Sigue siendo un orden de magnitud más rápido y preciso que transcribir treinta claves a mano, que es la alternativa real.

¿mi JSON se sube a alguna parte?

No, y esta es una categoría de herramienta donde la pregunta merece una respuesta real en lugar de una insignia.

Piense en qué's en el JSON usted'd pegar en un generador de tipos. It' es una respuesta API, lo que significa que posiblemente contenga un token portador, un identificador de sesión, un correo electrónico de cliente, una identificación de usuario interna, un nivel de precios, un secreto de webhook. Eso'no es hipotético - it' es el caso modal, porque el punto es que tomaste un fáctico respuesta al tipo en contra.

Cualquier convertidor del lado del servidor necesariamente recibe esa carga útil. Puede que no lo registre, y probablemente no lo haga 't, pero tú 'Estás extendiendo la confianza que no tienes 'Tienes que extender, y dependiendo de los datos, es posible que estés creando un problema de cumplimiento para una tarea que no tiene por qué tocar una red. en absoluto.

La inferencia de tipos es pura computación sobre un valor analizado. No necesita red, ni cuenta, ni almacenamiento. El convertidor en Toolz.dev tiene unos cientos de líneas de TypeScript sin dependencias que se ejecutan en su pestaña; la carga útil es una cadena JavaScript en su navegador y la memoria #39 y permanece allí. Puede verificar esto de la misma manera que usted & #39;d verificar cualquier reclamo de este tipo: abra la pestaña de red y presione Generar, o apague su wifi y observe cómo sigue funcionando. Este es el mismo principio detrás de cada herramienta en el sitio, y I' He escrito sobre por qué es más importante por qué las herramientas basadas en navegador superan a las del lado del servidor en cuanto a datos confidenciales.

Un ejemplo trabajado

Aquí 's la muestra con la que se envía la herramienta, que está construida deliberadamente para ejercer cada regla anterior:

{
  "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 raíz nombrada Project, asta 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
}

Lea lo que pasó. owner se extrajo en su propia interfaz y se hizo referencia a él por su nombre. tags colapsado a string[] porque cada elemento era una cadena. releases fusionó sus dos miembros en uno Release- singularizado - y notes se volvió opcional porque la segunda versión no tenía & # 39; no tengo uno. retiredAt se volvió opcional porque su único valor observado era nulo.

Y ahora lee lo que tú 'd arreglar. retiredAt?: null es el generador 's informe honesto que nunca ha visto un valor no nulo, y 's inútil como tipo - usted 'd cámbielo a retiredAt?: string porque lo sabes ' es una marca de tiempo cuando está presente. Esa edición única es la lección completa: el generador obtuvo la estructura de siete claves, el anidamiento, la combinación de matrices y la opcionalidad directamente en una sola pasta, y le dejó la única decisión que requería saber lo que significa el campo.

preguntasrán el

¿Cómo convierto JSON a una interfaz TypeScript?

Pegue su JSON en el convertidor, establezca el nombre del tipo raíz en cualquiera que sea el recurso y presione Generar. Infiere el tipo de cada clave, extrae objetos anidados en sus propias interfaces con nombre, fusiona matrices de objetos en un solo tipo de elemento y genera código que puede copiar directamente en un .ts archivo. Allí 's sin registro ni carga: la inferencia se ejecuta en su navegador.

¿Qué sucede con las matrices de objetos?

Ellos' se fusionan en una interfaz que describe un solo elemento y la propiedad se escribe como una matriz del mismo. Cualquier clave que aparezca en algunos miembros de la matriz pero no en otros se vuelve opcional. Esto coincide con el comportamiento real de los datos paginados, donde los registros provienen de una tabla y algunas columnas son anulables. El único caso que maneja mal es una matriz genuinamente heterogénea de diferentes tipos de eventos, que debes convertir a mano en una unión discriminada.

¿debería nulo convertirse en una clave opcional o una unión con nulo?

Depende de si su API omite campos ausentes o los envía como nulos. Si los omite, key?: T es exacto. Si la clave está siempre presente y a veces nula, key: T | null es preciso y está usando ? permitiría erróneamente que faltara la clave. El convertidor se vuelve opcional y le permite cambiar, porque los dos se serializan de manera diferente JSON.stringify elimina propiedades indefinidas pero emite propiedades nulas.

¿puede inferir tipos precisos a partir de una única muestra JSON?

Infiere tipos precisos para esa muestra, que es 't lo mismo. Un campo que ' un número en su registro puede ser nulo en otros; un campo presente en los tres registros que pegó podría ser opcional en todo el conjunto de datos completo. Utilice una carga útil representativa con varios registros en lugar de un objeto seleccionado cuidadosamente y trate el resultado como un borrador revisado en lugar de un contrato terminado.

¿cuál y#39; ¿La diferencia entre JSON y TypeScript y JSON Schema y TypeScript?

Esta herramienta infiere tipos de un valor de ejemplo; El esquema JSON a TypeScript traduce un esquema formal que ya declara tipos, campos obligatorios y enumeraciones. El esquema tiene autoridad y la inferencia es una suposición, por lo que si tiene un esquema JSON, una especificación OpenAPI o un esquema GraphQL, utilícelo. La inferencia es para el caso muy común en el que no existe ningún esquema y todo lo que tiene es un cuerpo de respuesta.

¿cómo maneja las claves que son identificadores válidos 't?

Las claves con guiones, puntos, espacios o dígitos iniciales se citan en la salida, por lo que "content-type" se convierte en "content-type": string. That's TypeScript válido, al que se accede con notación entre corchetes. Palabras reservadas como class don'no es necesario citar como nombres de propiedad. Los nombres de interfaz derivados de dichas claves tienen PascalCased y prefijo si 'd comienzan con un dígito y los nombres en colisión obtienen un sufijo numérico para que la salida siempre se compile.

¿debo generar interfaces o escribir alias?

Haga coincidir lo que sea que ya haga su base de código; esta es principalmente una cuestión de coherencia. Las interfaces admiten la fusión de declaraciones y extends, y dar mensajes de error marginalmente más claros. Escriba alias can't fusionar, lo cual generalmente es deseable y es necesario para cualquier cosa que sea't una forma de objeto. Una raíz que's una matriz o una primitiva se emite como alias de cualquier manera, ya que allí's no hay ningún objeto para declarar una interfaz.

¿Mi json está cargado en un servidor?

No. Todo el motor de inferencia se ejecuta como JavaScript en su navegador, sin llamadas a la red, sin registro ni almacenamiento. Esto importa aquí más que para la mayoría de las herramientas, porque el JSON you'd pegar en un generador de tipos suele ser una respuesta API real que contiene tokens, registros de clientes o ID internos. Abra la pestaña de su red mientras genera o desconéctese de Internet: sigue funcionando.


Herramientas relacionadas: Formateador JSON Para inspeccionar la carga útil primero, JSON a YAM y JSON a XML para la conversión de formato, y Diferencia de JSON para detectar lo que cambió entre dos respuestas. Lectura adicional: La guía definitiva de las herramientas JSON y La Guía de Herramientas de Codificación del Desarrollador.

Frequently Asked Questions

Paste your JSON into the converter, set the root type name to whatever the resource is called, and press Generate. It infers the type of every key, pulls nested objects out into their own named interfaces, merges arrays of objects into a single element type, and outputs code you can copy straight into a .ts file. There's no signup and no upload — the inference runs in your browser.

Comments

0 comments

0/2000 characters

No comments yet. Be the first to share your thoughts!