JSON से TypeScript कन्वर्टर

Converter वास्तव में क्या करता है

यह आपके JSON को parse करता है, हर value पर walk करता है, और shape describe करने वाले TypeScript interface declarations का set emit करता है। Nested objects को PascalCase में parent property key से derived अपना named interface मिलता है (एक user field User interface बन जाती है)। जब दो nested objects name पर collide करते हैं, दूसरे को numeric suffix मिलता है (User, User2)। Root पर, array type Root = RootItem[]; alias plus RootItem interface बन जाता है; object single Root interface बन जाता है (या जो भी नाम आप «root name» field में डालें)।

Sample input और output:

// Input
{
  "id": 42,
  "name": "Ada",
  "active": true,
  "tags": ["admin", "billing"],
  "profile": { "bio": "Programmer", "link": null }
}

// Output
export interface Root {
  id: number;
  name: string;
  active: boolean;
  tags: string[];
  profile: Profile;
}

export interface Profile {
  bio: string;
  link: unknown;
}

JSON → TypeScript Type Mapping

Root-level arrays of objects के लिए, converter सभी items में keys को single representative interface में merge करता है। यह fair approximation है जब items same shape share करते हैं, लेकिन जब shapes genuinely diverge होती हैं (जैसे heterogeneous events array) तो information lose होती है। उस case के लिए, generation के बाद आपको hand से discriminated union लिखना होगा।

Objects के लिए interface क्यों, Root Array के लिए type क्यों

Official TypeScript Handbook एक one-line heuristic देता है: «If you would like a heuristic, use interface until you need to use features from type.» दोनों structurally typed हैं, दोनों object shapes describe कर सकते हैं, लेकिन interface object shapes के लिए win करता है क्योंकि यह declaration merging support करता है (interface को fields add करने के लिए re-open करना), extends के साथ cleanly काम करता है, और compiler errors में name से show होता है। type aliases required होते हैं जब आपको primitives के unions, multiple types के intersections, या non-object चीज़ को name करना हो, इसीलिए root-level array को interface की बजाय type Root = RootItem[]; alias मिलता है।

Naming के बारे में एक note: converter legacy I prefix के बिना PascalCase use करता है (इसलिए User rather than IUser)। Modern TS style guides (Google's, Microsoft's, React community's) लगभग universally prefix drop करते हैं। Property names JSON keys से exactly match करते हैं (camelCase यदि JSON camelCase use करता है, snake_case यदि snake_case use करता है)। Keys जो valid JS identifiers नहीं हैं (hyphens, spaces contain करते हों, या digit से शुरू होते हों) quoted होते हैं: "foo-bar": string;।

यह Tool क्या नहीं करता (Limits के बारे में ईमानदारी)

एक single JSON example एक real schema से कम information carry करता है, इसलिए कई चीज़ें जो detect करना nice होता अकेले input से possible नहीं हैं:

• Optional fields। आपके example में हर property required बन जाती है। यदि real API कभी-कभी field omit करता है, तो आपको ? hand से add करना होगा: email?: string;। या converter को multiple examples पर run करें और results union करें।
• Nullable detection। Example में null unknown बन जाता है; converter यह नहीं बता सकता कि field genuinely nullable है (string | null) या इस sample में बस null था। API contract के based पर hand से adjust करें।
• String literal unions। "active" value वाला status field string बन जाता है, "active" | "inactive" | "pending" नहीं। Converter दूसरी values नहीं देख सकता।
• Date type detection। "2024-04-12T10:00:00Z" जैसी ISO 8601 string string ही रहती है। JavaScript का Date JSON type नहीं है।
• Discriminated unions। यदि root array में different shapes के items हैं (different types के events, polymorphic records), तो converter सभी keys को एक interface में merge करता है tagged union produce करने की बजाय। Real heterogeneous data के लिए, आपको union hand से लिखना होगा।
• Number precision। JavaScript का number safely integers को 2⁵³−1 तक represent करता है। Large integer IDs JSON.parse से parse होने पर precision lose करते हैं; यदि आपका API 64-bit integers return करता है, तो safest pattern उन्हें strings के रूप में भेजना और string के रूप में type करना है।

यह Tool कब Use करें

• Real API response से types bootstrapping करना। Endpoint hit करें, JSON paste करें, interfaces का starting set पाएं। Optional fields और string literals के लिए hand से tweak करें।
• Untyped third-party SDK में types add करना। कई older JS libraries बिना types के ship होती हैं। Sample response से generate करना docs पढ़ने से faster है।
• Front-end और back-end के बीच types share करना। एक canonical example से generate करें और दोनों codebases में copy करें (या published types package के माध्यम से share करें)।
• JS codebase को TypeScript पर migrate करना। App में flowing real data से types generate करें और gradually function signatures annotate करें।
• Config file के लिए types generate करना। Strict typing config errors को compile time पर visible बनाती है।
• Internal data file की shape document करना। Generated interface machine-readable docs के रूप में भी काम करता है।

Code-First बनाम Schema-First बनाम Direct (यह Tool कहां Fit होता है)

TypeScript types runtime data से पाने के तीन common workflows:

• Code-first runtime validators: Zod, Yup, Effect Schema, Joi। आप JS में validator schema लिखते हैं, यह inference के माध्यम से runtime parsing और TypeScript type दोनों देता है। Schema source of truth है। Best जब validation type जितना ही matter करे।
• Schema-first: JSON Schema या OpenAPI spec लिखें, quicktype, json-schema-to-typescript, या openapi-typescript जैसे tools के माध्यम से TypeScript types generate करें। Best जब API contract multiple languages span करे।
• Direct sample inference (यह tool, plus quicktype's plain-JSON mode), real data paste करें, types पाएं। Fastest path; weakest validation guarantees क्योंकि nothing runtime data को type के against check करता है।

Right choice इस पर depend करता है कि आपकी concern mostly static type-checking है (यह tool great है) या runtime safety भी (Zod / Effect Schema reach करें)।

सामान्य गलतियाँ

1. Generated types को finished spec treat करना। ये 70%-done starting point हैं। Optional fields के लिए ? add करें, genuinely nullable जगहों पर | null, applicable होने पर string literal unions।
2. Single example से generate करना जब API में variants हों। User object जिसमें कभी email हो और कभी नहीं, «email is required» के रूप में generate होगा। Multiple examples run करें और results union करें, या hand-edit करें।
3. सब कुछ automatically readonly mark करना। Immutable data flows के लिए useful लेकिन state objects के लिए wrong जिन्हें आप mutate करते हैं। readonly toggle thoughtfully use करें।
4. Large integer IDs पर precision trust करना। JavaScript का number 2⁵³−1 पर tops out होता है। 64-bit IDs के लिए, strings के रूप में transmit करें और string के रूप में type करें।
5. interface को type से confuse करना। Different tools, different trade-offs। TypeScript Handbook का heuristic है «use interface unless you need a feature only type provides,» exactly यही यह tool करता है।
6. Confidential JSON को server-side converter में paste करना। Real API responses में अक्सर customer data, credentials, internal IDs होते हैं। Browser-only conversion (यह tool) data आपकी machine पर रखता है।

अधिक Frequently Asked Questions

मेरे सभी fields required क्यों mark हो गए?

क्योंकि single JSON example converter को नहीं बता सकता कि real API में कौन से fields कभी-कभी absent होते हैं। Example में appear होने वाली हर key required बन जाती है। यदि आप जानते हैं कि field optional है, तो trailing ? hand से add करें: email?: string;। Multi-sample optionality detection के लिए, more sophisticated quicktype CLI इसे natively handle करता है।

मेरा null field unknown के रूप में typed क्यों है?

क्योंकि converter single null से यह नहीं बता सकता कि field हमेशा nullable है (string | null) या इस sample में बस null था (string)। unknown conservative default है; TypeScript आपको value use करने से पहले type narrow करने के लिए force करेगा, जो any से safer है। API की intent जानने के बाद string | null hand से edit करें।

interface या type use करना चाहिए?

Official TypeScript Handbook का heuristic: interface use करें जब तक आपको केवल type द्वारा provide किए जाने वाले feature की ज़रूरत न हो, primarily union types, intersection types, या primitive को name करना। यह converter उसी rule को follow करता है: हर object shape के लिए interface, root array alias के लिए type। कुछ style guides बजाय type default करने की recommend करते हैं (Matt Pocock ने publicly यह case argue किया है) लेकिन objects के लिए conventional default interface है।

क्या मेरा JSON कहीं upload होगा?

नहीं। Conversion एक self-contained JavaScript IIFE है जो आपके JSON को JSON.parse के माध्यम से parse करता है, value पर walk करता है, और TypeScript output को textarea में लिखता है। कोई fetch नहीं, कोई analytics call नहीं जो JSON content carry करे, कोई server नहीं। यह matter करता है क्योंकि real API responses में typically customer data, internal IDs, या credentials होते हैं जो आप third party से flow नहीं करवाना चाहते।

JSDoc, Zod, या runtime validation के बारे में क्या?

यह tool केवल compile-time TypeScript types emit करता है: कोई runtime validators नहीं (Zod / Yup / Effect Schema), कोई JSDoc comments नहीं। यदि आपको runtime validation चाहिए जो static type के रूप में भी double करे, तो Zod में schema लिखें और type derive करने के लिए Zod का z.infer<typeof Schema> use करें। यदि आपके पास JSON Schema है और runtime validation और TS types दोनों चाहते हैं, तो json-schema-to-typescript + AJV conventional pairing है।

Interface names पर I prefix क्यों नहीं है?

क्योंकि अधिकांश modern TypeScript style guides इसे drop करते हैं। Google's TypeScript Style Guide इसके against explicitly recommend करता है; React community PascalCase without prefix पर converge हो गई है। Legacy IUser convention C# / Java का early TypeScript पर influence था; current practice plain User है।