JSON-to-TypeScript inference எவ்வாறு வேலை செய்கிறது
Inference என்பது பாகுபடுத்தப்பட்ட JSON மரத்தில் ஒரே ஒரு pass. கருவி ஒவ்வொரு மதிப்பையும் படிக்கிறது, அதற்கு ஒரு TypeScript type தேர்ந்தெடுக்கிறது, பிறகு கண்டுபிடித்த ஒவ்வொரு object க்கும் ஒரு interface எழுதுகிறது.
- உலாவியின் native parser மூலம் JSON sample ஐ பாகுபடுத்தி, தவறான உள்ளீட்டை line/column குறிப்புடன் நிராகரிக்கவும்.
- ஒவ்வொரு மதிப்புக்கும் ஒரு TypeScript type sniff செய்யவும் —
string,number,boolean,null, array, அல்லது nested object. - ஒவ்வொரு nested object க்கும் அதன் parent property key இலிருந்து வரும் interface பெயர் கொடுக்கவும் (எனவே
user.addressஒருAddressinterface ஆகிறது). - ஒவ்வொரு array இலும் item types merge செய்யவும்,
{id: 1}மற்றும்{id: 2, label: "x"}கொண்ட list சரியான optional புலங்களுடன் union உருவாக்குகிறது. - உங்கள் விருப்பங்களை (interface vs. type, readonly, optional-nullable) பயன்படுத்தி, கோப்பு forward references இல்லாமல் compile ஆகுமாறு dependency order ல் declarations வெளியிடவும்.
JSON இலிருந்து TypeScript types ஏன் உருவாக்க வேண்டும்?
- பெரும்பாலான shape bugs response type எழுதப்பட்டிருந்தால் compile time ல் பிடிக்கலாம். Real payload இலிருந்து interface infer செய்வது அதிகபட்சத்தை உங்களுக்காக எழுதுகிறது, மற்றும் `strict` mode ஆவணங்கள் மறந்து போன புலத்தை catch செய்கிறது.
- Zod அல்லது io-ts போன்ற runtime validator உடன் inferred interfaces இணைப்பது ஒரே shape க்கு இரண்டு வேலைகளை கொடுக்கிறது: development ல் editor autocomplete மற்றும் production எதிர்பாராத ஒன்றை அனுப்பும்போது edge ல் 400.
- TypeScript இன் language server தெரிந்த புலங்களை மட்டுமே surface செய்கிறது. inferred interface import செய்தவுடன், நீங்கள் dot type செய்யும் தருணத்தில் autocomplete வேலை செய்கிறது — response ல் `as any` cast மற்றும் repo முழுவதும் frustrated grep இல்லை.
- OpenAPI spec எழுதப் போகிறீர்கள் என்றால், inferred interface response schema இன் வேகமான முதல் draft. உங்களுக்கு இன்னும் கையெழுத்து எடுத்துக்காட்டுகள் மற்றும் constraints தேவை, ஆனால் property names மற்றும் types ஏற்கனவே சரியாக இருக்கும்.
பொதுவான பயன்பாடுகள்
Real payload இருக்கும் ஆனால் schema இல்லாதபோது inference மிகவும் உதவுகிறது.
- handler எழுதுவதற்கு முன்பு Stripe, GitHub அல்லது Twilio இலிருந்து third-party webhook payloads typing செய்வது.
- Frontend team அதே நாளில் code செய்யத் தொடங்குவதற்காக internal REST API க்கு types bootstrapping செய்வது.
- Observed API response இலிருந்து Zod, io-ts அல்லது Valibot schema க்கான starting point உருவாக்குவது.
வெளியீடு எப்படி இருக்கும்?
ஒரு sample JSON ஆவணம் மற்றும் root பெயர் கொடுத்தால், generator ஒரு interfaces tree உருவாக்குகிறது, ஒவ்வொரு nested object க்கும் ஒன்று. root பெயர் User உடன் கீழேயுள்ள உள்ளீட்டிற்கு:
{"id":1,"name":"Alice","tags":["a","b"],"address":{"city":"Paris"}} ஐ root பெயர் User உடன் ஒட்டவும், generator இதை உருவாக்குகிறது:
export interface User {
id: number;
name: string;
tags: string[];
address: Address;
}
export interface Address {
city: string;
}
address அதன் சொந்த பெயரிடப்பட்ட interface க்கு promote செய்யப்பட்டதை கவனிக்கவும் — அது dependency-ordered output. type declaration style உடன் அதே JSON export type User = {...} emit செய்யும்; readonly toggle இயக்கியிருந்தால், ஒவ்வொரு property க்கும் readonly modifier கிடைக்கும்.
Generator விருப்பங்கள்
அறிவிப்பு நடை
Object shapes க்கான நிலையான TypeScript idiom interface அல்லது நீங்கள் பின்னர் mapped types, conditional types அல்லது intersections தேவைப்படும்போது பயனுள்ள type தேர்ந்தெடுக்கவும். இரண்டும் identical runtime behaviour உருவாக்குகின்றன; தேர்வு coding-style preference.
Optional nullable புலங்கள்
Sampled மதிப்பு null ஆக இருக்கும்போது, புலத்தின் type T | null ஆகிறது. இந்த விருப்பத்தை இயக்குவது ? modifier சேர்க்கிறது, எனவே API சில நேரங்களில் null திருப்பாமல் key ஐ முழுவதும் skip செய்யும்போது TypeScript side ல் புலம் optional ஆகும்.
Readonly மாற்றி
Emitted interface ஒரு immutable data model க்கு பொருந்துமாறு ஒவ்வொரு property declaration க்கும் readonly prepend செய்கிறது. Redux state slices, frozen API responses, அல்லது compiler தற்செயலான mutation flag செய்ய வேண்டும் என்று விரும்பும் எங்கும் பயனுள்ளது.
Nested objects மற்றும் arrays ஆதரிக்கிறதா?
ஆம். ஒவ்வொரு nested object உம் அதன் parent property key இலிருந்து வரும் பெயரிடப்பட்ட interface ஆகிறது, மற்றும் arrays அவற்றின் contents இலிருந்து item type infer செய்கின்றன. Objects இன் arrays shapes ஒவ்வொன்றுக்கும் ஒரு interface பெறுகின்றன, shapes ஒவ்வாமல் இருக்கும் இடங்களில் union types உடன்.
Optional புலங்கள் எவ்வாறு infer செய்யப்படுகின்றன?
"Null-able புலங்களை optional ஆக குறிக்கவும்" toggle இயக்கவும், sampled மதிப்பு null ஆக இருக்கும் எந்த புலத்திற்கும் key ல் ? modifier மற்றும் type ல் | null கிடைக்கும். toggle இல்லாமல், புலம் required ஆக இருக்கும் மற்றும் type வெறும் T | null ஆக இருக்கும்.
Discriminated unions ஆதரிக்கிறதா?
ஒரு array mixed-shape items வைத்திருக்கும்போது அல்லது ஒரு புலம் ஒரு மதிப்பையும் null ஐயும் கொண்டு வரும்போது basic union types வருகின்றன. Full discriminated-union inference (tag ஆக type அல்லது kind தேர்ந்தெடுத்து variants பிரிப்பது) பல samples தேவை — அது திட்டமிடப்பட்டுள்ளது ஆனால் இன்றைய build ல் இல்லை.
பல JSON samples இலிருந்து types infer செய்யலாமா?
இன்னும் இல்லை — இன்றைய inferrer ஒரு நேரத்தில் ஒரு sample படிக்கிறது. ஒரு interface பகிர வேண்டிய இரண்டு payloads இருந்தால் (ஒரு list endpoint மற்றும் single-item endpoint), practical workaround அவற்றை ஒரு array ல் merge செய்யவும், அதிலிருந்து generate செய்யவும், பிறகு resulting union types ஐ பெயரிடவும். Multi-sample inference roadmap ல் உள்ளது, ஏனெனில் ஒரு response ல் இருக்கும் புலங்களை மற்றொன்றில் இல்லாததை கண்டுபிடிக்க அதுவே ஒரே வழி.
ஒரு payload ஒட்டவும், root பெயரிடவும், interfaces நகலெடுக்கவும். முழு pipeline உங்கள் உலாவியில் இயங்குகிறது, எனவே unreleased API அல்லது signed webhook body உங்கள் இயந்திரத்தில் இருக்கும்.