Dynamic Attributes with v-bind

A static attribute is text the compiler copies. v-bind:disabled="..." — written with the colon shorthand :disabled in every real codebase — turns the value into an expression that Vue evaluates on every render and keeps in sync with the DOM. Same directive, two very different lifetimes.

<script setup lang="ts">
import { ref } from 'vue'
const isSaving = ref(false)
const email = ref('')
const attempts = ref(0)
</script>

<template>
  <button :disabled="isSaving">{{ isSaving ? 'Saving…' : 'Save' }}</button>
  <input v-model="email" :aria-invalid="attempts > 3" />
  <form :action="submitUrl" method="post">
    <a :href="`/orders/${order.id}`">View</a>
  </form>
</template>

The rule that governs every binding, and the one worth memorizing before the syntax details: null, undefined, and false remove the attribute; anything else sets it as a string. For most attributes that is intuitive, but for boolean attributes — disabled, checked, required, readonly, multiple — it carries a trap that exists in plain HTML too: presence means true. Write the literal disabled="false" and the button is disabled, because the browser only checks whether the attribute exists. With the binding, :disabled="isSaving" with isSaving === false removes the attribute entirely and enables the button. The two lines below are equivalent in Vue and both wrong if you wanted a working button:

<button disabled="false">x</button>   <!-- disabled: presence is truth -->
<button :disabled="'false'">x</button> <!-- also disabled: a non-empty string -->

Binding to a computed URL — your fourth key point in practice — replaces the manual-DOM habit completely:

<script setup lang="ts">
import { computed } from 'vue'
const props = defineProps<{ product: { id: string; photo: string | null } }>()
const photoUrl = computed(() => props.product.photo ?? '/placeholder.svg')
</script>

<template>
  <img :src="photoUrl" :alt="props.product.name" />
</template>

No querySelector, no .src = assignment, no re-running anything when the product changes: the expression reads reactive state, so the reactive system patches the attribute whenever the inputs change. That is the through-line of this entire phase — templates declare relationships; the reactivity system maintains them.

Two syntax extensions appear rarely but earn points in interviews. Dynamic arguments let the attribute name itself come from an expression: :[attrName]="value" where attrName is 'data-test-id' or 'aria-describedby'. The argument must be a single valid JavaScript identifier or a quoted string — spaces and newlines break it, because the compiler treats them as expression boundaries. The object form binds several attributes at once: v-bind="{ id, class: activeClass, 'data-test': testId }" — a plain object of raw (unbound) values, no colon shorthand inside. Its most common appearance is forwarding a parent's extras to a child: v-bind="$attrs", which spreads every attribute the component did not declare as a prop onto a root element — the mechanism behind wrapper components that stay transparent. You will meet $attrs again as the thing defineProps splits away from the rest; here it is enough to recognize the pattern.

One caution to keep templates readable: bindings are re-evaluated per render, so heavy computation belongs in a computed and the template should bind a name. :disabled="requests.filter(r => r.active).length > 0" works — but :disabled="hasActiveRequests" documents itself and lets devtools show you the boolean directly. Next: the two bindings where Vue stops treating values as plain strings — class and style.

class and style get special treatment because they are additive: the parent's classes, a component's internal classes, and dynamic state all need to coexist. Vue handles the merge for you, which is why you never concatenate class strings by hand.

<script setup lang="ts">
import { ref } from 'vue'
const isActive = ref(true)
const errors = ref<string[]>(['email'])
const theme = ref<'light' | 'dark'>('dark')
</script>

<template>
  <!-- static + object + array, all merged -->
  <div
    class="card"
    :class="{ active: isActive, 'has-errors': errors.length > 0 }"
    :style="{ fontSize: size + 'px', color: theme === 'dark' ? '#ddd' : '#222' }"
  >
    Content
  </div>

  <!-- array syntax combines binding sources -->
  <p :class="['badge', isActive && 'badge--on', theme]">Tag</p>
</template>

The merge rules, precisely:

The fallthrough row matters on teams: <MyButton class="lg" /> renders the child with lg merged onto its root node, so wrapper styling needs no prop plumbing. It is also the same mechanism that puts scoped-style caveats in the previous phase — the parent's scope attribute lands on that root too.

style follows the same object/array shape with value semantics instead of presence. Object keys are camelCase (backgroundColor, flexGrow) and numbers get px appended automatically for dimensional properties — fontSize: 14 renders font-size: 14px; unitless properties (opacity, zIndex, fontWeight) pass through untouched. Mixing strings and objects in the array form works: :style="[{ color }, baseStyle]" with later entries winning on conflict. Custom properties are the exception that proves the camelCase rule — write them as-is: :style="{ '--grid-gap': gap + 'px' }" and read them in CSS with var(--grid-gap).

Two habits separate clean code from brittle code here. First, stop building class strings. 'btn ' + (isOn ? 'btn-on' : 'btn-off') + ' ' + size loses every static class the moment a value is missing and forces you to maintain three parallel taxonomies; the object syntax keeps the mapping from state to class in one visible place, which is what CSS-in-template should look like. Second, treat class bindings as a state API. When a template accumulates :class="{ 'md:grid-cols-3': layout === 'grid' }"-style expressions, that is the moment to compute a named class list in script (const layoutClasses = computed(...)) so the template binds one identifier and devtools shows one boolean/object instead of an inline expression tree.

The behavior to test in your browser devtools once, so it sticks: inspect a node while toggling :class and watch the class attribute update in the same frame — the DOM change is exactly what your hand-rolled classList.toggle code used to do, minus the bugs. Next: Event Handling with v-on — bindings push state to the DOM; listeners bring user actions back.

A report arrives: images work on localhost and 404 behind the company's /app/ reverse proxy. The template said <img src="/hero.png">, the file sat in public/, and production moved the app under a subpath. URL bindings are where template habits meet the bundler, and the failure modes are systematic.

Bundled assets must flow through imports. Anything under src/assets/ exists in the build only if imported, and it arrives with a content-hashed name — so the URL itself is state that only the bundler knows:

<script setup lang="ts">
import logoUrl from '@/assets/logo.svg'        // hashed URL string
const props = defineProps<{ id: string }>()
const avatarUrl = computed(() => `/avatars/${props.id}.webp`)  // runtime-composed
</script>

<template>
  <img :src="logoUrl" alt="logo" />
  <img :src="avatarUrl" alt="" />
</template>

<img src="@/assets/logo.svg"> as a static attribute does not resolve @ (the template's static-asset rewriting understands relative paths like ../assets/x.png, not aliases), which produces the classic dev-server 404 that still "looks right" in the code review. The import form is explicit, works with TypeScript (the vite/client types give *.svg module declarations), and tree-shakes.

Public files need the base prefix at runtime. A public asset referenced as /favicon.svg works at the domain root and breaks under base: '/app/'. Vite injects the configured base as a constant, so compose public URLs through it:

const manifestUrl = import.meta.env.BASE_URL + 'site.webmanifest'

Hardcoded root-absolute paths are the bug; hashed imported assets are immune because the bundler already stamped base into their URLs. This asymmetry — imports get base for free, public references must add it — is worth stating in any deployment discussion.

Boolean and presence attributes, revisited with real APIs. The removal rule (null/undefined/false deletes the attribute) makes bindings the correct way to express optional HTML:

<input :required="isRequired" :maxlength="maxLen ?? undefined" :disabled="!formReady" />
<img :src="src" :alt="decorative ? undefined : label" />   <!-- alt absent when decorative -->

Note the aria-* exception to keep assistive tech correct: aria-* and role are string-semantic attributes where "false" is meaningful information. :aria-hidden="false" removes the attribute (fine — absence equals false there), but :aria-pressed="isActive" on a toggle button removes aria-pressed when inactive, which screen readers report as "not a toggle button" instead of "toggled off". Bind explicit strings for those:

<button :aria-pressed="String(isActive)">Like</button>

The general review checklist for URL and conditional attributes: static path that a bundler should hash? import it · public file? prefix import.meta.env.BASE_URL · boolean attribute? bind a real boolean, never the string "false" · aria-*/role? bind 'true'/'false' strings deliberately. With state now flowing out to attributes, the next piece is the return channel: Event Handling with v-on.

A final production habit ties URL bindings to testing: give key elements stable hooks. A data-testid attribute bound from the row's id gives end-to-end tests a selector that survives class-name redesigns, and because it is an ordinary attribute it follows the same removal rule — bind undefined when the id is absent rather than leaking the string 'undefined' into the DOM. Teams that adopt this early stop writing CSS-selector queries in Playwright, and the bindings themselves document which elements the test suite depends on. The same discipline applies to image assertions: match the hashed prefix rather than an exact filename, since every content change renames the file. Attribute bindings are the seam where your data model meets both the browser and the tooling that verifies it — treat them as part of the page's public surface, not as incidental markup.