Objects: values with names instead of positions

An array is the right shape when the values are the same kind of thing and their order means something: stops on a route, scores in a game, lines on an invoice. It is the wrong shape the moment the values mean different things.

Imagine storing one person as `['Ada', 36, true]`. What is index 1? You would have to remember, and so would everyone who reads your code, and everyone who adds a fourth value has to insert it in the agreed place forever. The position carries no meaning, so all the meaning lives in your head.

The fix is to label each value with a name instead of a number: `{ name: 'Ada', age: 36, active: true }`. That is an object, and the improvement is not that it can hold more — it is that the code now says what it means without a comment.

You write an object with curly braces, and inside them a list of `name: value` pairs separated by commas: `const user = { name: 'Ada', age: 36 };`. Each pair is a property. The name on the left is the key, and the thing on the right is the value.

Keys are text. You can write them unquoted when they look like ordinary names, and MDN calls the whole `{ ... }` form an object initializer or object literal. Values can be anything at all — numbers, strings, booleans, `null`, other objects, arrays, even functions.

Unlike an array, an object has no order that you should rely on and no `length`. It is a set of labelled slots, and you reach into it by name.

Dot notation is the one you will write most: `user.name`. You type the key directly after the dot, exactly as it is spelled.

Bracket notation takes an expression instead: `user['name']`. Those two lines do the same thing, because the expression `'name'` evaluates to the string `name`. The difference only appears when the thing in the brackets is not a literal.

Writing to a property uses the same two forms with `=` after them: `user.age = 37` changes an existing property, and `user.city = 'London'` creates one that did not exist. There is no separate syntax for adding — assignment is how properties come into being.

MDN sets out the rule plainly: a property name that has a space or a hyphen, that starts with a number, or that is held inside a variable, can only be read with bracket notation. Dot notation needs a literal identifier, and those names are not identifiers.

The third case is the one that matters most in practice. If a variable `key` currently holds the string `'name'`, then `user[key]` reads the `name` property — but `user.key` looks for a property literally spelled k-e-y, which almost certainly does not exist, so you get `undefined` and no warning.

Read it this way and it stops being confusing: after a dot, you are typing the key. Inside brackets, you are computing the key. Whenever the key is decided while the program runs rather than while you type, you need brackets.

MDN states it directly: nonexistent properties of an object have the value `undefined`, and not `null`. Reading `user.email` on an object that has no email is not an error.

That is convenient and it is also the reason a spelling mistake can survive for days. `user.nmae` is `undefined`, exactly like a property you genuinely have not set yet, so nothing distinguishes the typo from the legitimate absence at the point where you made it.

There are two ways to ask whether a property is actually there. `'age' in user` is `true` when the object has that property, whatever its value. `Object.hasOwn(user, 'age')` asks the same question about the object's own properties. Both differ from `user.age !== undefined` in one case: a property that exists and was deliberately set to `undefined`.

Objects are not sealed when you create them. `stock.plums = 7` adds a property, assigning to an existing key replaces its value, and `delete stock.pears` removes a property entirely.

This is true even when the object was declared with `const`. `const` protects the name from being pointed at a different value — it does nothing about the contents. `const user = {}; user.name = 'Ada';` is completely legal, and it surprises almost everyone once. Lesson 6 explains exactly why.

Being able to reshape an object freely is powerful and easy to abuse. Code where objects sprout properties in twelve different places is code nobody can predict, which is why Module 9 spends its time on choosing a shape and sticking to it.

Three built-in functions turn an object into an array, which is the bridge between the two shapes in this module. `Object.keys(obj)` gives an array of the property names, `Object.values(obj)` an array of the values, and `Object.entries(obj)` an array of `[key, value]` pairs.

Because they hand you arrays, everything you learned in the first two lessons applies: `Object.keys(user).length` is how many properties an object has.

One detail to file away. Keys always come back as strings, even if you wrote them as numbers, and keys that look like non-negative integers come first in numeric order regardless of the order you wrote them in. `Object.keys({ 2: 'b', 1: 'a' })` is `['1', '2']`. If ordering matters to you, use an array.

An object labels its values with names instead of positions. Dot notation types the key; bracket notation computes it, which is why a key held in a variable needs brackets. Reading a property that is not there gives `undefined`, so a typo and a genuine absence look the same. `Object.keys`, `Object.values` and `Object.entries` turn an object back into arrays.