All quizzesEasy
Template & Render Basics — Series 2
Preview — 3 of 10 questions
Does writing @click="() => handleClick(item.id)" inline, instead of a named method, meaningfully hurt performance?
javascript
<template>
<button v-for="item in items" :key="item.id" @click="() => handleClick(item.id)">
{{ item.name }}
</button>
</template>AA brand-new arrow function is created on every single re-render, for every item in the list — while cheap for a handful of buttons, this becomes a measurable, unnecessary cost for large lists (hundreds/thousands of items) re-rendering frequently, since none of those function objects are ever reused between renders, unlike a stable method reference
BThis is invalid syntax — @click can only bind to a method reference, never an inline arrow function
CVue automatically caches inline template functions after their first creation — this pattern has zero performance difference from a named method, for any list size
DInline arrow functions in templates only affect memory usage, never actual rendering speed
Why is this pattern generally discouraged, beyond just being confusing to read?
javascript
<template>
<li v-for="user in users" v-if="user.isActive" :key="user.id">
{{ user.name }}
</li>
</template>AIn Vue 3, v-if has higher priority than v-for on the same element, meaning the compiler evaluates the condition before the loop variable (user) even exists in scope — this specific example actually throws a reference error, since user isn't accessible yet when v-if="user.isActive" tries to evaluate. Beyond the correctness bug, even in cases that don't error, filtering inside v-for this way means the loop still iterates and evaluates the condition for every item, rather than filtering the source list once beforehand
BThis throws a compile error in Vue 3 — v-if and v-for can never coexist on the same element under any circumstances
Cv-if and v-for combined always renders every item, completely ignoring the v-if condition
DThis pattern is fine and recommended — it's the standard way to conditionally render filtered list items in Vue 3
How does this differ from a custom IntersectionObserver-based lazy-loading implementation?
javascript
<template>
<img
v-for="photo in photos"
:key="photo.id"
:src="photo.url"
loading="lazy"
alt=""
/>
</template>Aloading="lazy" is a native HTML attribute, supported directly by modern browsers with zero JavaScript — the browser itself decides when to actually fetch the image (typically as it approaches the viewport), requiring no IntersectionObserver setup, no extra library, and no Vue-specific code at all. It's the simplest option for basic lazy-loading, though a custom JS-based solution still offers more control (custom thresholds, loading placeholders, fine-tuned trigger distances) that the native attribute doesn't expose
Bloading="lazy" is a Vue-specific directive — it doesn't work on plain <img> tags outside of a Vue application
Cloading="lazy" and IntersectionObserver-based lazy loading behave identically in every respect — there's no meaningful difference between them at all
Dloading="lazy" only works for <img> tags inside a v-for loop — it has no effect on a single, standalone <img>
Sign up free to play
Answer all 10 questions (7 more), see explanations for every answer, and track your score.