Changing data without breaking it

When you write const b = a and a holds a number, b gets its own copy of that number and the two go their separate ways forever. When a holds an object, something different happens: b does not get a copy of the object. It gets a second name for the same object.

That is not a quirk to be worked around; it is how every language of this kind works, and it is what makes it possible to pass a large record to a function without copying it. But it does mean that a change made through one name is visible through the other, immediately, and that surprises everyone the first time.

It also explains something that looked odd in lesson 3: the lookup table you built holds the same record objects as the array it came from. Two views, one set of objects. Editing through the table edits what the array sees, because there was only ever one thing there.

const does not help here. const stops the NAME from being pointed at something else; it says nothing at all about whether the thing itself can be changed. A const object is fully editable, and a great many people lose an afternoon to that once.

Think of an object as a whiteboard in a shared room. Handing someone the object is telling them where the room is. It is not handing them a photocopy.

So when they rub something out, everyone who knows where the room is sees it gone — including you, and including the part of your program that had no idea anyone else was writing on it.

Copying is deliberate: you go to the room and photograph the board. Now you have your own picture and can scribble on it freely. The catch, and it is the important one, is that if the board had a note saying "see the other room for the details", your photograph has that note too. It does not have a copy of the other room.

The standard move is to build a new object that starts as a copy of the old one and then overrides the parts you want different. { ...user, name: "Grace" } means: take every property of user, then set name to Grace, and make that a brand new object.

Order inside the braces decides who wins, and later wins. { ...user, name: "Grace" } overrides user's name; { name: "Grace", ...user } is overridden BY user and does nothing useful. This is worth burning in, because both spellings look reasonable at a glance.

A property that already existed keeps its original position when you override it, so the field order of your records stays stable. A property that did not exist is appended at the end. That predictability is what makes records readable in logs and diffs.

Arrays have the same pattern: [...list, newItem] to append, [...list.slice(0, i), newValue, ...list.slice(i + 1)] to replace one position, and list.filter(...) to remove. All of them return a new array and leave the original alone.

Spread copies one level deep and no further. If a property holds another object, the copy gets the same pointer to that same nested object — not a copy of it.

So { ...user } gives you a new user you can safely rename, and a nested address that is still shared with the original. Change copy.address.city and the original's city changes too, because there is exactly one address object and both users are pointing at it.

This is the single most common source of "I copied it and it still changed" confusion. The copy did work. It just did not go as deep as you assumed.

The fixes, in order of preference: spread the nested part too, { ...user, address: { ...user.address, city: "Paris" } }, which is explicit about exactly what is being replaced; or, when the data is plain and you genuinely want everything deep-copied, use the JSON round trip from lesson 2 with its losses in mind (no undefined, no Dates, no Maps). Browsers also offer structuredClone for this, though it is not available in this page's sandbox.

There is no way to deduce this from the names, so it is worth learning as a list. These MUTATE the array they are called on: push, pop, shift, unshift, splice, sort, reverse, fill and copyWithin.

These return a new array and leave the original alone: map, filter, slice, concat, flat, flatMap, and spreading with [...]. Newer engines add toSorted, toReversed, toSpliced and with, which are the non-mutating twins of the first list.

sort and reverse are the two that catch people, because they also RETURN the array, so const sorted = scores.sort() looks like it made a copy. It did not: sorted and scores are the same array, and scores is now in a different order. Write scores.slice().sort(...) — or toSorted(...) — when the original must survive.

One more sort surprise, unrelated to mutation: with no compare function, sort converts every element to a string and sorts by text. That puts 10 before 9. Numbers need an explicit comparison, sort((a, b) => a - b), every single time.

A function that changes what it was given has an effect nobody reading the call can see. update(basket) tells you nothing; const next = withQuantity(basket, sku, 2) tells you everything, including that the old basket is still there if you need it.

It also makes comparison possible. If updates always produce a new object, then oldValue !== newValue is a reliable, instant test of whether anything changed — which is precisely how user-interface libraries decide what to redraw, and why this style is so common in modern JavaScript.

And it makes bugs local. When data can only be changed by producing a new version, the list of places that could have caused a wrong value is the list of places that built one — not every line in the program that ever held a reference to it.

The cost is real but small: a little more memory and a few more characters. Pay it by default for shared data, and mutate freely inside a function on values that function created itself, where nobody else can see.

Assigning an object gives a second name for one thing, and const protects the name rather than the contents. Copy-then-override with spread produces a changed copy; later entries win, and existing keys keep their position. Spread is shallow, so nested objects stay shared unless you spread them too. push, splice, sort and reverse change the array in place; map, filter, slice and concat return a new one.