Reactivity caveats and limitations in Vue - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when you directly assign a new property to a reactive object?

Consider a reactive object created with reactive(). What will happen if you add a new property directly after creation?

Vue

import { reactive } from 'vue';
const state = reactive({ count: 0 });
state.newProp = 123;
console.log(state.newProp);

A The new property is added but is not reactive; changes won't trigger updates.

B The new property is reactive and updates will trigger re-renders.

C Vue throws an error because new properties cannot be added to reactive objects.

D The new property is reactive only if declared with <code>ref()</code>.

💡 Hint

Think about how Vue tracks reactivity on object properties.

Vue's reactive() wraps existing properties to be reactive. Adding new properties directly after creation does not make them reactive automatically. To add reactive properties later, you should use ref() or reactive() properly.

❓ state_output

intermediate

What is the output when mutating an array inside a reactive object?

Given the following code, what will be logged to the console?

Vue

import { reactive } from 'vue';
const state = reactive({ items: [1, 2, 3] });
state.items.push(4);
console.log(state.items.length);

A 3

B undefined

C 4

D Throws a TypeError

💡 Hint

Arrays inside reactive objects are reactive. What happens when you push an item?

Vue wraps arrays inside reactive objects, so mutating methods like push are reactive and update the array length. The console logs 4 because the new item was added.

📝 Syntax

advanced

Which option correctly uses toRefs to avoid losing reactivity when destructuring?

Given a reactive object, which code snippet correctly destructures properties while preserving reactivity?

Vue

import { reactive, toRefs } from 'vue';
const state = reactive({ count: 0, name: 'Vue' });
// Destructure here

A const count = toRefs(state.count); const name = toRefs(state.name);

B const { count, name } = state;

C const count = state.count.value; const name = state.name.value;

D const { count, name } = toRefs(state);

💡 Hint

Think about how to keep reactivity when extracting properties.

Direct destructuring (option D) breaks reactivity because it copies values. Using toRefs returns refs for each property, preserving reactivity. Option D is correct.

🔧 Debug

advanced

Why does this reactive object not update the template when a nested property changes?

Examine the code below. Why does changing state.user.address.city not update the template?

Vue

import { reactive } from 'vue';
const state = reactive({ user: {} });
state.user.address = { city: 'Paris' };
// Later in code
state.user.address.city = 'London';

A Because <code>state.user.address.city</code> is a primitive and cannot be reactive.

B Because <code>address</code> was added after <code>user</code> was made reactive, it is not reactive.

C Because <code>reactive</code> only tracks top-level properties, not nested ones.

D Because nested objects cannot be reactive in Vue.

💡 Hint

Think about when properties are added to reactive objects.

Vue's reactive() only makes existing properties reactive. Adding address after creation means it is not reactive. Changes to city inside address won't trigger updates.

🧠 Conceptual

expert

What is a key limitation of Vue's reactivity system regarding property deletion?

Which statement best describes Vue's behavior when deleting a property from a reactive object?

A Vue does not track property deletions; deleting a property does not trigger reactive updates.

B Vue throws an error if you try to delete a property from a reactive object.

C Deleting a property from a reactive object triggers reactivity and updates the UI automatically.

D Deleting a property converts the reactive object into a non-reactive plain object.

💡 Hint

Consider how Vue tracks changes to object properties.

Vue's reactivity system does not detect property deletions. Deleting a property does not trigger updates, so the UI may not reflect the change unless handled explicitly.