Composables for reusable logic in Vue - Performance & Optimization

Performance: Composables for reusable logic

MEDIUM IMPACT

This affects page load speed and interaction responsiveness by controlling how reusable logic impacts component rendering and reactive updates.

Sharing reactive logic across multiple components

Vue

import { reactive } from 'vue';

export function useCounter() {
  const state = reactive({ count: 0 });
  return { state };
}

Creates a fresh reactive state per component instance, limiting reactivity scope and reducing unnecessary updates.

📈 Performance GainReactive updates are scoped, reducing re-renders and improving interaction responsiveness.

Sharing reactive logic across multiple components

Vue

import { reactive } from 'vue';

const state = reactive({ count: 0 });

export function useCounter() {
  return { state };
}

This shares a single reactive state instance globally, causing all components to re-render on any change, even if unrelated.

📉 Performance CostTriggers unnecessary re-renders and reactive updates across all components using the composable.

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Global shared reactive state in composable	Low (few DOM nodes)	High (many reactive triggers)	Medium (frequent updates)	[X] Bad
Instance-scoped reactive state in composable	Low (few DOM nodes)	Low (limited reactive triggers)	Low (updates scoped)	[OK] Good

Rendering Pipeline

Composable logic runs during component setup, creating reactive state and functions. Proper scoping limits reactive dependency tracking to each component instance, reducing the number of reactive updates during user interaction.

→JavaScript Execution

→Reactive Dependency Tracking

→Component Render

→Paint

⚠️ BottleneckReactive Dependency Tracking causing excessive component re-renders

Core Web Vital Affected

INP

This affects page load speed and interaction responsiveness by controlling how reusable logic impacts component rendering and reactive updates.

Optimization Tips

1Avoid sharing global reactive state in composables to prevent unnecessary re-renders.

2Scope reactive state inside composables per component instance for better update isolation.

3Use DevTools Performance panel to monitor reactive effect executions and component renders.

Performance Quiz - 3 Questions

What is a performance risk of using a global reactive state inside a Vue composable?

A All components using it re-render on any state change

B It reduces bundle size significantly

C It prevents reactive updates

D It improves initial page load speed

DevTools: Performance

How to check: Record a performance profile while interacting with components using the composable. Look for excessive component re-renders or reactive effect recalculations.

What to look for: High number of component render calls or reactive effect executions indicates inefficient composable usage.

Practice

1. What is the main purpose of a composable in Vue?

easy

A. To reuse reactive logic across multiple components

B. To define global CSS styles

C. To create new Vue directives

D. To register Vue components globally

Solution

1. Step 1: Understand composables role

   Composables are functions that encapsulate reactive logic to be reused.

2. Step 2: Identify main purpose

   They help share logic like state or effects across components without duplication.

3. Final Answer:

   To reuse reactive logic across multiple components -> Option A

4. Quick Check:

   Composable = reusable logic [OK]

Hint: Composables share logic, not styles or components [OK]

Common Mistakes:

• Confusing composables with CSS or templates
• Thinking composables register components
• Assuming composables create directives

2. Which of the following is the correct way to define a composable in Vue 3?

easy

A. function useCounter() { return reactive({ count: 0 }) }

B. const useCounter = new Vue({ data() { return { count: 0 } } })

C. const useCounter = reactive({ count: 0 })

D. function useCounter() { const count = ref(0); return { count }; }

Solution

1. Step 1: Check composable function syntax

   A composable is a function that returns reactive state or methods.

2. Step 2: Validate options

   function useCounter() { const count = ref(0); return { count }; } defines a function returning a ref wrapped count, which is correct. const useCounter = new Vue({ data() { return { count: 0 } } }) wrongly uses Vue instance syntax. const useCounter = reactive({ count: 0 }) returns reactive object directly without function. function useCounter() { return reactive({ count: 0 }) } returns reactive but misses ref usage and best practice.

3. Final Answer:

   function useCounter() { const count = ref(0); return { count }; } -> Option D

4. Quick Check:

   Composable = function returning reactive state [OK]

Hint: Composable must be a function returning reactive data [OK]

Common Mistakes:

• Defining composables as Vue instances
• Returning reactive objects without a function
• Not using ref or reactive inside composables

3. Given this composable:

import { ref } from 'vue';
export function useToggle() {
  const isOn = ref(false);
  function toggle() { isOn.value = !isOn.value; }
  return { isOn, toggle };
}

What will be the value of isOn.value after calling toggle() twice starting from initial state?

medium

A. true

B. undefined

C. false

D. null

Solution

1. Step 1: Analyze initial state and toggle function

   Initially, isOn.value is false. Each toggle flips it to the opposite.

2. Step 2: Apply two toggles

   First toggle: false -> true. Second toggle: true -> false.

3. Final Answer:

   false -> Option C

4. Quick Check:

   Two toggles flip false twice back to false [OK]

Hint: Toggle flips boolean; even toggles return original [OK]

Common Mistakes:

• Assuming toggle sets true always
• Forgetting to access .value of ref
• Confusing initial state with toggled state

4. What is wrong with this composable code?

import { ref } from 'vue';
export function useCount() {
  const count = ref(0);
  function increment() {
    count++;
  }
  return { count, increment };
}

medium

A. The count variable should be declared with reactive()

B. You cannot increment a ref directly with ++ operator

C. ref should be imported from 'vue/reactive' instead

D. The function should be named useCounter, not useCount

Solution

1. Step 1: Understand ref usage

   Ref values are accessed and mutated via the .value property.

2. Step 2: Identify error in increment function

   The code uses count++ which tries to increment the ref object itself, not its value. It should be count.value++.

3. Final Answer:

   You cannot increment a ref directly with ++ operator -> Option B

4. Quick Check:

   Use count.value++ to update ref [OK]

Hint: Always use .value to read or write ref values [OK]

Common Mistakes:

• Incrementing ref without .value
• Confusing reactive and ref imports
• Thinking function name affects behavior

5. You want to create a composable that tracks window width and updates reactively on resize. Which approach correctly implements this?

hard

A. function useWindowWidth() {
const width = ref(window.innerWidth);
onMounted(() => {
window.addEventListener('resize', () => {
width.value = window.innerWidth;
});
});
onUnmounted(() => {
window.removeEventListener('resize', () => {
width.value = window.innerWidth;
});
});
return { width };
}

B. function useWindowWidth() {
const width = ref(window.innerWidth);
window.addEventListener('resize', () => {
width.value = window.innerWidth;
});
return { width };
}

C. function useWindowWidth() {
const width = reactive({ value: window.innerWidth });
window.onresize = () => {
width.value = window.innerWidth;
};
return width;
}

D. function useWindowWidth() {
const width = ref(0);
window.addEventListener('resize', () => {
width = window.innerWidth;
});
return { width };
}

Solution

1. Step 1: Understand reactive window width tracking

   We need a ref to hold width and update it on resize events.

2. Step 2: Check event listener lifecycle management

   function useWindowWidth() { const width = ref(window.innerWidth); onMounted(() => { window.addEventListener('resize', () => { width.value = window.innerWidth; }); }); onUnmounted(() => { window.removeEventListener('resize', () => { width.value = window.innerWidth; }); }); return { width }; } correctly adds listener on mount and removes it on unmount to avoid leaks. function useWindowWidth() { const width = ref(window.innerWidth); window.addEventListener('resize', () => { width.value = window.innerWidth; }); return { width }; } adds listener immediately without cleanup. function useWindowWidth() { const width = reactive({ value: window.innerWidth }); window.onresize = () => { width.value = window.innerWidth; }; return width; } uses reactive incorrectly and overwrites window.onresize. function useWindowWidth() { const width = ref(0); window.addEventListener('resize', () => { width = window.innerWidth; }); return { width }; } tries to assign to ref variable directly, which is invalid.

3. Final Answer:

   function useWindowWidth() { const width = ref(window.innerWidth); onMounted(() => { window.addEventListener('resize', () => { width.value = window.innerWidth; }); }); onUnmounted(() => { window.removeEventListener('resize', () => { width.value = window.innerWidth; }); }); return { width }; } -> Option A

4. Quick Check:

   Manage listeners with lifecycle hooks [OK]

Hint: Add and remove listeners inside lifecycle hooks [OK]

Common Mistakes:

• Not removing event listeners causing memory leaks
• Assigning directly to ref variable instead of .value
• Overwriting window.onresize instead of adding listener