Theory
एक Helpful Note, एक Dead Feed
एक conscientious teammate events.json खोलता है और, future readers की मदद करना चाहते हुए, add करता है:
// seat counts updated every evening by Priya
वह save करता है। FestConnect का schedule page blank हो जाता है। Console report करता है JSON.parse ने line 1 पर एक SyntaxError throw किया।
JavaScript में, वह comment perfectly legal है। JSON में, ऐसी कोई चीज़ comment नहीं है, और यह lesson इस बात की कहानी है कि यह एक gap नहीं, एक decision है।
Practical
Rejection खुद देखिए (इसे Run कीजिए)
// This string contains JSON with a comment inside it:
const annotated = `{
// updated every evening by Priya
"name": "Garba Night",
"seats": 350
}`;
try {
JSON.parse(annotated);
} catch (e) {
console.log("Parser said: " + e.message); // SyntaxError
}
// The same data, uncommented, parses fine:
const clean = '{ "name": "Garba Night", "seats": 350 }';
console.log(JSON.parse(clean).name);
This example runs in Gri-Learn on the web, where you can edit it and see the output.
Theory
Design से Absent
JSON के creator, Douglas Crockford, ने format से comments deliberately हटाए, और उनके stated reasons exam-friendly हैं:
- Purity: JSON एक minimal DATA interchange standard है; एक data file को data carry करना चाहिए, और कुछ नहीं
- Abuse Prevention: early use में, उन्होंने देखा comments parsing directives में बदल दिए जा रहे थे (specific parsers के लिए instructions), जो चुपचाप इस promise को तोड़ते थे कि कोई भी JSON हर जगह same मतलब रखता है
Simplicity ही है जो हर language के JSON parser को छोटा और behaviour में identical रखती है। Grammar closed रही: कहीं भी कोई // नहीं, कोई /* */ नहीं।
Theory
Teams इसके बजाय क्या करती हैं
Real projects को अभी भी अपना data explain करना ज़रूरी है। 3 honest routes:
- Self-Documenting Names:
"seatsUpdatedDaily": trueखुद को explain करता है; अच्छे key names पहली documentation हैं - External Docs: API documentation या एक schema file हर field describe करती है: professional standard
- एक Note की तरह Data Field:
"_comment": "seats updated evenings": legal, visible... और एक असली comment NAHI: यह हर copy के साथ travel करता है, bytes cost करता है, और consuming code को इसे ignore करना ज़रूरी है। Sparingly इस्तेमाल कीजिए, अगर बिल्कुल भी
Quiz
जब JSON.parse को valid data के ऊपर // a note वाली एक file मिलती है तो क्या होता है?
- Comment skip हो जाता है और data normally parse होता है
- यह एक SyntaxError throw करता है: standard JSON में बिल्कुल कोई comment syntax नहीं है
- Comment एक special _comment property में parse हो जाता है
- सिर्फ़ /* */ block comments allowed हैं; // line comments fail होते हैं
Show the answer
यह एक SyntaxError throw करता है: standard JSON में बिल्कुल कोई comment syntax नहीं है
Grammar में comments के लिए बस कोई production नहीं है, तो parser पहले slash पर fail होता है: hook का blank-page bug। Option A JavaScript की खुद की tolerance describe करता है, exact वह habit जो यह landmine plant करती है। Option C reality को उल्टा करता है: _comment एक manual CONVENTION है जो कुछ teams adopt करती हैं, कभी कुछ नहीं जो parsers बनाते हैं। Option D एक half-permission invent करता है; दोनों comment styles equally illegal हैं। Related exam row: XML के पास असली comments HAIN (<!-- -->), Unit 3 comparison में इसके genuine advantages में से एक।
Think first
पर VS Code की settings.json में तो Comments हैं...
आपने शायद एक .json file में comments काम करते हुए DEKHE हैं: VS Code की settings, कुछ config files। Tap करने से पहले: इस sighting को इस lesson के हर claim से reconcile कीजिए।
Show the answer
वे files standard JSON नहीं हैं: वे JSONC (JSON with Comments) या JSON5 जैसे similar supersets हैं, जिन्हें specific TOOLS human-edited configs के लिए accept करना चुनते हैं। File extension .json रही; format चुपचाप नहीं रहा। जो boundary hold करनी है: एक tool के config के अंदर, tool rules बनाता है; DATA INTERCHANGE में (APIs, events.json, कोई भी चीज़ जो कोई और program fetch करे), सिर्फ़ standard JSON safe है, और comments असली consumers तोड़ देंगे। Exam sentence: JSONC जैसे supersets comments allow करते हैं, पर standard JSON नहीं करता, और interchange को standard ही assume करना चाहिए।
Watch out
Practice में यह कहाँ काटता है
Live Data Files को Hand-Editing करना: helpful-note reflex exactly वहाँ सबसे strong है जहाँ यह सबसे fatal है: shared .json feeds।
Config Habits को APIs में Copy करना: tool configs से एक JSONC habit उसी moment टूट जाती है जब एक strict parser (जो इनमें से हर एक है) इससे मिलता है।
Big Data में _comment Field: 10000 records जिनमें हर एक "_comment": "..." carry करता है वह documentation है जो bandwidth में paid है, per request, forever।
Theory
Unit 3 बंद होती है: JSON पूरी तरह आपका है
अब आप JSON define कर सकते हैं, इसे XML के against argue कर सकते हैं, सही typed strings और numbers वाले objects लिख सकते हैं, सारे 5 array shapes wield कर सकते हैं, और explain कर सकते हैं वह एक चीज़ जिसे यह contain करने से मना करता है। events.json complete है और honest तरीके से documented है (अच्छे names, बाहर रखे notes)। Unit 4 आख़िरकार इसे move करती है: AJAX और XMLHttpRequest, जहाँ browser page reload किए BINA server से यह file fetch करता है, और Unit 1 से सब कुछ साथ click होता है।
Summary
Key takeaways
- Standard JSON में कोई comments नहीं हैं: // और / / JSON.parse को एक SyntaxError throw कराते हैं।
- यह absence Crockford का design है: data interchange की purity, और comment-abuse को parser directives की तरह रोकना।
- इसके बजाय self-explaining key names और external docs से document कीजिए; "_comment" data fields एक legal पर costly convention हैं।
- JSONC/JSON5 supersets (VS Code configs) comments allow करते हैं पर standard JSON नहीं हैं: APIs में कभी नहीं।
- XML के पास असली comments हैं; JSON के पास नहीं: एक standing comparison row।
- Data files data carry करती हैं; explanations documentation में रहती हैं।
- Memory hook: JSON facts carry करता है, कभी footnotes नहीं।