JSON para TypeScript

Exemplo

Entrada:

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

Saída:

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

interface Address {
  city: string;
}

Mapeamento de tipos

Opcional vs anulável

• foo?: string, o campo pode estar ausente do objeto. A verificação de undefined se aplica.
• foo: string | null, o campo está sempre presente mas pode ser explicitamente nulo.
• foo?: string | null, pode estar ausente OU nulo.

O JSON em si não tem undefined, mas as APIs variam em como sinalizam a ausência. Combine com a semântica da sua API:

• APIs REST geralmente omitem campos ausentes -> ?:.
• GraphQL sempre retorna todos os campos solicitados -> | null.
• Alguns SDKs usam ambos em diferentes contextos.

Tipos de união vs literais

Se a ferramenta vê o mesmo campo de string com um pequeno conjunto de valores em amostras ("status": "pending", "active", "archived"), ela pode emitir uma união literal de string:

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

Ative “inferir uniões literais de string” se você quiser isso.

Erros comuns

• Inferindo de uma amostra. Cada campo se torna obrigatório; a nulidade não pode ser observada. Passe de 5 a 10 amostras variadas para melhores tipos.
• Arrays vazios. "tags": [] não fornece informações de tipo, o gerador emite unknown[]. Forneça uma amostra com pelo menos um elemento.
• Arrays de tipos mistos. [1, "two", true] produz (number | string | boolean)[]. Normalmente isso significa que o JSON deve ser redesenhado em vez de tipado.
• Chaves de string numéricas. JSON {"1": "a", "2": "b"} ainda é um objeto em TypeScript (Record<string, string>), não um array. O gerador lida com isso corretamente.