Conditional Templates

Show, hide, and style parts of your Velt wireframe templates conditionally with VeltIf, VeltData, and velt-class.

• Conditional Templates let you conditionally show or hide parts of the Velt Component Wireframes.
• You can add conditions based on the same data models available in Template Variables.

There are two ways to use Conditional Templates:

1. Using Velt If component

• Wrap wireframe components and html elements in Velt If component.
• If the condition is not met, the component will not be rendered.
• Good for targeting groups of components at once.

React / Next.js

<VeltIf condition="{annotation.status.id} === 'OPEN' && {annotation.comments.length} === 3">
  {/* Content to render if condition is true */}
</VeltIf>

Other Frameworks

<velt-if condition="{annotation.status.id} === 'OPEN' && {annotation.comments.length} === 3">
  <!-- Content to render if condition is true -->
</velt-if>

2. Using Velt If attribute

• Add Velt If attribute to existing wireframe components.
• If the condition is not met, the component will not be rendered.
• Good for targeting a single component.

React / Next.js

<VeltCommentDialogWireframe.Header veltIf="{user.isAdmin} === true" />

Other Frameworks

<velt-comment-dialog-header-wireframe velt-if="{user.isAdmin} === true">
</velt-comment-dialog-header-wireframe>

Syntax

The condition is specified as a string that will be evaluated as a JavaScript expression.

Syntax: {<variable>} <operator> <value>

Example: {annotation.status.id} === 'OPEN'

Template variables are enclosed in curly braces and support nested paths:

{user.name}                               property access
{annotation.comments.length}              array length
{annotation.comments.0.text}              array index (dot)
{annotation.comments[0].from.userId}      array index (bracket)
{unreadCommentsMap[annotation.annotationId]}   dynamic key (inner resolved first)
{annotation.context.foo}                  annotation.context shorthand

Operators allowed in a condition:

Category	Supported
Logical	&&, ||, !
Equality	==, !=, ===, !==
Comparison	<, >, <=, >=
Grouping	(, )
Literals	strings '…', numbers, true, false, null, undefined

Anything outside this whitelist is stripped before evaluation (safe by design).

Strict CSP Policy

Some environments enforce strict Content Security Policies (CSP) that disallow unsafe-eval. In such cases, the default method could be blocked and the conditions may not be evaluated. Here is how you can use an alternative approach to evaluate Velt If conditions. This method uses a safer, CSP-compliant parser to evaluate your Velt If conditions.

React / Next.js

client.enableSafeEval();
client.disableSafeEval();

Other Frameworks

Velt.enableSafeEval();
Velt.disableSafeEval();

Examples

React / Next.js

{/* 1. Show content only for open annotations: */}
<VeltIf condition="{annotation.status.id} === 'OPEN'">
  <p>This annotation is currently open.</p>
</VeltIf>

{/* 2. Display a message for annotations with more than 5 comments: */}
<VeltIf condition="{annotation.comments.length} > 5">
  <p>This is a popular annotation!</p>
</VeltIf>

{/* 3. Combine multiple conditions: */}
<VeltIf condition="{annotation.status.id} === 'OPEN' && {annotation.comments.length} === 0">
  <p>This is a new open annotation without any comments yet.</p>
</VeltIf>

Other Frameworks

<!-- 1. Show content only for open annotations: -->
<velt-if condition="{annotation.status.id} === 'OPEN'">
  <p>This annotation is currently open.</p>
</velt-if>

<!-- 2. Display a message for annotations with more than 5 comments: -->
<velt-if condition="{annotation.comments.length} > 5">
  <p>This is a popular annotation!</p>
</velt-if>

<!-- 3. Combine multiple conditions: -->
<velt-if condition="{annotation.status.id} === 'OPEN' && {annotation.comments.length} === 0">
  <p>This is a new open annotation without any comments yet.</p>
</velt-if>

Related Directives

Two sibling directives use the same {token} syntax as Velt If:

velt-data: print a live value as text

Documented with the full data catalog in Template Variables.

velt-class: toggle CSS classes conditionally

React / Next.js

// On a wireframe component: the veltClass prop
<VeltCommentDialogWireframe.Header veltClass="'is-dark': {darkMode}" />

// On your own markup inside a wireframe: the literal attribute passes through JSX
<div velt-class="'is-dark': {darkMode}, 'is-resolved': {resolved}" />
<div velt-class-active="{showReplies}" />

Other Frameworks

<div velt-class="'is-dark': {darkMode}, 'is-resolved': {resolved}"></div>
<div velt-class-active="{showReplies}"></div>

Mapped vs. flat-config features (which name form to use)

Two access conventions exist, as a rule of thumb:

• Mapped: use short aliases like {annotation.from.name}: Comment Dialog, Comments Sidebar, Comment Bubble, Inline Comments Section, Multi-Thread Comment Dialog, Text Comment, Notifications Panel, Notifications Tool, Activity Log.
• Flat-config: use the explicit {componentConfig.<name>} form: Cursor, Presence, Huddle, Recording, Transcription, View Analytics, Area, Arrow, Tag, Reactions, Selection, Rewriter, Comments Tool, Sidebar Button, Autocomplete.

If a short alias resolves to undefined in a flat-config feature, fall back to {componentConfig.<name>}. Mapped features accept the explicit form too; it’s just not required.

Variables that support nested access

Only these root names allow {root.nested.field}; any other variable resolves to its root only. (Per-component variable lists with examples: Template Variables.)

user, annotation, annotations, allAnnotations, userContact, comment, commentAnnotation,
commentAnnotations, recorderInitConfig, ghostComment, editComment, assignTo, customChipData,
currentDialogView, context, focusedAnnotation, notification, selectedMinimalFilterDropdownOption,
unreadNotificationsForYou, notificationsForYouInSession, notificationsInSession,
notificationsByUserMap, notificationsByDocumentId, notificationsByDate, settingsConfig,
settingsSelectedOption, settingsAccordionExpanded, tabConfig, tabPage, TABS, allActivities,
filteredActivities, groupedActivities, virtualScrollItems, availableFilters, expandedGroups,
activity, activityRecord, dateGroup, filter, filterOption, position, allowedElementIds,
filteredAnnotations, multiThreadCommentAnnotation, composerCommentAnnotation, statuses,
filterState, sortState, selectedAnnotationsMap, selectedAnnotationsLocationMap, contextOptions

If a deep path returns undefined, first check the root is on this list.

---

Frequently used variables (Comment Dialog / Sidebar)

A small starter set: see the per-feature page for the full list and types:

Variable	Meaning	Typical use
{user} / {user.name}	Current user	velt-data
{annotation}	The thread’s annotation (deep paths OK)	velt-data (e.g. annotation.from.name)
{comment} / {commentIndex}	Current comment in a thread card / its 0-based index	velt-if="{commentIndex} === 0"
{darkMode}	Dark mode active	velt-class
{noCommentsFound}	Sidebar empty state	velt-if
{enableResolve}, {canResolveAnnotation}	Resolve availability	velt-if
{resolved} / {status}	Thread resolved / status	velt-if / velt-class
{composerInOpenState}	Composer expanded	velt-class
{focusedAnnotation}	Sidebar’s focused thread	velt-data
{notification}	Current notification (notifications panel)	velt-data

---

Debugging a token that shows nothing

If a token renders undefined/blank, check, in order:

1. Spelling: exact name from Template Variables (case-sensitive).
2. Nested access: is the root in the nested-access list above? If not, you can only read its root.
3. Context: are you inside a slot that actually receives that variable? (e.g. {comment}/{commentIndex} exist only inside thread-card descendants; {notification} only in the notifications panel.)
4. Mapped vs flat: for flat-config features use {componentConfig.<name>}.

The full variable list (and which roots allow nested access) is in Template Variables.