Composables for reusable logic in Vue - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What is the output of this Vue composable usage?

Consider this composable and component using it:

import { ref } from 'vue';

export function useCounter() {
  const count = ref(0);
  function increment() {
    count.value++;
  }
  return { count, increment };
}

// In a component setup:
const { count, increment } = useCounter();
increment();
increment();

What is the value of count.value after these calls?

A 0

B 1

C 2

D undefined

💡 Hint

Each call to increment() increases count.value by 1.

The composable useCounter returns a reactive count starting at 0. Calling increment() twice increases it to 2.

📝 Syntax

intermediate

Which option correctly defines a composable that returns a reactive string?

Choose the correct composable function that returns a reactive string message initialized to "Hello".

A

import { reactive } from 'vue';
export function useMessage() {
  const message = reactive('Hello');
  return { message };
}

B

export function useMessage() {
  const message = 'Hello';
  return { message };
}

C

import { reactive } from 'vue';
export function useMessage() {
  const message = reactive({ text: 'Hello' });
  return message.text;
}

D

import { ref } from 'vue';
export function useMessage() {
  const message = ref('Hello');
  return { message };
}

💡 Hint

Use ref for primitive reactive values like strings.

ref creates a reactive primitive value. reactive is for objects. Option D correctly uses ref and returns an object containing message.

🔧 Debug

advanced

Why does this composable cause shared state across components?

Look at this composable:

import { ref } from 'vue';

const count = ref(0);

export function useSharedCounter() {
  function increment() {
    count.value++;
  }
  return { count, increment };
}

When used in multiple components, why do they share the same count value?

A Because Vue automatically shares all composable state between components.

B Because <code>count</code> is declared outside the function, so it is shared across all calls.

C Because the function does not return <code>count</code> properly.

D Because <code>ref</code> creates a global reactive variable by default.

💡 Hint

Think about where variables are declared in JavaScript modules.

Variables declared outside the composable function are shared across all imports and calls, causing shared state. To avoid this, declare reactive state inside the function.

❓ state_output

advanced

What is the output of this composable with watchEffect?

Given this composable and usage:

import { ref, watchEffect } from 'vue';

export function useDoubleCounter() {
  const count = ref(1);
  const double = ref(0);

  watchEffect(() => {
    double.value = count.value * 2;
  });

  function increment() {
    count.value++;
  }

  return { count, double, increment };
}

// In component setup:
const { count, double, increment } = useDoubleCounter();
increment();
increment();

What are the final values of count.value and double.value?

A <code>count.value</code> is 3 and <code>double.value</code> is 6

B <code>count.value</code> is 2 and <code>double.value</code> is 4

C <code>count.value</code> is 3 and <code>double.value</code> is 3

D <code>count.value</code> is 1 and <code>double.value</code> is 2

💡 Hint

watchEffect updates double whenever count changes.

Starting at 1, two increments make count 3. The watchEffect sets double to twice count, so 6.

🧠 Conceptual

expert

Why use composables instead of mixins for reusable logic?

Which reason best explains why Vue composables are preferred over mixins for sharing reusable logic?

A Composables provide better type inference and avoid naming conflicts by using explicit function calls.

B Mixins are faster to run but harder to write.

C Composables automatically merge data and methods without conflicts.

D Mixins allow better control over lifecycle hooks than composables.

💡 Hint

Think about clarity and code safety when reusing logic.

Composables use explicit function calls returning reactive state, improving type safety and avoiding naming collisions common in mixins.