javascript Variable Shadowing

Why This Question Matters

If you're just starting with JavaScript, you might look at this snippet and think it's a trick question. It looks too simple. But this actually touches on one of the most fundamental concepts in the language: primitive vs. reference types.

Getting this wrong isn't just about failing a quiz; it's about how you manage data in your app. If you don't understand how JavaScript handles assignment, you'll eventually run into bugs where you change a value in one part of your code and accidentally mutate a variable somewhere else. This is where "weird" bugs live.

Understanding the Code

Let's look at the snippet again:

let a = 1
let b = a
b = 99
console.log(a)

At first glance, it seems like b is linked to a. You might think, "I set b equal to a, so if I change b, a should change too."

Here is what's actually happening under the hood:

1. let a = 1: JavaScript allocates a spot in memory for a and stores the number 1 there.
2. let b = a: This is the critical part. Since 1 is a primitive value (a number), JavaScript doesn't link b to a. Instead, it takes the *value* of a (which is 1), makes a copy of it, and assigns that copy to b. Now you have two separate boxes in memory, both containing the number 1.
3. b = 99: You're telling JavaScript to change the value in b's box to 99. This has zero effect on a's box.
4. console.log(a): We check the value of a, which is still 1.

Finding the Correct Answer

The output is 1 (Option B).

Why not 99? Because numbers are passed by value. When you wrote let b = a, you weren't creating a shortcut or a reference to a. You were just duplicating the data.

If this were a different data type—like an object or an array—the result would be completely different. For example:

let a = { value: 1 }
let b = a
b.value = 99
console.log(a.value) // This would be 99!

In the object example, a and b both point to the same memory address. Changing one affects the other. But with the number 1, they are totally independent.

Common Mistakes Developers Make

The biggest mistake is assuming that assignment (=) always works the same way. Beginners often treat variables like "labels" for a piece of data. While that's true for objects, it's not how primitives work.

Another common trip-up is the confusion between reassignment and mutation.

In the original challenge, we are *reassigning* b. We aren't changing the number 1 (you can't actually change the number 1; it's immutable); we are just telling the variable b to stop looking at 1 and start looking at 99.

If you're coming from a language like C++ or C#, you might be thinking about pointers. In JavaScript, you don't have direct access to memory addresses, so the engine decides for you: primitives are copied, objects are referenced.

Real-World Usage

You'll run into this daily when managing state in frameworks like React or Vue.

Imagine you have a state object representing a user profile. If you do const newUser = oldUser and then change newUser.name = 'Alex', you've just mutated the oldUser object too. This is a nightmare in React because the framework won't detect that the state changed (since the memory reference is still the same), and your UI won't re-render.

This is why we use the spread operator:

const newUser = { ...oldUser }; 

By doing this, we create a shallow copy, mimicking the behavior of the primitive assignment we saw in the challenge. We ensure that changing the new object doesn't mess up the original one.

Key Takeaways