Theory
One event was never the point
Last lesson perfected the single event record. But FestConnect's reality is plural: a LIST of 40 events, a list of ticket prices, a hall's seat map with rows and columns of booked-or-free.
XML faked lists by repeating elements. JSON has the real thing: the array, ordered values in square brackets, and your syllabus names 5 shapes of it. All 5 obey one grammar; what changes is only what sits inside the brackets.
Theory
The array, formally
A JSON array is an ordered, comma-separated list of values in square brackets:
["Garba Night", "Coding Contest", "Robo Race"]
Properties that matter:
- ordered: position is meaning; after parsing, index from 0
- values may be ANY JSON type: strings, numbers, booleans, null, objects, arrays
.lengthcounts elements after parsing- mixing types in one array is legal, though real data keeps each array consistent
At a glance
The 5 syllabus forms, one fest each
| Form | Example | FestConnect meaning |
|---|---|---|
| Array of strings | ["Garba Night", "Robo Race"] | Event names |
| Array of numbers | [50, 100, 150] | Ticket price tiers |
| Array of booleans | [true, true, false] | Which fest days are open |
| Array of objects | [{"name": "Garba Night", "seats": 350}, ...] | THE events list itself |
| Multi-dimensional | [[1, 1, 0], [0, 1, 1]] | Seat map: rows of seats |
Practical
All 5 forms, parsed and walked (run it)
const text = `{
"names": ["Garba Night", "Coding Contest", "Robo Race"],
"prices": [50, 100, 150],
"daysOpen": [true, true, false],
"events": [
{ "name": "Garba Night", "seats": 350 },
{ "name": "Coding Contest", "seats": 60 }
],
"seatMap": [[1, 1, 0],
[0, 1, 1]]
}`;
const d = JSON.parse(text);
console.log(d.names[0]); // Garba Night (index from 0)
console.log(d.prices.length); // 3
console.log(d.events[1].name); // Coding Contest: index, then key
console.log(d.seatMap[1][2]); // 1: row index 1, seat index 2
for (const ev of d.events) { // the loop every fest page runs
console.log(ev.name + ": " + ev.seats + " seats");
}
This example runs in Gri-Learn on the web, where you can edit it and see the output.
Theory
Reading a chained access
The 2 compound forms deserve slow motion.
Array of objects: d.events[1].name reads right to left as a path: in d, take events (an array), take element index 1 (the SECOND object), take its name. Index first, then key.
Multi-dimensional: d.seatMap[1][2] is outer index then inner: row at index 1 (the second row [0, 1, 1]), then its element at index 2: the value 1, a booked seat. Row, then column, both from 0: the same discipline as BCA102's matrix positions.
Quiz
Using the listing's data: what does d.events[0].seats evaluate to?
- 350: the first event object's seats value
- 60: arrays index from 1, so events[0] does not exist
- The string "seats" itself
- undefined: objects inside arrays need a special accessor
Show the answer
350: the first event object's seats value
Index 0 is the FIRST element (Garba Night's object), and .seats plucks its number: 350. Option B imports 1-based counting; JSON arrays, like every JavaScript array, start at 0, so events[1] is the Coding Contest. Option C confuses the key's name with its value. Option D invents ceremony that does not exist: an array element that is an object answers to ordinary dot access, which is precisely why the array-of-objects form dominates real APIs: index into the list, then use it like any object.
Think first
Book seat row 0, seat 2
A student books the THIRD seat of the FIRST row in the listing's seatMap. Before tapping: which expression reads that seat's current value, what is it now, and what does the booking change it to?
Show the answer
First row = index 0, third seat = index 2: d.seatMap[0][2], currently 0 (free, since row 0 is [1, 1, 0]). Booking sets d.seatMap[0][2] = 1, making row 0 fully booked: [1, 1, 1]. The habit to internalise: translate human counting (first, third) into indexes (0, 2) BEFORE touching the brackets, outer dimension first. Off-by-one here books the wrong seat for a real person, which is how this stops being an exam point and starts being a refund queue.
Watch out
Array slips
Human counting: events[1] is the SECOND event: the eternal off-by-one.
Trailing comma: [50, 100, 150,] fails JSON.parse, same law as objects.
Assuming order survives everything: JSON arrays are ordered, but object KEYS are not promised any order: rely on array positions, never on key positions.
seatMap[2][0] on a 2-row map: row index 2 does not exist; reading it gives undefined and indexing INTO that undefined throws: check .length when rows vary.
Theory
You now read any API response
Arrays of objects with nested arrays IS the shape of real-world API data: a weather feed, a cricket scorecard, your own future endpoints. Practice: sketch tomorrow's canteen menu as JSON (days array, each day an object, each meal a string array) and walk it with chained access. One JSON topic remains, and it is a curiosity: the comment syntax JSON deliberately does NOT have, and what teams do instead.
Summary
Key takeaways
- Arrays: ordered, comma-separated values in [ ]; indexed from 0 after parsing; .length counts.
- Five forms: strings, numbers, booleans, objects, and arrays-in-arrays (multi-dimensional).
- Array of objects is the real-world king: d.events[1].name chains index, then key.
- Multi-dimensional access is outer-then-inner: seatMap[row][seat], both from 0.
- Element types may mix legally; consistent arrays are sane arrays.
- Array order is guaranteed; object key order is not.
- Memory hook: brackets hold the queue, count the queue from 0.