Shapes inside shapes

So far every array has held single values and every object has held single values. Real data almost never looks like that. An order has a customer; a customer has an address; an order has lines, and each line is itself an item with a quantity and a price.

You do not need anything new for this. An array element can be an object. An object's value can be an array. That is the whole feature — the pieces you already know simply nest inside each other, as deep as the data requires.

What is new is the reading. A path like `order.customer.address.city` looks like one operation and is actually four, and knowing that is the difference between debugging it in thirty seconds and staring at it for an hour.

Read `order.customer.address.city` strictly left to right. Start with `order`, which is an object. Take its `customer` property, which gives you another object. Take that object's `address` property, which gives another object. Take that object's `city` property, which is finally a string.

Each step produces a value, and the next step is applied to that value. Every intermediate result has to be something that can have properties, or the next step cannot happen.

This is why printing the steps is such an effective debugging technique. If `order.customer.address.city` is not what you expect, print `order.customer`, then `order.customer.address`, and the first one that is `undefined` tells you exactly where the data stopped matching your assumption.

The single most common structure in real programs is an array whose elements are objects — a list of users, a list of order lines, a list of search results. Each element has the same keys, and the array supplies the order.

Reading one of them alternates the two operations you already know: square brackets when the current value is an array, a dot when it is an object. `order.items[0].name` is a dot, then an index, then a dot.

Do not be put off by the length of these expressions. There is no new rule in `order.items[0].name` — it is just the same two moves taken in turn.

You already know that reading a property that does not exist gives `undefined`. `order.customer.email` on a customer with no email is simply `undefined`, and nothing goes wrong.

Now try to step through that `undefined`. `order.delivery.address`, where the order has no `delivery` property, asks `undefined` for a property — and that is a TypeError. The program stops there, with a message saying it cannot read a property of `undefined`.

So the rule is not check everything, it is check anything you intend to step through. The last step in a path is safe; every step before it is a place the walk can fall over. This is exactly what Lesson 7's `?.` operator is for, but do the checking by hand first — the operator is much easier to use well once you know what it is replacing.

`typeof []` is `'object'`, and so is `typeof {}` and `typeof null`. `typeof` is not a good tool for telling these apart, which surprises people who reach for it first.

`Array.isArray(value)` is the reliable way to ask whether something is an array. It is `true` for arrays and `false` for plain objects, `null`, strings and everything else.

The reason arrays report as objects is that an array really is an object with numeric keys and a `length` that maintains itself. You do not need that fact to use arrays, but it explains why `list[-1]` quietly gives `undefined` rather than complaining: it is just another key that has never been set.

When you design a nested shape, the first question is whether each level is a list or a lookup. A list keeps order and allows duplicates: `[{ id: 'a' }, { id: 'b' }]`. A lookup finds one thing instantly by name: `{ a: { ... }, b: { ... } }`.

Lists are the right default when order matters or when you will present the whole thing in sequence. Lookups are right when you mostly need to answer what is the record for this id, because finding it costs nothing rather than requiring a search.

You do not have to choose forever — Module 9 is about converting between the two and deciding deliberately. For now, notice which one your data wants, and be able to say why.

Nesting adds no new syntax: arrays hold objects, objects hold arrays, and you read them with a dot or an index depending on what the previous step gave you. Reading a missing last step is `undefined`; stepping through a missing middle step is a TypeError. `Array.isArray` is how you tell an array from a plain object, because `typeof` says `object` for both.