JavaScript Shallow Copy — Spot the Bug!

Why This Question Matters

If you've spent any time with JavaScript, you've probably encountered the "mutation nightmare." You change a value in one part of your app, and suddenly, a completely unrelated component or function starts behaving weirdly because the data it was relying on changed behind its back.

The core of this problem is how JavaScript handles types. Specifically, the difference between primitives (strings, numbers, booleans) and reference types (objects, arrays).

Many developers assume that using the spread operator (...) is a magic bullet for copying objects. It feels clean, it's concise, and it works perfectly for simple objects. But the moment you introduce nested data, you're no longer copying values—you're copying references. This is where bugs hide.

Understanding the Code

Let's look at the snippet again:

const original = { a: 1, b: { c: 2 } }
const clone = { ...original }
clone.b.c = 99
console.log(original.b.c) // Output: 99

At first glance, it looks like we're creating a new object. We use { ...original }, which creates a new object literal and copies the properties of original into it.

Here is what's actually happening under the hood:
1. a: 1 is a primitive. The value 1 is copied directly.
2. b: { c: 2 } is an object. In JavaScript, objects aren't stored directly in the variable; the variable holds a pointer (a reference) to a location in memory where the object actually lives.

When you spread original into clone, JavaScript copies that pointer. Now, both original.b and clone.b are pointing to the exact same spot in memory.

When you run clone.b.c = 99, you aren't changing the clone object's top-level structure; you're following the pointer to the nested object and changing a value inside it. Since original is looking at that same memory address, it "sees" the change. This is what we call a shallow copy.

Finding the Correct Answer

The challenge asks why this fails to deeply clone the object. The answer is that the spread operator only goes one level deep.

If you want a deep clone, you need a way to recursively copy every single level of the object tree, creating new memory references for every nested object or array encountered.

If you were looking for the correct way to fix this, you have a few options depending on your environment:

1. The Modern Way (Native API)
structuredClone() is now built into most modern browsers and Node.js. It's the current gold standard for deep cloning.

const clone = structuredClone(original);

2. The "Quick and Dirty" Way
You'll see people use JSON.parse(JSON.stringify(obj)). It works for simple data, but it's dangerous. It strips out functions, undefined, Date objects, and RegExp. I generally advise against this unless you're 100% sure your data is just plain JSON.

3. The Library Way
For complex state management, Lodash's _.cloneDeep() has been the industry standard for years. It handles edge cases that native methods sometimes miss.

Common Mistakes Developers Make

The most common mistake is assuming that "immutability" is automatic. In frameworks like React, you're told to never mutate state. Developers often do this:

const newState = { ...state };
newState.user.settings.theme = 'dark'; // BUG: This mutates the original state!

They think they're safe because they used the spread operator. But because user is an object and settings is another object, they've just mutated the global state tree, which can lead to components not re-rendering or, worse, unpredictable data corruption.

Another edge case is arrays. Spreading an array of objects [...myArray] does the same thing. You get a new array, but the objects inside that array are still references to the originals.

Real-World Usage

In production, this concept is critical when dealing with State Management (Redux, Zustand, Vuex). If you mutate a reference instead of returning a new object, the framework's "diffing" algorithm won't detect a change. It will see that the reference to the object is the same and skip the UI update, leaving your users staring at a screen that doesn't refresh.

It also comes up in Undo/Redo functionality. If you save a "snapshot" of your application state using a shallow copy, and then the user modifies the current state, your snapshot is ruined because it's pointing to the same mutated data.

Key Takeaways

- Spread is shallow. It only copies the first layer.
- References are pointers. If a property is an object or array, you're copying the address, not the value.
- Use structuredClone() for a native, deep copy in modern JS.
- Be careful with JSON hacks. They break when you have non-JSON types like Dates or Maps.
- Always think about the depth. Before cloning, ask yourself: "Does this object have objects inside it?" If yes, a spread operator isn't enough.