JSON से TypeScript इंटरफ़ेस जनरेटर
कोई भी JSON ऑब्जेक्ट पेस्ट करें और अपने ब्राउज़र में तुरंत एक पूरी तरह टाइप्ड
TypeScript इंटरफ़ेस — या नेस्टेड इंटरफ़ेसों का सेट — जनरेट पाएँ। नेस्टेड
ऑब्जेक्ट, ऐरे, वैकल्पिक प्रॉपर्टीज़, यूनियन टाइप और null संभालता है। कुछ भी
अपलोड नहीं होता।
अंतिम समीक्षा 2026-06-19।
यह कैसे काम करता है
- पार्स — आपका JSON ब्राउज़र के अपने नेटिव
JSON.parseसे पार्स होता है। यदि यह मान्य JSON नहीं है, तो त्रुटि संदेश तुरंत दिखता है। - अनुमान — मान-ट्री को पुनरावर्ती रूप से चला जाता है। हर ऑब्जेक्ट एक नामित
इंटरफ़ेस बनता है। ऐरे के लिए, टाइप सभी एलिमेंट से अनुमानित होता है ताकि परिणामी
टाइप हर आइटम को कवर करे। जिन कीज़ का मान
nullहो, या जो कुछ ऐरे-एलिमेंट से अनुपस्थित हों, उन्हें?के साथ वैकल्पिक चिह्नित किया जाता है। - उत्पन्न — इंटरफ़ेस सबसे-गहरे-पहले (चाइल्ड, फिर पैरेंट) उत्पन्न होते हैं
ताकि फ़ाइल ऊपर-से-नीचे बिना आगे के संदर्भ के कंपाइल हो। हर इंटरफ़ेस
exportकिया जाता है, किसी भी.tsया.d.tsफ़ाइल में पेस्ट करने को तैयार।
प्रॉपर्टी कब वैकल्पिक बनती है
दो स्थितियाँ किसी प्रॉपर्टी को वैकल्पिक चिह्न (?) दिलाती हैं:
-
सैंपल JSON में मान
nullहै — जनरेटर?जोड़ता है और टाइप के अंत में| nullलगाता है, क्योंकि असल API या तो मान लौटा सकता है या कुछ नहीं। -
JSON में ऑब्जेक्टों की एक ऐरे है और कोई की कुछ एलिमेंट में दिखती है पर सभी में
नहीं — की मर्ज किए गए इंटरफ़ेस में जोड़ी तो जाती है पर
?चिह्नित होती है, क्योंकि हर रिकॉर्ड में वह नहीं होगी।
यदि आप जानते हैं कि कोई फ़ील्ड हमेशा मौजूद रहता है और कभी null नहीं होता, तो जनरेट किए गए
आउटपुट से बस ? हटा दें।
JSON → TypeScript टाइप मैपिंग
| JSON मान | TypeScript टाइप | उदाहरण JSON |
|---|---|---|
string | string | "Alice" |
number | number | 42 or 3.14 |
boolean | boolean | true or false |
null | T | null (+ optional ?) | null |
array of T | T[] | ["a","b"] |
array of mixed primitives | (string | number | boolean)[] | [1,"x",true] |
object | interface Name { … } | { "city": "NYC" } |
unknown / empty array | unknown[] | [] |
इंटरफ़ेस नामकरण
इंटरफ़ेस के नाम JSON की-नाम से लिए जाते हैं और PascalCase में बदले जाते हैं — उदाहरण के लिए,
की user_profile से UserProfile नाम का इंटरफ़ेस बनता है, और
lineItems से LineItems। रूट ऑब्जेक्ट हमेशा ऊपर दिए
रूट इंटरफ़ेस नाम फ़ील्ड का नाम इस्तेमाल करता है (डिफ़ॉल्ट Root)।
इसे अपने डोमेन मॉडल से मिलाने के लिए बदलें — जैसे User, ApiResponse
या Product।
गोपनीयता और सुरक्षा
सारी प्रोसेसिंग पूरी तरह आपके ब्राउज़र के अंदर होती है — कोई डेटा किसी सर्वर पर नहीं भेजा जाता, कोई कुकी सेट नहीं होती, और कुछ भी लॉग नहीं होता। असली API प्रतिक्रियाएँ, चाहे उनमें व्यक्तिगत डेटा हो, पेस्ट करना सुरक्षित है, क्योंकि सामग्री कभी आपके डिवाइस से बाहर नहीं जाती। पेज लोड होने के बाद यह टूल ऑफ़लाइन भी काम करता है।
TypeScript क्या है, और टाइप क्यों मदद करते हैं
TypeScript JavaScript का एक टाइप्ड सुपरसेट है, जिसे Microsoft में Anders
Hejlsberg (C# और Turbo Pascal के डिज़ाइनर) ने बनाया और पहली बार 2012 में जारी किया। हर मान्य
JavaScript प्रोग्राम पहले से ही मान्य TypeScript है; TypeScript जो जोड़ता है वह एक
स्थैतिक टाइप-लेयर (static type layer) है, जिसे कंपाइलर आपके कोड के चलने से
पहले जाँचता है और फिर पूरी तरह मिटा देता है — ब्राउज़र को अब भी सादा JavaScript ही मिलता है।
फ़ायदा यह है कि बग्स की एक पूरी श्रेणी लिखते समय ही पकड़ी जाती है: एक ग़लत वर्तनी वाली
प्रॉपर्टी, एक नंबर जहाँ स्ट्रिंग अपेक्षित थी, एक फ़ील्ड जो undefined हो सकता है।
एडिटर इसी टाइप-जानकारी का उपयोग ऑटोकम्प्लीट, इनलाइन डॉक्यूमेंटेशन और सुरक्षित स्वचालित
रीफ़ैक्टरिंग के लिए करते हैं।
TypeScript संरचनात्मक टाइपिंग (structural typing / "duck typing") का उपयोग करता है: दो टाइप संगत होते हैं यदि उनकी आकृति मेल खाती है, चाहे उनके नाम कुछ भी हों। कोई ऑब्जेक्ट वहाँ स्वीकार्य होता है जहाँ इंटरफ़ेस अपेक्षित है, जब तक उसमें कम-से-कम सही टाइप की अनिवार्य प्रॉपर्टीज़ हों। यही वजह है कि किसी असली API प्रतिक्रिया से जनरेट किया गया एक ही सटीक इंटरफ़ेस इतना मूल्यवान होता है — यह उस ठीक-ठीक आकृति का वर्णन करता है जिस पर आपका कोड भरोसा कर सकता है।
JSON से टाइप क्यों जनरेट करें?
जब आप किसी JSON API का उपभोग करते हैं, तो प्रतिक्रिया बस बिना-टाइप वाला डेटा होती है — आपका
एडिटर उसके बारे में कुछ नहीं जानता, इसलिए हर response.user.name एक अनुमान है जो
केवल रनटाइम पर विफल होता है। एक इंटरफ़ेस जनरेट करना उस प्रतिक्रिया को एक
अनुबंध (contract) में बदल देता है: कंपाइलर अब जानता है कि कौन-से फ़ील्ड
मौजूद हैं और हर एक किस टाइप का है, लिखते ही उन्हें ऑटोकम्प्लीट करता है, और
response.user.naem को तुरंत त्रुटि के रूप में चिह्नित करता है। किसी गहरे नेस्टेड
पेलोड के लिए यह हाथ से करना थकाऊ है और ग़लती की संभावना है, जो ठीक वही काम है जिसे यह टूल
स्वचालित करता है — यह JSON को एक बार चलता है और सटीक, नेस्टेड, export किए गए इंटरफ़ेस उत्पन्न
करता है जिन्हें आप सीधे अपने प्रोजेक्ट में पेस्ट कर सकते हैं।
interface बनाम type एलियास
TypeScript किसी ऑब्जेक्ट-आकृति को नाम देने के दो तरीक़े देता है: एक interface और
एक type एलियास। सादे ऑब्जेक्ट-आकृतियों के लिए ये काफ़ी हद तक आपस में बदले जा
सकते हैं, और यह जनरेटर interface घोषणाएँ उत्पन्न करता है क्योंकि वे साफ़ पढ़ी
जाती हैं और उन्हें extend तथा मर्ज किया जा सकता है। जब आपको ऐसा कुछ चाहिए जो
इंटरफ़ेस सीधे व्यक्त नहीं कर सकते, तब type एलियास का उपयोग करें: यूनियन
(type Status = "active" | "archived"), ट्यूपल, मैप्ड टाइप, या किसी प्रिमिटिव का
एलियास। एक आम परंपरा है "ऑब्जेक्ट की सार्वजनिक आकृति के लिए इंटरफ़ेस, यूनियन और यूटिलिटी
टाइप के लिए type एलियास" — पर किसी कोडबेस के भीतर संगति सटीक चुनाव से अधिक मायने रखती है।
एक ही सैंपल से टाइप अनुमान की सीमाएँ
किसी भी JSON-से-टाइप टूल के बारे में — इस टूल सहित — यह सबसे महत्वपूर्ण बात समझनी है: इंटरफ़ेस
उस एकमात्र उदाहरण से अनुमानित होता है जिसे आप पेस्ट करते हैं, और एक उदाहरण
किसी API के बारे में सब कुछ नहीं बता सकता। यदि कोई फ़ील्ड कभी मौजूद और कभी अनुपस्थित होता है
पर आपके सैंपल में संयोगवश शामिल है, तो जनरेटर उसे अनिवार्य चिह्नित कर देगा। यदि कोई फ़ील्ड
आमतौर पर नंबर होता है पर कभी-कभी null, तो केवल वही सैंपल जिसमें null
हो एक वैकल्पिक, nullable टाइप उत्पन्न करेगा। एक ख़ाली ऐरे कोई एलिमेंट-टाइप नहीं देती, इसलिए
उसे केवल unknown[] ही टाइप किया जा सकता है। और एक स्ट्रिंग जो वास्तव में कोई ISO
तारीख़, ईमेल या गणित-गणित मान (enumerated value) है, बस string टाइप की जाती है,
क्योंकि JSON स्तर पर यही सब है। जनरेट किए गए टाइप को API के असली दस्तावेज़ के विरुद्ध निखारने
के लिए एक शानदार पहला मसौदा समझें, न कि एक गारंटीशुदा पूर्ण अनुबंध।
null, undefined और वैकल्पिक ? चिह्न
TypeScript एक बारीक भेद करता है जिसे JavaScript धुंधला कर देता है। null एक
स्पष्ट "कोई मान नहीं" है; undefined "यह कभी सेट ही नहीं हुआ" है; और वैकल्पिक
चिह्न ? का अर्थ है कि प्रॉपर्टी ऑब्जेक्ट से पूरी तरह ग़ायब हो सकती है।
ये एक जैसी नहीं हैं। जब आप अनुशंसित strictNullChecks कंपाइलर विकल्प सक्षम करते
हैं, तो टाइप-सिस्टम आपको हर मामले को संभालने के लिए बाध्य करता है, जो क्लासिक "cannot read
property of undefined" क्रैश को रोकता है। यह जनरेटर ? (और | null)
तब जोड़ता है जब कोई सैंपल-मान null हो, और अकेला ? तब जब कोई की
ऑब्जेक्ट-ऐरे के कुछ एलिमेंट से अनुपस्थित हो — जो सैंपल ने दिखाया उसका ईमानदार प्रतिबिंब। यदि
आपकी डोमेन-जानकारी कहती है कि कोई फ़ील्ड हमेशा मौजूद रहता है, तो बस आउटपुट से ?
हटा दें।
any बनाम unknown
जब कोई टाइप वास्तव में निर्धारित नहीं हो पाता, तो आपके पास दो निकास-द्वार हैं। any
उस मान के लिए टाइप-जाँच को बंद कर देता है — कुछ भी अनुमत हो जाता है, जो चुपचाप उन्हीं
बग्स के लिए दरवाज़ा फिर खोल देता है जिन्हें पकड़ने के लिए TypeScript मौजूद है।
unknown सुरक्षित विकल्प है: यह किसी भी मान को स्वीकार करता है पर उपयोग से पहले
आपको एक जाँच से उसे सँकरा (narrow) करने को बाध्य करता है। आधुनिक शैली any पर
unknown को दृढ़ता से प्राथमिकता देती है, और यही वजह है कि यह टूल किसी ख़ाली ऐरे
के लिए any[] के बजाय unknown[] उत्पन्न करता है — यह आपके कोड को तब
तक ईमानदार रखता है जब तक आप असली एलिमेंट-टाइप न दें।
टाइप रनटाइम पर मिट जाते हैं — अविश्वसनीय डेटा को वैलिडेट करें
चूँकि TypeScript टाइप कंपाइलेशन के दौरान मिटा दिए जाते हैं, वे रनटाइम पर कोई सुरक्षा नहीं देते। यदि कोई सर्वर ऐसा डेटा लौटाता है जो आपके इंटरफ़ेस से मेल नहीं खाता — कोई ग़ायब फ़ील्ड, कोई स्ट्रिंग जहाँ आपने नंबर की उम्मीद की — तो TypeScript इसे नहीं रोक सकता, क्योंकि तब तक टाइप रह ही नहीं जाते। किसी विश्वास-सीमा (trust boundary) को पार करने वाले डेटा (बाहरी API, उपयोगकर्ता इनपुट, वेबहुक) के लिए आपको एक रनटाइम वैलिडेटर चाहिए। Zod, io-ts और Valibot जैसी लाइब्रेरियाँ आपको एक बार स्कीमा घोषित करने देती हैं और आने वाले डेटा को वैलिडेट भी करती हैं और उससे मेल खाता TypeScript टाइप भी अनुमानित करती हैं, ताकि स्थैतिक टाइप और रनटाइम जाँच कभी अलग न हों। JSON Schema को Ajv जैसे वैलिडेटर के साथ यही काम भाषा-निरपेक्ष तरीक़े से करता है। यह टूल जो इंटरफ़ेस बनाता है वे happy-path आकृति का वर्णन करते हैं; एक रनटाइम वैलिडेटर गारंटी देता है कि डेटा वास्तव में उसी में आया।
सैंपल-आधारित बनाम स्कीमा-आधारित जनरेशन
किसी सैंपल से टाइप जनरेट करना, जैसा यहाँ है, सबसे तेज़ रास्ता है जब आपके पास केवल एक उदाहरण प्रतिक्रिया हो — कोई सेटअप नहीं, कोई बिल्ड-स्टेप नहीं, पेस्ट करो और चलो। जब कोई API औपचारिक वर्णन प्रकाशित करता है तब आप बेहतर कर सकते हैं: एक OpenAPI (Swagger) दस्तावेज़ या एक GraphQL स्कीमा को किसी कोड-जनरेटर को दिया जा सकता है जो हर एंडपॉइंट और API द्वारा दस्तावेज़ीकृत हर प्रकार को कवर करने वाले टाइप बनाता है, और जिसे API बदलने पर फिर से चलाया जा सकता है ताकि टाइप कभी पुराने न पड़ें। सैंपल-आधारित जनरेशन को त्वरित, तदर्थ टूल समझें और स्कीमा-आधारित जनरेशन को अनुरक्षित, पूरे-API का समाधान — ये प्रतिस्पर्धा नहीं, एक-दूसरे के पूरक हैं।
जनरेट किए गए मसौदे से प्रोडक्शन टाइप तक
कुछ त्वरित संपादन एक जनरेट किए गए इंटरफ़ेस को एक निखरे डोमेन-टाइप में बदल देते हैं। रूट
इंटरफ़ेस का नाम Root से कुछ अर्थपूर्ण में बदलें (User,
ApiResponse, Invoice)। ढीले string फ़ील्ड को लिटरल
यूनियन में सँकरा करें जहाँ मान-समूह ज्ञात हो ("draft" | "published")।
unknown[] को असली एलिमेंट-टाइप से बदलें जब आप उसे जान लें। पहचानकर्ताओं को
"ब्रांड" करने पर विचार करें ताकि एक UserId और एक OrderId आपस में न
मिल जाएँ, भले ही दोनों स्ट्रिंग हों। और यदि आप कोई लाइब्रेरी शिप कर रहे हैं, तो इंटरफ़ेस को
एक .d.ts घोषणा फ़ाइल में ले जाएँ — एक केवल-टाइप वाली फ़ाइल जो
बिना कोई JavaScript उत्पन्न किए आकृतियों का वर्णन करती है — ताकि उपभोक्ताओं को शून्य रनटाइम
लागत पर पूरी टाइप-जानकारी मिले।
ऑब्जेक्टों की ऐरे एक ही इंटरफ़ेस कैसे बनती है
जब किसी JSON ऐरे में ऑब्जेक्ट होते हैं, तो यह टूल हर एलिमेंट के लिए अलग टाइप नहीं बनाता — यह
उन्हें एक ही इंटरफ़ेस में मर्ज कर देता है जो पूरे संग्रह का वर्णन करता है। यह
सभी ऑब्जेक्टों में दिखने वाली हर की को इकट्ठा करता है, हर प्रॉपर्टी का टाइप उसके देखे गए मानों
से अनुमान लगाता है, और किसी भी की को जो कम-से-कम एक एलिमेंट से ग़ायब हो ? के साथ
वैकल्पिक चिह्नित करता है। फिर प्रॉपर्टी को उस मर्ज किए इंटरफ़ेस की ऐरे के रूप में टाइप किया
जाता है (उदाहरण के लिए users: User[])। आमतौर पर यही आप चाहते हैं, क्योंकि किसी असली
API सूची में एक ही आकृति की आइटम्स होनी चाहिए — पर इसका मतलब यह भी है कि एक अजीब एलिमेंट
अनुमानित टाइप को चौड़ा कर सकता है, इसलिए केवल पहला रिकॉर्ड नहीं, बल्कि एक प्रतिनिधि सैंपल पेस्ट
करना बेहतर है।
Enum और लिटरल यूनियन
JSON में enum की कोई अवधारणा नहीं है, इसलिए कोई फ़ील्ड जिसका मान किसी निश्चित समूह में से एक
हो — कोई स्टेटस, कोई भूमिका, कोई देश-कोड — एक सादे string के रूप में आता है, और
यह टूल उसे वैसे ही टाइप करता है। ऐसे फ़ील्ड को हाथ से सँकरा करना सबसे मूल्यवान संपादनों में से
एक है: status: string को status: "draft" | "published" | "archived"
में बदलें और कंपाइलर अब किसी भी वर्तनी-दोष या अमान्य मान को पकड़ लेगा, जबकि आपका एडिटर अनुमत
विकल्पों को ऑटोकम्प्लीट करेगा। TypeScript के पास एक समर्पित enum कीवर्ड भी है, पर
अधिकांश आधुनिक कोडबेस ऊपर जैसी लिटरल-यूनियन टाइप को प्राथमिकता देते हैं,
क्योंकि वे सरल हैं, साफ़-साफ़ सादी स्ट्रिंग में मिट जाते हैं, और JSON के साथ अच्छे से चलते हैं।
जानने योग्य यूटिलिटी टाइप
एक बार आपके पास एक सटीक इंटरफ़ेस हो, तो TypeScript के अंतर्निहित यूटिलिटी टाइप
आपको उसे दोबारा लिखे बिना नया आकार देने देते हैं। Partial हर प्रॉपर्टी को वैकल्पिक
बना देता है (किसी "अपडेट" पेलोड के लिए उपयोगी जहाँ कोई भी फ़ील्ड भेजा जा सकता है);
Required इसका उल्टा करता है; Pick और Omit किसी बड़े
टाइप के कुछ फ़ील्ड से एक छोटा टाइप बनाते हैं; Readonly परिवर्तन रोकता है; और
Record स्ट्रिंग-की वाले डिक्शनरी का वर्णन करता है। यहाँ आधार इंटरफ़ेस जनरेट करके
फिर उससे ये विविधताएँ प्राप्त करना आपके टाइप को DRY रखता है — सत्य का एक स्रोत, अनेक आकृतियाँ —
ताकि अंतर्निहित डेटा-आकृति में कोई बदलाव केवल एक ही जगह करना पड़े।
एक व्यावहारिक वर्कफ़्लो
एक भरोसेमंद पैटर्न है: असली API को एक बार कॉल करें, एक प्रतिनिधि प्रतिक्रिया कॉपी करें, उसे
यहाँ पेस्ट करें, और रूट इंटरफ़ेस का नाम एंडपॉइंट से मिलाएँ। स्पष्ट enum-जैसी स्ट्रिंगों को
लिटरल यूनियन में सँकरा करें, वैकल्पिक चिह्नों को API के दस्तावेज़ के विरुद्ध पुष्टि करें, और किसी
भी unknown[] को असली एलिमेंट-टाइप से बदलें। किसी विश्वास-सीमा को पार करने वाले
डेटा के लिए, उसी आकृति को Zod या JSON Schema वैलिडेटर के रूप में फिर से बनाएँ ताकि रनटाइम जाँच
और स्थैतिक टाइप एक-साथ बने रहें। इस तरह किया जाए तो एक JSON सैंपल थकाऊ हाथ-अनुवाद के बजाय कुछ
ही मिनटों में एक पूरी तरह टाइप्ड, वैलिडेटेड मॉडल बन जाता है।
अक्सर पूछे जाने वाले सवाल
- क्या यह गहरे नेस्टेड ऑब्जेक्ट संभालता है?
- हाँ। जनरेटर पूरे JSON ट्री को पुनरावर्ती (recursive) रूप से चलता है। हर नेस्टेड ऑब्जेक्ट अपना नामित interface बन जाता है, और मूल इंटरफ़ेस उन चाइल्ड इंटरफ़ेसों को नाम से संदर्भित करते हैं। इंटरफ़ेस सबसे गहरे-पहले (deepest-first) उत्पन्न होते हैं ताकि आउटपुट ऊपर-से-नीचे बिना आगे के संदर्भ (forward reference) के कंपाइल हो।
- मिश्रित टाइप वाली ऐरे के साथ क्या होता है?
- जब किसी ऐरे के सभी एलिमेंट प्रिमिटिव (string, number, boolean) होते हैं, तो जनरेटर एक यूनियन ऐरे टाइप बनाता है जैसे (string | number)[]। जब एलिमेंट ऑब्जेक्ट होते हैं, तो यह हर एलिमेंट में देखी गई सभी कीज़ को मर्ज कर देता है — कोई की जो कुछ एलिमेंट में मौजूद हो पर सभी में नहीं, उसे वैकल्पिक (?) चिह्नित किया जाता है ताकि टाइप ऐरे की सभी आइटम्स का सही प्रतिनिधित्व करे।
- ? (वैकल्पिक) चिह्न का क्या मतलब है?
- ? से चिह्नित प्रॉपर्टी वैकल्पिक है — व्यवहार में यह कुछ ऑब्जेक्ट से अनुपस्थित हो सकती है। जनरेटर तब ? जोड़ता है जब सैंपल JSON में किसी की का मान null हो (यह संकेत कि असल मान अनुपस्थित हो सकता है), या जब कोई की ऑब्जेक्ट-ऐरे के कुछ पर सभी एलिमेंट में नहीं दिखती। TypeScript में, एक वैकल्पिक प्रॉपर्टी ऑब्जेक्ट से पूरी तरह ग़ायब हो सकती है — यह उस प्रॉपर्टी से अलग है जो मौजूद है पर स्पष्ट रूप से null है।
- क्या मैं यह आउटपुट सीधे TypeScript में इस्तेमाल कर सकता हूँ?
- हाँ। जनरेट किए गए इंटरफ़ेस मानक TypeScript सिंटैक्स का उपयोग करते हैं और export किए गए हैं, इसलिए आप इन्हें सीधे किसी .ts या .d.ts फ़ाइल में पेस्ट कर सकते हैं। आप अपनी डोमेन-जानकारी के अनुसार इंटरफ़ेस का नाम बदलना या वैकल्पिकता समायोजित करना चाह सकते हैं — जनरेटर एक ही सैंपल JSON से टाइप का अनुमान लगाता है, इसलिए यह नहीं जान सकता कि हर मामले में कौन-से फ़ील्ड वास्तव में अनिवार्य हैं।
- ऑब्जेक्ट की ऐरे को मैं कैसे संभालूँ?
- जब किसी ऐरे में ऑब्जेक्ट होते हैं, तो जनरेटर एलिमेंट-टाइप के लिए एक नामित interface बनाता है — उदाहरण के लिए, की users: [{...}] एक interface Users {...} बनाती है और प्रॉपर्टी को users: Users[] टाइप देती है। यदि ऐरे के अलग-अलग ऑब्जेक्ट में अलग-अलग कीज़ हों, तो सभी कीज़ मर्ज हो जाती हैं और कम-से-कम एक एलिमेंट से ग़ायब कोई भी की वैकल्पिक चिह्नित होती है।
- यदि मेरे JSON में ऐसी कीज़ हों जो मान्य TypeScript पहचानकर्ता (identifier) नहीं हैं तो?
- ऐसी कीज़ जिनमें स्पेस, हाइफ़न, डॉट हों या जो अंक से शुरू होती हों, मान्य TypeScript पहचानकर्ता नहीं हैं। जनरेटर इन्हें पहचानकर उद्धरण-चिह्नों में लपेट देता है — उदाहरण के लिए "my-key"?: string — जो मान्य TypeScript ऑब्जेक्ट-टाइप सिंटैक्स है। फिर आप ऐसी प्रॉपर्टीज़ को ब्रैकेट नोटेशन से एक्सेस कर सकते हैं: obj["my-key"]।
- क्या यह interface के बजाय Zod स्कीमा या type एलियास आउटपुट कर सकता है?
- हाँ। टूल के ऊपर दिए "आउटपुट" चयनकर्ता से टारगेट को TypeScript type एलियास या Zod v3 स्कीमा में बदलें। Zod आउटपुट उसी अनुमानित आकृति से बनता है — स्ट्रिंग z.string() बनती है, नंबर z.number(), नेस्टेड ऑब्जेक्ट z.object({...}), ऐरे z.array(...) और वैकल्पिक कीज़ को .optional() मिलता है — और इसमें import { z } from "zod" लाइन शामिल होती है, इसलिए यह पेस्ट करने को तैयार है। Zod तब चुनें जब आपको केवल कंपाइल-टाइम टाइप नहीं, बल्कि रनटाइम वैलिडेशन चाहिए।