Vue 3 ref() vs reactive(): differences and when to use each

WHAT THIS TESTS: This question tests whether you understand the fundamental reactivity primitives in Vue 3's Composition API and can articulate the architectural difference between a value wrapper and a proxy. Interviewers want to see that you know why ref() is the recommended default, how the unwrapping mechanism works, and when reactive() is appropriate. It also reveals whether you understand JavaScript Proxies and the mental model behind Vue 3's reactivity system.

A GOOD ANSWER COVERS: First, state that ref() is the recommended way to declare reactive state in Composition API according to the Vue docs. Second, explain that ref() takes any value and returns it wrapped in an object with a .value property, so you read and mutate the state through that .value property. Third, explain that reactive() creates a reactive proxy of an object, meaning you access properties directly without a .value intermediary. Fourth, note that ref() works with primitives like numbers or strings as well as objects, whereas reactive() only accepts objects. Fifth, mention that in templates, ref() values are automatically unwrapped, so you do not write .value in the template, but you do in script. Sixth, give a clear rule of thumb: use ref() for most state, especially primitives or values that will be replaced entirely, and use reactive() when you want to keep raw object access patterns and do not need to reassign the whole object.

COMMON WRONG ANSWERS: A major red flag is claiming that ref() is only for primitives and reactive() is only for objects. Another is forgetting that ref() requires .value in script but not in templates. Some candidates incorrectly say that reactive() can be used with primitives, or that ref() returns a plain object without a wrapper. Claiming that ref() and reactive() are interchangeable without structural changes in code is also incorrect because switching from reactive() to ref() would require adding .value throughout your logic.

LIKELY FOLLOW-UPS: The interviewer may ask why ref() is recommended over reactive() as the default. They might also ask about the limitations of reactive(), such as the inability to replace the entire object without losing reactivity or the caveats with arrays and collections. Another follow-up is how to share state between components using ref() versus reactive(), or how TypeScript inference differs between the two.

ONE CONCRETE EXAMPLE: Imagine a counter. With ref(), you write const count = ref(0) and then increment it with count.value++. With reactive(), you would write const state = reactive({ count: 0 }) and increment with state.count++. If you later reassign count to a new value, ref() handles it fine because you are mutating .value. If you reassign the state variable itself to a new object, reactive() breaks reactivity because you are no longer referencing the original proxy.