Why component patterns matter in Vue - Challenge Your Understanding

Challenge - 5 Problems

❓ component_behavior

intermediate

How does a poorly structured Vue component affect reusability?

Consider a Vue component that mixes UI logic and data fetching directly inside the setup() without separation. What is the main impact on reusability?

Vue

<script setup>
import { ref } from 'vue'
const data = ref(null)
fetch('/api/data').then(res => res.json()).then(json => data.value = json)
</script>
<template>
  <div>{{ data }}</div>
</template>

A The component automatically caches data, improving performance in all cases.

B The component will not render because data fetching must be done outside <code>setup()</code>.

C The component becomes tightly coupled to data fetching, making it hard to reuse with different data sources.

D The component is more reusable because it handles all logic internally.

💡 Hint

Think about what happens if you want to use the component with different data sources.

Mixing data fetching directly inside the component ties it to a specific data source. This reduces reusability because you cannot easily change the data without modifying the component.

❓ state_output

intermediate

What is the output when using a shared reactive object incorrectly?

Given two components sharing the same reactive object without proper isolation, what will be the output after one updates the state?

Vue

<script setup>
import { reactive } from 'vue'
const sharedState = reactive({ count: 0 })
function increment() {
  sharedState.count++
}
</script>
<template>
  <button @click="increment">Increment</button>
  <p>Count: {{ sharedState.count }}</p>
</template>

A Each component maintains its own count, so updates do not affect the other.

B Both components show the updated count because they share the same reactive state.

C The count resets to zero on every click due to reactivity issues.

D The component throws an error because reactive objects cannot be shared.

💡 Hint

Consider what happens when multiple components use the same reactive object instance.

Sharing a reactive object means all components reference the same state. When one updates it, all reflect the change.

📝 Syntax

advanced

Which option correctly uses Vue syntax for conditional rendering?

Which code snippet correctly shows a message only if isVisible is true?

A

<template>
  <div v-if="isVisible">Visible</div>
</template>

B

<template>
  <div #if="isVisible">Visible</div>
</template>

C

<template>
  <div *if="isVisible">Visible</div>
</template>

D

<template>
  <div @if="isVisible">Visible</div>
</template>

💡 Hint

The correct directive for conditional rendering in Vue is v-if.

v-if is the standard Vue directive for conditional rendering. The other options use invalid syntax.

🔧 Debug

advanced

Why does this Vue component fail to update the UI when state changes?

Examine the code below. Why does the UI not update when count changes?

Vue

<script setup>
import { ref } from 'vue'
const count = ref(0)
function increment() {
  count.value++
}
</script>
<template>
  <button @click="increment">Increment</button>
  <p>Count: {{ count }}</p>
</template>

A Because <code>count</code> is a plain variable, Vue does not track its changes for reactivity.

B Because the template syntax is incorrect; it should use <code>{{ this.count }}</code>.

C Because <code>increment</code> is not declared as an async function.

D Because the <code>count</code> variable is declared inside <code>setup()</code> but not returned.

💡 Hint

Think about how Vue tracks reactive state.

Vue only tracks reactive variables created with ref() or reactive(). Plain variables like let count = 0 are not reactive, so UI won't update.

🧠 Conceptual

expert

Why is separating concerns in Vue components crucial for large applications?

In large Vue applications, why is it important to separate concerns like UI, state management, and side effects into different components or composables?

A It eliminates the need for Vue Router and Vuex by default.

B It reduces the total number of components, making the app load faster.

C It forces all logic into a single file, simplifying debugging.

D It improves maintainability, testability, and allows multiple developers to work independently without conflicts.

💡 Hint

Think about teamwork and managing complexity in big projects.

Separating concerns helps keep code organized, easier to test, and allows teams to work on different parts without stepping on each other's toes.