ConditionViewer

Usage

• Use ConditionViewerItem and ConditionViewerGroup to render a read-only summary of a set of rules — segment conditions, exit conditions, audience rules, trigger filters — as boxed sentences nested under the operator that combines them.
• Do not use them to build an editor. This family covers the view state only; a rule being edited needs form components.
• Use ConditionViewerGroup for a set combined under one operator, ConditionViewerItem for a single rule, ConditionViewerTerm for the emphasized runs inside a sentence, and ConditionViewerDetailList plus ConditionViewerDetail for sub-conditions below a sentence.
• These components know nothing about what a rule means. Every word, every marker icon, the operator wording, the condition count, and the recursion over your data all stay in the application. Do not expect Pluma to derive any of it.

Appearance

• Give each ConditionViewerItem a marker with icon (a Pluma icon name), iconSrc (an image URL), or iconContent (any node — in Ember an icon block). iconContent takes precedence over iconSrc, which takes precedence over icon. A condition with none of them renders no marker.
• The marker is a sm rounded-square Coin and its size and shape are fixed, so markers stay aligned with the sentence's first line. Do not try to resize it.
• iconColorVariant defaults to purple. Change it only to signal that one condition needs attention (an unresolvable reference, an invalid value); leave it alone otherwise so a set of conditions reads as one.
• isInline makes a condition hug its content instead of filling the available width. Use it for a condition shown alongside other content; leave it off for a list of conditions.
• Pass isNested to every ConditionViewerGroup except the outermost one. The outermost group has no surface or border of its own; nested groups get the surface, border and padding that separate them from their siblings. The chrome does not alternate with depth — every nested level looks the same.
• Do not restyle the boxes with className or inline styles. The public CSS variables (conditionBackgroundColor, conditionBorderColor, conditionPadding, conditionGap, conditionGroupGap, conditionDetailBackgroundColor, and the rest — see condition-viewer.style-exports.ts) are the supported way to adjust a whole tree, and can be set on any ancestor.

Behaviors

• isCollapsible renders the collapse toggle and manages the open state internally, starting open (defaultOpen changes that). Pass isOpen with onToggle instead when the state lives in your application; isOpen makes the group controlled and is honored with or without isCollapsible, so a group can be driven from a control of your own with no Pluma toggle at all.
• A collapsible group with no label names its own toggle ("Expand conditions" / "Collapse conditions"). Prefer giving the group a label — the toggle is then named by the descriptor, which says which group it collapses.
• A ConditionViewerItem with no icon, iconSrc or iconContent renders no marker, and its sentence sits flush with the box's padding rather than offset to meet a marker.
• A collapsed group unmounts its children rather than hiding them, so they leave the tab order with the rest of the content.
• Use actions on a ConditionViewerGroup for the way into editing the set, and actions on a ConditionViewerItem for what sits beside a rule rather than inside its sentence (a warning tooltip, a cost indicator). ConditionViewerItem actions align with the marker, so they stay put as the sentence wraps.
• Put a ConditionViewerDetailList in a condition's details, never a bare ConditionViewerDetail. The list owns the spacing and the lead-in; a condition can hold several lists when it is refined by differently-labelled sets.
• Put the lead-in text ("and matches all:") at the end of the item's own sentence, not on the list's label. It then reads as one phrase on one line with the chips below it; a label renders on a line of its own and breaks the sentence in two.
• Use label only for the second and subsequent lists on one item, where an item is refined by more than one differently-described set and only the first lead-in can live in the sentence.
• A detail chip's overflow stays visible, so a value inside one can anchor a Tooltip or Popover without being clipped. This applies to values in the item's sentence too, not just in chips.
• When a value has more detail behind it — a date's full timestamp, a truncated list — wrap it in a ConditionViewerTerm so it keeps the usual emphasis, and mark the trigger with isUnderlined on the Tooltip (or isTooltipTriggerUnderlined on a FormattedDateTime) so a reader can tell there is more to see.
• In Ember, do not wrap a named block (<:details>, <:actions>, <:label>) in {{#if}} — Glimmer rejects it. Write the block unconditionally and drive it with the matching hasXBlock prop (hasDetailsBlock, hasActionsBlock, hasLabelBlock, hasIconBlock) instead of spelling out one invocation per combination.
• hasXBlock is a three-state override, not a boolean toggle: leave it undefined and the slot renders whenever there's content, set it explicitly and it wins outright. Both frameworks read it; it exists mainly because Ember can't conditionally write a named block, and because has-block is true for a present-but-empty block, which would otherwise render an empty container.
• The marker is always aria-hidden; the sentence is what assistive technology reads. A labelled group gets role="group" and is named by its own descriptor, which also names the collapse toggle.

Content

• Wrap the parts of a sentence that carry meaning in ConditionViewerTerm — field names, values, entity names all get the same treatment — and leave the connecting words plain.
• A sentence does not have to start with a field. Both **company** is **acme** and Has viewed a screen matching **/home/** at least **6** times are correct; put the emphasis where the meaning is.
• Keep the phrasing consistent across rule types within an application. Pluma sets no wording, so consistency is the application's job.
• Write group descriptors as a sentence with the operator as an inline Badge, for example Matches <Badge>all</Badge> of 4 conditions. Pluma aligns the badge with the words either side of it.
• Do not put interactive controls in a sentence beyond tooltip or popover triggers on a value. Anything actionable belongs in actions.