← back to blog

Why inline ternaries don't belong in your Vue templates

A template is a description of UI structure. The moment it starts branching, constructing strings, or calling functions, it stops describing and starts computing — and Vue already has a better place for that.

TL;DR

Move ? :, &&, string concatenation, and multi-call expressions out of the template and into a computed. You get a readable, declarative template, logic you can name, log, and unit-test, and — because computed properties are cached on their reactive dependencies — fewer recalculations during re-render. The template should read like UI; the logic should live in JS/TS.

The problem with inline template logic

Templates are supposed to read top-to-bottom like the markup they produce. Inline conditions break that. Every one of these is a real cost, not a style preference:

Why computed properties win

The fix is boring and it's been in the framework the whole time:

The performance point

This is the part people skip, so it's worth being precise. A function call or expression in a template runs on every re-render of that component. Vue can't know whether the result changed, so it runs it again every time the component's render function executes:

<!-- runs on every re-render, every time -->
{{ expensiveFunction(user) }}
{{ a ? computeA() : computeB() }}

A computed is cached against its reactive dependencies. It only re-runs when one of the values it read last time actually changes:

const displayLabel = computed(() => {
  if (isValidated.value) {
    return computeValidatedLabel()
  }
  return computeUnvalidatedLabel()
})

Read displayLabel ten times in a render and it computes once. Re-render for an unrelated reason and it doesn't recompute at all. The payoff scales with the thing you're rendering:

• fewer recalculations,
• more predictable rendering,
• no accidental expensive work in the hot render path,
• safe for large lists, tables, and frequently-updating components.

DO vs DON'T

A conditional label

DON'T — branch and concatenate i18n strings inline:

<q-tooltip
  anchor="center right"
  self="center left"
  :offset="[6, 0]"
  class="sidebar-tooltip"
>
  {{
    isValidated
      ? $t('common_unvalidate_short') + ' ' + $t(type)
      : $t('common_validate_short') + ' ' + $t(type)
  }}
</q-tooltip>

DO — name the intent, build the string once in a computed:

const validationTooltip = computed(() => {
  const action = isValidated.value
    ? t('common_unvalidate_short')
    : t('common_validate_short')
  return `${action} ${t(type)}`
})

<q-tooltip
  anchor="center right"
  self="center left"
  :offset="[6, 0]"
  class="sidebar-tooltip"
>
  {{ validationTooltip }}
</q-tooltip>

The template now reads as "a tooltip showing the validation tooltip." The string-building is testable in isolation, and the $t noise is gone from the markup.

A conditional :style

DON'T — return whole style objects from a ternary in the template:

:style="
  props.moduleType === MODULES.Buildings
    ? {
        '--row-alt-color': '#f8fafc',
        '--table-header-bg': moduleColors.bgColorLighter,
      }
    : { '--row-alt-color': '#f8fafc' }
"

:style="
  isValidated
    ? {
        borderColor: moduleColors.buttonTextColor,
        color: moduleColors.buttonTextColor,
      }
    : {
        background: moduleColors.bgColorLighter,
        color: moduleColors.buttonTextColor,
        border: `1px solid ${moduleColors.buttonTextColor}`,
      }
"

DO — prefer a class for the variant, and let CSS custom properties (computed once) carry the dynamic values. Branch with :class, theme with --vars:

const tableVars = computed(() => ({
  '--row-alt-color': '#f8fafc',
  '--table-header-bg': moduleColors.value.bgColorLighter,
}))

<table
  :class="{ 'is-buildings': props.moduleType === MODULES.Buildings }"
  :style="tableVars"
>

.is-buildings {
  /* variant-specific rules live in CSS, where they belong */
}

For the button, the same move — one class toggle, the colours as variables:

const buttonVars = computed(() => ({
  '--btn-fg': moduleColors.value.buttonTextColor,
  '--btn-bg': moduleColors.value.bgColorLighter,
}))

<button :class="{ 'is-validated': isValidated }" :style="buttonVars">

.is-validated {
  border-color: var(--btn-fg);
  color: var(--btn-fg);
}
button:not(.is-validated) {
  background: var(--btn-bg);
  color: var(--btn-fg);
  border: 1px solid var(--btn-fg);
}

Styling rules go to the stylesheet, dynamic theme values flow through cached custom properties, and the template just says "this button is validated or it isn't." (If you'd rather keep the whole object in JS, a single computed returning the style object still beats an inline ternary — the point is to get the branch out of the template.)

The heuristic

You don't need a rule per case. One test covers almost all of it. If a template expression contains:

• ? :
• && (used to compute, not just to gate v-if)
• string concatenation
• more than one function call

→ move it to a computed property.

And the inverse — what's fine to leave in the template:

• property access (user.name)
• simple bindings (:href="url")
• loops (v-for)
• visibility conditions (v-if="isOpen")

When not to bother

Computed properties aren't free — they carry dependency-tracking overhead — and the goal is readable code, not maximal indirection. Leave it inline when:

• The expression is genuinely trivial: {{ count + 1 }}, {{ items.length }}, :disabled="loading". Wrapping these in a computed adds a name to read with no benefit.
• A single boolean gates a v-if/v-show. That is a visibility condition; it belongs in the template.
• The value depends on v-for scope (the loop item). You can't lift a per-row expression into a component-level computed without restructuring — extract a child component or a small helper function instead, and let the child's computed cache per instance.

The line is "does this branch, build, or compute?" — not "is there any logic at all?" A template with zero expressions is its own kind of unreadable.

References

• Vue docs, Computed Properties — the canonical "don't put complex logic in templates" guidance, including the caching contract vs. methods.
• Vue docs, Template Syntax — JavaScript expressions — what templates are meant to hold; expressions are restricted by design.
• Vue docs, Class and Style Bindings — prefer object/array :class for variants over inline style ternaries.
• Vue style guide, Simple expressions in templates — official "strongly recommended" rule that says exactly this.
• MDN, Using CSS custom properties — why pushing dynamic values through --vars keeps the styling in CSS. See also Why CSS variables beat SCSS variables.

— Pierre