What exactly does the spread syntax copy in `const copy = [...items]` or `const next = {...state}`, and what bug appears once the data has a nested level?

## One level, always exactly one Spread evaluates the source and copies its values into a brand-new container. For an array, `[...items]` iterates the source and appends each produced value to a fresh array. For an object, `{...state}` copies the source's own enumerable properties onto a fresh object. In both cases the *values* are copied — and in JavaScript a variable or property holding an object holds a reference to it, not the object itself. Copying the value therefore copies the reference. ```js const items = [{ id: 1 }, { id: 2 }]; const copy = [...items]; copy === items; // false — new array copy[0] === items[0]; // true — same inner object copy.push({ id: 3 }); // items is unaffected: length still 2 copy[0].id = 99; // items[0].id is now 99 as well ``` That pair of results is the whole concept: the *container* is independent, the *contents* are shared. ## Why this shows up as a state bug The idiom that made spread ubiquitous is the immutable update — produce a new value instead of mutating the old one, so that anything comparing the before and after by identity can tell something changed. Spread does that correctly for the level you spread, and silently fails for anything below it: ```js const state = { count: 0, user: { name: 'ada', prefs: { theme: 'dark' } } }; // Correct at the top level const a = { ...state, count: 1 }; a !== state; // true — a genuinely new object // Broken one level down const b = { ...state }; b.user.name = 'grace'; state.user.name; // 'grace' — the original mutated b.user === state.user; // true — nothing looks changed to an identity check ``` Two distinct symptoms follow. First, the "old" value is retroactively corrupted, which destroys undo history, memoized snapshots and anything that logged the previous state. Second, code that compares by reference concludes nothing changed, because `b.user` and `state.user` are the same object — the mutation is invisible to the very mechanism the copy existed to serve. ## Copying the path you touch The standard fix is to spread each level along the path being updated, leaving untouched branches shared (which is fine, because they are never mutated): ```js const next = { ...state, user: { ...state.user, prefs: { ...state.user.prefs, theme: 'light' } }, }; next !== state; // true next.user !== state.user; // true next.user.prefs.theme; // 'light' state.user.prefs.theme; // 'dark' — untouched ``` For arrays of objects the same rule applies: `[...list]` is enough to insert or remove an entry, but replacing a field inside one entry needs a new object for that entry, typically produced with `map` returning `{ ...entry, done: true }` for the matching item. When the shape is arbitrary or deeply nested, hand-spreading every level becomes unreadable and error-prone; that is the point at which a real deep copy, or a data model that keeps nesting shallow, is the better answer. ## Things people wrongly expect spread to do - **Recurse.** It never does, at any depth, for arrays or objects. - **Preserve holes.** `[...[1, , 3]]` yields `[1, undefined, 3]`: the array iterator produces `undefined` for a hole, so the copy is dense. - **Merge nested keys.** `{...a, ...b}` replaces a shared key's value wholesale with `b`'s; it does not merge two nested objects. - **Copy non-enumerable or inherited properties.** Object spread takes only own enumerable properties. ## Answering it well State the rule in one sentence (new container, shared contents), show the `copy[0] === items[0]` check that proves it, then name the concrete failure: a nested mutation that both corrupts the original and defeats identity-based change detection. Finishing with the layered-spread fix and the honest caveat that it stops scaling at three or four levels is what turns a definition into an answer.