Theory
એક helpful note, એક dead feed
એક conscientious teammate events.json ને open કરે છે અને, future readers ને help કરવા માંગીને, ઉમેરે છે:
// seat counts updated every evening by Priya
તે save કરે છે. FestConnect નું schedule page blank થઈ જાય છે. console report કરે છે કે JSON.parse SyntaxError throw કરે છે line 1 પર.
JavaScript માં, તે comment perfectly legal છે. JSON માં, કોઈ comment જેવી વસ્તુ નથી, અને આ lesson એ story છે કે શા માટે તે decision છે, gap નહીં.
Practical
rejection ને yourself જુઓ (run it)
// આ string માં JSON છે comment સાથે અંદર:
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
}
// same data, uncommented, fine parses થાય છે:
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
Absent by design
JSON ના creator, Douglas Crockford, એ comments ને format માંથી deliberately remove કર્યા, અને તેના stated reasons exam-friendly છે:
- Purity: JSON એ minimal DATA interchange standard છે; data file એ data ને carry કરવું જોઈએ, કંઈ બીજું નહીં
- Abuse prevention: early use માં, તેણે observe કર્યું કે comments ને parsing directives (specific parsers ને instructions) તરીકે turned કરવામાં આવતા હતા, જે silently promise ને break કરતું હતું કે કોઈ પણ JSON નો અર્થ બધે same થાય છે
Simplicity એ જ છે જે દરેક language ના JSON parser ને small અને identical behaviour માં રાખે છે. grammar closed રહ્યું: કોઈ // નહીં, કોઈ /* */ નહીં, nowhere.
Theory
teams શું instead કરે છે
Real projects ને હજુ તેમના data ને explain કરવાની જરૂર છે. 3 honest routes:
- Self-documenting names:
"seatsUpdatedDaily": trueપોતે explain કરે છે; good key names એ first documentation છે - External docs: API documentation અથવા schema file દરેક field ને describe કરે છે: professional standard
- note તરીકે data field:
"_comment": "seats updated evenings": legal, visible... અને real comment નથી: તે દરેક copy સાથે travels કરે છે, bytes consume કરે છે, અને consuming code એ તેને ignore કરવું પડે છે. Use sparingly, જો at all
Quiz
શું થાય છે જ્યારે JSON.parse valid data ની ઉપર // a note ધરાવતી file ને meet કરે છે?
- comment ને skipped કરવામાં આવે છે અને data normally parses થાય છે
- તે SyntaxError throw કરે છે: standard JSON પાસે કોઈ comment syntax નથી at all
- comment ને special _comment property માં parse કરવામાં આવે છે
- ફક્ત /* */ block comments allowed છે; // line comments fail થાય છે
Show the answer
તે SyntaxError throw કરે છે: standard JSON પાસે કોઈ comment syntax નથી at all
grammar માં comments માટે કોઈ production નથી, તેથી parser first slash પર fail થાય છે: teammate નું blank-page bug hook થી. Option A JavaScript ની own tolerance ને describe કરે છે, exact habit જે આ landmine ને plants કરે છે. Option C reality ને inverts કરે છે: _comment એ manual CONVENTION છે જેને some teams adopt કરે છે, ક્યારેય કંઈ parsers create નથી કરતા. Option D half-permission ને invent કરે છે; બંને comment styles equally illegal છે. Related exam row: XML પાસે real comments છે (<!-- -->), Unit 3 comparison નો એક genuine advantages.
Think first
પણ VS Code ના settings.json માં comments છે...
તમે probably comments ને .json file માં working જોયા હશે: VS Code ના settings, some config files. tap કરતા પહેલાં: તે sighting ને reconcile કરો આ lesson જે claims કરે છે તેની સાથે.
Show the answer
તે files standard JSON નથી: તેઓ JSONC (JSON with Comments) અથવા similar supersets છે જેમ કે JSON5, જે specific TOOLS choose કરે છે accept કરવા માટે human-edited configs માટે. file extension .json જ રહ્યું; format quietly did not. boundary hold કરવા માટે: એક tool ના config ની અંદર, tool rules બનાવે છે; DATA INTERCHANGE માં (APIs, events.json, કંઈ પણ જે બીજું program fetch કરે છે), ફક્ત standard JSON safe છે, અને comments real consumers ને break કરશે. Exam sentence: supersets જેમ કે JSONC comments ને allow કરે છે, પણ standard JSON નથી કરતું, અને interchange એ standard ને assume કરવું પડે.
Watch out
જ્યાં આ practice માં bites કરે છે
Hand-editing live data files: helpful-note reflex strongest છે exactly જ્યાં તે most fatal છે: shared .json feeds.
APIs માં config habits ને Copying કરવું: tool configs થી JSONC habit break થાય છે moment જે strict parser (which is all of them) તેને meet કરે છે.
big data માં _comment field: 10000 records દરેક "_comment": "..." ને carry કરે છે documentation paid for in bandwidth, per request, forever.
Theory
Unit 3 closes: JSON fully yours છે
તમે હવે JSON ને define કરી શકો છો, તેને XML સામે argue કરી શકો છો, correctly typed strings અને numbers સાથે objects ને write કરી શકો છો, બધા 5 array shapes ને wield કરી શકો છો, અને એક વસ્તુ ને explain કરી શકો છો જે તે contain કરવા refuse કરે છે. events.json complete છે અને honest way થી documented છે (good names, notes kept outside). Unit 4 finally તેને move કરે છે: AJAX અને XMLHttpRequest, જ્યાં browser આ file ને server થી fetch કરે છે page ને reload કર્યા વગર, અને everything since Unit 1 clicks together.
Summary
Key takeaways
- Standard JSON પાસે કોઈ comments નથી: // અને / / JSON.parse ને SyntaxError throw કરાવે છે.
- absence એ Crockford નું design છે: data interchange ની purity, અને comment-abuse ને prevent કરવું parser directives તરીકે.
- instead document કરો self-explaining key names અને external docs દ્વારા; "_comment" data fields legal પણ costly convention છે.
- JSONC/JSON5 supersets (VS Code configs) comments ને allow કરે છે પણ standard JSON નથી: ક્યારેય APIs માં નહીં.
- XML પાસે real comments છે; JSON પાસે નથી: standing comparison row.
- Data files data ને carry કરે છે; explanations documentation માં live થાય છે.
- Memory hook: JSON facts ને carry કરે છે, ક્યારેય footnotes નહીં.