§

JSON نمونہ

type inferrer تیار ہو رہا ہے…
§

TypeScript interfaces

TypeScript

Pakistan میں TypeScript ٹیموں کو یہ مسئلہ جلدی پیش آتا ہے۔ بڑے SDKs typed clients ship کرتے ہیں (Stripe، Twilio، AWS)، لیکن internal services اور third-party webhook payloads شاذ ہی کرتے ہیں، اس لیے عام workflow یہ ہے: network panel میں ایک real response capture کریں، یہاں paste کریں، root کا نام endpoint کے بعد رکھیں، اور آؤٹ پٹ project کی types directory میں copy کریں۔ وہاں سے، strict mode وہ mismatches پکڑتا ہے جو documentation نے بتانا بھول گئی تھی۔ FedRAMP gateways کو target کرنے والے federal contractors inferred shapes کو microservice boundaries پر JSON validate کرنے کے لیے استعمال کرتے ہیں بغیر bundle میں runtime schema dependency شامل کیے۔ inferrer مکمل طور پر آپ کے براؤزر میں چلتا ہے، اس لیے staging APIs، signed webhook bodies اور unreleased endpoints کے payloads کسی hosted service تک نہیں پہنچتے۔

JSON سے TypeScript inference کیسے کام کرتی ہے؟

Inference parsed JSON tree پر ایک single pass ہے۔ ٹول ہر value پڑھتا ہے، اس کے لیے ایک TypeScript type چنتا ہے، پھر اسے ملنے والے ہر object کے لیے ایک interface لکھتا ہے۔

  1. Browser کے native parser سے JSON نمونہ parse کریں اور malformed input کو line/column hint کے ساتھ reject کریں۔
  2. ہر value کے لیے TypeScript type sniff کریں — string، number، boolean، null، array یا نیسٹڈ object۔
  3. ہر نیسٹڈ object کو اس کے parent property key سے ماخوذ interface نام دیں (اس لیے user.address ایک Address interface بنتا ہے)۔
  4. ہر array میں item types merge کریں تاکہ {id: 1} اور {id: 2, label: "x"} کی فہرست صحیح optional fields کے ساتھ union تیار کرے۔
  5. اپنے options (interface بمقابلہ type، readonly، optional-nullable) لاگو کریں اور dependency order میں declarations emit کریں تاکہ file forward references کے بغیر compile ہو۔

JSON سے TypeScript types کیوں تخلیق کریں؟

  • زیادہ تر shape bugs compile time پر قابل گرفت ہیں اگر response type لکھا ہو۔ real payload سے interface infer کرنا زیادہ تر کام آپ کے لیے لکھ دیتا ہے، اور `strict` mode وہ field پکڑتا ہے جسے docs نے ذکر کرنا بھول گئے۔
  • Zod یا io-ts جیسے runtime validator کے ساتھ inferred interfaces کو pair کرنا اسی shape کو دو کام دیتا ہے: development میں editor autocomplete اور edge پر 400 جب production کچھ unexpected بھیجے۔
  • TypeScript کا language server صرف وہ fields surface کرتا ہے جو وہ جانتا ہے۔ ایک بار inferred interface import کریں، dot ٹائپ کرتے ہی autocomplete کام کرتا ہے — response پر as any cast اور repo میں مایوس grep مزید نہیں۔
  • اگر آپ OpenAPI spec لکھنے والے ہیں، تو inferred interface response schema کا تیز first draft ہے۔ آپ کو پھر بھی ہاتھ سے لکھے examples اور constraints چاہیے ہوں گے، لیکن property names اور types پہلے سے درست ہیں۔

عام استعمالات

Inference سب سے زیادہ مدد کرتی ہے جب real payload موجود ہو لیکن schema نہ ہو۔

  • Stripe، GitHub یا Twilio کے third-party webhook payloads کے لیے handler لکھنے سے پہلے types بنانا۔
  • internal REST API کے لیے types bootstrapping تاکہ frontend team اسی دن اس کے خلاف coding شروع کر سکے جس دن backend آئے۔
  • observed API response سے Zod، io-ts یا Valibot schema کے لیے starting point تخلیق کرنا۔

آؤٹ پٹ کیسا دکھتا ہے؟

ایک نمونہ JSON دستاویز اور ایک root نام دینے پر، generator interfaces کا ایک tree تیار کرتا ہے، ہر نیسٹڈ object کے لیے ایک۔ نیچے کے input کے لیے root نام User کے ساتھ:

{"id":1,"name":"Alice","tags":["a","b"],"address":{"city":"Paris"}} root نام User کے ساتھ paste کریں اور generator تیار کرتا ہے:

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

export interface Address {
  city: string;
}
نوٹ کریں کہ address اپنے نامی interface میں promote ہوا — یہ dependency-ordered آؤٹ پٹ ہے۔ وہی JSON type declaration style کے ساتھ export type User = {...} emit کرے گا؛ readonly ٹوگل آن ہونے پر ہر property کو readonly modifier ملتا ہے۔

Generator options

Declaration style

interface چنیں (object shapes کے لیے معیاری TypeScript idiom) یا type (کارآمد اگر آپ کو بعد میں mapped types، conditional types یا intersections چاہیے ہوں)۔ دونوں یکساں runtime رویہ پیدا کرتے ہیں؛ انتخاب coding-style preference ہے۔

Optional nullable fields

جب sampled value null ہو، field کا type T | null بنتا ہے۔ یہ آپشن آن کرنے سے ? modifier بھی شامل ہوتا ہے تاکہ field TypeScript side پر optional ہو — مفید جب API کبھی key بالکل omit کرے null لوٹانے کی بجائے۔

Readonly modifier

ہر property declaration پر readonly prepend کرتا ہے تاکہ emitted interface immutable data model سے میل کھائے۔ Redux state slices، frozen API responses، یا جہاں بھی compiler کو accidental mutation flag کرانی ہو، وہاں کارآمد۔

کیا یہ نیسٹڈ objects اور arrays سپورٹ کرتا ہے؟

جی ہاں۔ ہر نیسٹڈ object اپنے parent property key سے ماخوذ نامی interface بنتا ہے، اور arrays اپنے contents سے item type infer کرتی ہیں۔ Objects کی arrays فی object shape ایک interface پاتی ہیں، union types کے ساتھ جہاں shapes متفق نہ ہوں۔

Optional fields کیسے infer ہوتے ہیں؟

"null-able fields optional نشان کریں" ٹوگل آن کریں اور جس field کی sampled value null ہو اسے key پر ? modifier اور type میں | null ملتا ہے۔ ٹوگل کے بغیر، field required رہتی ہے اور type صرف T | null ہے۔

کیا یہ discriminated unions سپورٹ کرتا ہے؟

Basic union types اس وقت آتے ہیں جب array میں mixed-shape items ہوں یا کوئی field value اور null دونوں رکھے۔ Full discriminated-union inference (tag کے طور پر type یا kind چننا اور variants split کرنا) کے لیے متعدد نمونے چاہیے — یہ منصوبہ بند ہے لیکن آج کے build میں نہیں۔

کیا میں متعدد JSON نمونوں سے types infer کر سکتا ہوں؟

ابھی نہیں — آج کا inferrer ایک بار میں ایک نمونہ پڑھتا ہے۔ اگر آپ کے پاس دو payloads ہیں جو ایک interface share کریں (مثلاً list endpoint اور single-item endpoint)، عملی حل یہ ہے: انہیں ایک array میں merge کریں، اس سے generate کریں، پھر resulting union types rename کریں۔ Multi-sample inference roadmap پر ہے کیونکہ یہ وہ fields پکڑنے کا واحد طریقہ ہے جو ایک response میں موجود اور دوسرے میں غائب ہوں۔

Payload paste کریں، root نام دیں، interfaces کاپی کریں۔ پوری pipeline آپ کے براؤزر میں چلتی ہے، اس لیے unreleased API یا signed webhook body آپ کی مشین پر رہتی ہے۔