Gumawa ng TypeScript interfaces mula sa JSON _

Paano gumagana ang JSON-to-TypeScript inference

Isang pass lang sa parsed JSON tree ang inference. Binabasa ng tool ang bawat value, pinipili ang TypeScript type para dito, at isinusulat ang isang interface para sa bawat object na nahanap nito.

1. I-parse ang JSON sample gamit ang native parser ng browser at itanggap ang maling input na may line/column hint.
2. Mag-sniff ng TypeScript type para sa bawat value — string, number, boolean, null, array, o nested object.
3. Bigyan ng interface name ang bawat nested object na hango sa parent property key nito (kaya ang user.address ay magiging Address interface).
4. Pagsamahin ang mga item type sa bawat array para ang listahan ng {id: 1} at {id: 2, label: "x"} ay makagawa ng union na may tamang optional fields.
5. I-apply ang iyong mga opsyon (interface vs. type, readonly, optional-nullable) at mag-emit ng mga declaration sa dependency order para mag-compile ang file nang walang forward references.

Bakit gumawa ng TypeScript types mula sa JSON?

• Karamihan sa mga shape bug ay makukuha sa compile time kung nakasulat ang response type. Ang pag-infer ng interface mula sa tunay na payload ay nagsusulat ng karamihan nito para sa iyo, at nahuhuli ng `strict` mode ang field na nakalimutan ng docs.
• Ang pagsasama ng mga inferred interface sa isang runtime validator tulad ng Zod o io-ts ay nagbibigay ng dalawang trabaho sa parehong shape: editor autocomplete sa development at 400 error sa edge kapag may hindi inaasahang padala ang production.
• Ang language server ng TypeScript ay nagpapakita lang ng mga field na kilala nito. Kapag na-import mo na ang inferred interface, gumagana na ang autocomplete pagka-type mo ng tuldok — hindi na kailangang mag-cast ng `as any` sa response at mag-grep sa buong repo.
• Kung magsusulat ka na ng OpenAPI spec, ang inferred interface ay isang mabilis na unang draft ng response schema. Kailangan mo pa ring magsulat ng mga halimbawa at constraints nang mano-mano, pero tama na ang mga property name at type.

Mga karaniwang gamit

Nakakatulong ang inference kapag may tunay na payload na pero wala pang schema.

• Pag-type ng mga third-party webhook payload mula sa Stripe, GitHub, o Twilio bago sumulat ng handler.
• Pag-bootstrap ng mga type para sa isang internal REST API para makapagsimula na agad ang frontend team nang araw din na natapos ang backend.
• Paggawa ng panimulang punto para sa Zod, io-ts, o Valibot schema mula sa isang observed na API response.

Ano ang hitsura ng output?

Kapag binigay ang isang JSON sample at isang root name, ang generator ay gumagawa ng puno ng mga interface, isa para sa bawat nested object. Para sa input sa ibaba na may root name na User:

I-paste ang {"id":1,"name":"Alice","tags":["a","b"],"address":{"city":"Paris"}} na may root name na User at ang generator ay gagawa ng:

export interface User {
  id: number;
  name: string;
  tags: string[];
  address: Address;
}

export interface Address {
  city: string;
}

Mga opsyon ng generator

Declaration style

Pumili ng interface (ang karaniwang TypeScript idiom para sa mga object shape) o type (kapaki-pakinabang kung kakailanganin mo ng mapped types, conditional types, o intersections sa susunod). Parehong may katulad na runtime behaviour; ang pagpili ay isang coding-style preference.

Mga optional nullable field

Kapag ang sampled value ay null, ang type ng field ay nagiging T | null. Ang pag-on ng opsyong ito ay nagdadagdag din ng ? modifier para ang field ay optional sa TypeScript side — kapaki-pakinabang kapag minsan ay tinatanggal ng API ang key nang buo imbes na ibalik ang null.

Readonly modifier

Idinaragdag ang readonly sa harap ng bawat property declaration para ang emitted interface ay tumugma sa isang immutable data model. Kapaki-pakinabang para sa Redux state slices, frozen API responses, o kahit saan na gusto mong markahan ng compiler ang aksidenteng mutation.

Sinusuportahan ba nito ang mga nested object at array?

Oo. Ang bawat nested object ay nagiging named interface na hango sa parent property key nito, at ang mga array ay nag-iinfer ng item type mula sa kanilang nilalaman. Ang mga array ng object ay nakakakuha ng interface bawat object shape, na may union types kung saan magkaiba ang mga shape.

Paano nini-infer ang mga optional field?

I-on ang toggle na "Mark null-able fields optional" at ang anumang field na ang sampled value ay null ay makakakuha ng ? modifier sa key kasama ang | null sa type. Kung wala ang toggle, ang field ay mananatiling required at ang type ay magiging T | null lang.

Sinusuportahan ba nito ang discriminated unions?

Lumalabas ang mga basic union type kapag ang array ay may mixed-shape items o kapag ang isang field ay may parehong value at null. Ang full discriminated-union inference (pagpili ng type o kind bilang tag at paghihiwalay ng mga variant) ay nangangailangan ng maraming sample — planado iyon pero wala pa sa kasalukuyang build.

Maari bang mag-infer ng types mula sa maraming JSON sample?

Hindi pa — isang sample lang ang nababasa ng kasalukuyang inferrer sa isang pagkakataon. Kung mayroon kang dalawang payload na dapat magbahagi ng interface (halimbawa, isang list endpoint at isang single-item endpoint), ang praktikal na solusyon ay pagsamahin sila sa isang array, gumawa mula roon, at pangalanan muli ang mga nagresultang union type. Ang multi-sample inference ay nasa roadmap dahil ito ang tanging paraan para matuklasan ang mga field na present sa isang response pero absent sa isa pa.

Mag-paste ng payload, pangalanan ang root, kopyahin ang mga interface. Ang buong pipeline ay tumatakbo sa iyong browser, kaya ang mga unreleased API o signed webhook body ay nananatili sa iyong makina.