References: when two names mean one thing

For a number or a string, a variable holds the value itself. `let a = 5; let b = a; b = 6;` leaves `a` as 5, and nobody finds that surprising, because 5 was copied into `b`.

For an object or an array, the variable holds a reference — think of it as an address written on a card, with the actual object living somewhere else. The variable is the card, not the house.

Now everything else in this lesson follows. Copying the card gives you a second card with the same address, and both cards lead to the same house. Repainting the house is visible from both cards, because there is only one house. This single idea explains every surprise in this lesson, and most of the surprises in your first year of writing JavaScript.

`const other = original;` does not make a second object. It makes a second name for the one object. After that line, `other.count = 99` and `original.count = 99` are the same change, and `original === other` is `true`.

The same is true when you pass an object into a function. The parameter is another name for the caller's object, which is why a function that pushes into an array it was given has changed something the caller can see. That is the whole reason Lesson 2 made such a point of copying first.

To get a genuinely separate object you must ask for one: `{ ...original }`, `original.slice()`, or `Object.assign({}, original)`. Nothing else duplicates it.

`const list = [1, 2]; list.push(3);` is completely legal, and `list` is now three elements long. This astonishes almost everyone the first time, because `const` sounds like it should mean constant.

What `const` actually promises is that the name will never be pointed at a different value. `list = [4, 5]` is an error; `list.push(3)` is not, because the name still refers to the same array. The card cannot be swapped for a different address, but nothing stops you redecorating.

If you want the contents protected too, `Object.freeze(obj)` prevents properties from being added, removed or changed. In ordinary non-strict code an attempt to write to a frozen object fails silently rather than throwing, which makes freeze a weaker guarantee than it looks — useful as a guardrail, not as a lock.

`{ a: 1 } === { a: 1 }` is `false`. So is `[1, 2] === [1, 2]`. Both comparisons build two separate objects and then ask whether they are the same object, and they are not — identical contents, different addresses.

`===` on objects answers is this the same thing, never do these look alike. That is genuinely useful — it is how you check whether a function handed you back your own array or a copy — but it is not what people usually want when they write it.

To compare contents of plain data, `JSON.stringify(a) === JSON.stringify(b)` works and is easy to reach for. Know its limits before you rely on it: it is sensitive to key order, so `{a:1,b:2}` and `{b:2,a:1}` compare as different, and it silently ignores functions and properties holding `undefined`.

MDN defines a shallow copy as one whose properties share the same references as the source's. Spread, `slice`, `concat`, `Array.from` and `Object.assign` all produce shallow copies — there is no built-in that copies deeply.

The consequence is worth stating in the two halves MDN uses. Re-assigning a top-level property of the copy does not affect the source. Re-assigning a property of a nested object inside the copy does affect the source, because that nested object was never duplicated.

So `{ ...settings }` protects you against `copy.theme = 'light'` and does nothing at all about `copy.window.width = 1024`. A shallow copy is a fence around the outermost layer only.

When you need a structure that shares nothing, the portable trick is a round trip through text: `JSON.parse(JSON.stringify(value))`. Everything becomes a string on the way out, so there are no references left to share when it comes back.

Its limits are real and you should know them before you rely on it. Functions and properties holding `undefined` vanish, a `Date` comes back as a string, `NaN` and `Infinity` become `null`, and a structure that refers to itself throws. It is a good tool for plain data and a bad one for anything else.

Browsers and Node also provide `structuredClone`, which handles most of those cases properly. This sandbox does not have it — `typeof structuredClone` here is `'undefined'` — so the exercises use the JSON round trip. Knowing the difference means you will not be surprised when the same code behaves better outside the pad.

The classic version: a function is given a configuration object, tweaks a couple of properties on it, and returns it. Everything works until a second caller passes in the same shared default object, and now the defaults have been permanently edited by the first call.

The other classic: an array of items is copied with spread before editing, and the edit is made to one of the item objects inside it. The copy protected the list, not the items, so the original list's items changed too.

Both bugs look like action at a distance, and neither shows up where the mistake was made. The habit that prevents them is the one from Lesson 2, now with a reason attached: copy the level you are about to change, and know that copying one level is all you have done.

A variable holding an object holds a reference to it, so assignment and argument-passing hand out extra names for one thing. `const` freezes the name, not the contents. `===` compares identity, so identical-looking objects are not equal. Spread and slice copy one level; deeper structures stay shared unless you copy them too.