JSON a TypeScript

Ejemplo

Entrada:

{ "id": 1, "name": "Alice", "age": null, "tags": ["admin", "user"], "address": { "city": "Madrid" } }

Salida:

interface User {
  id: number;
  name: string;
  age: number | null;
  tags: string[];
  address: Address;
}

interface Address {
  city: string;
}

Mapeo de tipos

Opcional vs anulable

• foo?: string, el campo puede estar ausente del objeto. Se aplica la verificación de undefined.
• foo: string | null, el campo está siempre presente pero puede ser explícitamente nulo.
• foo?: string | null, podría estar ausente O nulo.

JSON en sí no tiene undefined, pero las APIs varían en cómo señalan la ausencia. Alinea con la semántica de tu API:

• Las APIs REST típicamente omiten campos faltantes -> ?:.
• GraphQL siempre devuelve cada campo solicitado -> | null.
• Algunos SDK utilizan ambos en diferentes contextos.

Tipos de unión vs literales

Si la herramienta ve el mismo campo de cadena con un pequeño conjunto de valores en las muestras ("status": "pending", "active", "archived"), puede emitir una unión de literales de cadena:

status: "pending" | "active" | "archived";

Activa “inferir uniones de literales de cadena” si deseas esto.

Errores comunes

• Inferir de una sola muestra. Cada campo se vuelve requerido; no se puede observar la nulabilidad. Pasa de 5 a 10 muestras variadas para obtener mejores tipos.
• Arreglos vacíos. "tags": [] no proporciona información de tipo, el generador emite unknown[]. Proporciona una muestra con al menos un elemento.
• Arreglos de tipos mixtos. [1, "two", true] produce (number | string | boolean)[]. Generalmente esto significa que el JSON debería ser rediseñado en lugar de tipificado.
• Claves de cadena numéricas. JSON {"1": "a", "2": "b"} sigue siendo un objeto en TypeScript (Record<string, string>), no un arreglo. El generador maneja esto correctamente.