Tag's icon prop renders a string literally instead of as an icon (Button already handles this)

[einari]

Tag's icon prop does not accept a PrimeIcons class-name string the way Button's does — passing one renders it as literal text instead of an icon.

Expected

Button (Common/Button.js) has a renderIcon helper:

const renderIcon = (icon) => typeof icon === 'string' ? jsx("i", { className: icon, "aria-hidden": 'true' }) : icon;

so <Button icon='pi pi-user' /> renders a proper <i className="pi pi-user"> icon. Tag's own JSDoc says it exists specifically to restore the PrimeReact-10-era authoring ergonomics on top of PrimeReact 11, matching Button's stated purpose.

Actual

Tag (Display/Tag.js) passes icon straight through as a child with no conversion:

const Tag = ({ value, severity, rounded, icon, className, children }) => (jsxs(Tag$1, { severity, rounded, className, "data-severity": severity, children: [icon, value ?? children] }));

<Tag value="Member" severity="success" icon="pi pi-user" /> renders the literal text pi pi-userMember — the icon class name is printed as a text node instead of becoming an icon.

Repro

import { Tag } from '@cratis/components/Display';

<Tag value="Member" severity="success" icon="pi pi-user" />

Expected: a green pill with a person icon followed by "Member".
Actual: a green pill containing the literal text "pi pi-userMember".

Why it matters

Every call site written against Tag's documented authoring model (a plain PrimeIcons class-name string, matching Button's) silently breaks in this exact way — no type error, no console warning, since icon?: React.ReactNode accepts a string just fine. Only a live render exposes it. Badge (Display/Badge.js) has the identical icon-less-conversion shape as Tag (no icon prop at all there, so not directly affected, but worth checking for the same class of gap if one is ever added).

Version: @cratis/components@3.5.0.

[cratis-direct]

Investigation

Reproduced — confirmed, not a reading of the code. I wrote a throwaway spec at Source/Display/for_Tag/when_icon_is_a_string/and_rendered.ts rendering <Tag value="Member" severity="success" icon="pi pi-user" /> inside CratisComponentsProvider via renderToStaticMarkup, and got:

<span data-scope="tag" id="pr_id__R_1_" class="" data-severity="success" ... data-slot="root">pi pi-userMember</span>

Exactly the reported symptom — no <i>, the class name printed as a text node. A second throwaway spec showed the identical gap in Chip (<div data-part="start">pi pi-filter</div>), Avatar (<span data-part="fallback">pi pi-user</span>) and Message (<div data-part="icon">pi pi-bell</div>). Badge has no icon prop, so it is unaffected. Both repro spec folders were deleted; git status is clean.

The key finding the issue doesn't mention: the repo already has the canonical helper. Source/Common/Icon.tsx exports IconDisplay, backed by normalizeIconClass (repairs 'pi-home' → 'pi pi-home', warns in dev on a bare 'plus'), with five existing specs and a Storybook page. Toolbar/ToolbarButton, ToolbarFolder and ToolbarFanOutItem all use it. Button's inline renderIcon is a second, weaker copy that predates or bypasses it. So this is not "port Button's helper to Tag" — it is "four Display components never got wired to the helper that already exists".

SUGGESTED-MODEL: sonnet

Plan for #220

Settled — do not redo

• The bug is real and reproduced (evidence above). No further repro work needed.
• Root cause: Source/Display/Tag.tsx:32-36 renders {icon} directly as a child of PrimeTag. Same in Chip.tsx:28, Avatar.tsx:29, Message.tsx:50.
• The fix mechanism is settled: use the existing IconDisplay from Source/Common/Icon.tsx. Do not add a new renderIcon helper, and do not copy Button's inline one — that would be a third implementation of the same thing and would skip normalizeIconClass's repair and dev warning.
• No import cycle: Toolbar/* already imports '../Common/Icon' directly (not via the barrel); Display/index.ts and Common/index.ts don't reference each other.
• Badge is out of scope — it has no icon prop.
• Repro/spec harness is settled: PrimeReact 11 components throw without a provider, so specs must wrap in CratisComponentsProvider and use renderToStaticMarkup — copy the shape of Source/Common/for_Tooltip/when_rendered/and_it_is_not_disabled.ts.

Changes

1. Source/Display/Tag.tsx — import IconDisplay and Icon from '../Common/Icon'; change the prop to icon?: Icon and render {icon && <IconDisplay icon={icon} />}.
2. Source/Display/Chip.tsx — keep the icon && guard, wrap the inner value: <PrimeChip.Start><IconDisplay icon={icon} /></PrimeChip.Start>.
3. Source/Display/Avatar.tsx — preserve the documented image → icon → label order: {icon ? <IconDisplay icon={icon} /> : label} inside PrimeAvatar.Fallback.
4. Source/Display/Message.tsx — this one gets simpler: severityIcons is already a Record<MessageSeverity, string> of class names, so the body collapses to <PrimeMessage.Icon><IconDisplay icon={icon ?? severityIcons[severity]} /></PrimeMessage.Icon>. Keep the icon !== false opt-out and keep icon?: Icon | false.
5. Specs — new Source/Display/for_<Component>/when_icon_is_a_string/and_rendered.ts for each of the four (there are currently no Display specs at all, so these are the first). Assert an <i> with the class is rendered and that the class does not appear as text. Add a when_icon_is_a_react_node case for Tag at minimum, to lock in that nodes still pass through. Message also needs a spec that icon={false} still renders no icon part.
6. Docs — Documentation/Display/index.md describes icon as `ReactNode` at lines 23 (Tag), 59 (Chip) and 80 (Avatar). Change the type column to `string \| ReactNode` and the description to match Button's wording ("a PrimeIcons class name ('pi pi-check') or an element"), and add a string-icon example to the Tag snippet.
7. Stories — Source/Display/Display.stories.tsx:49,53 currently pass icon={<i className="pi pi-user" />}. Add (don't replace) a string-icon variant so the authoring model the issue describes is visible in Storybook.

Gates

npx tsc -p Source/tsconfig.json --noEmit, yarn lint, yarn test in Source/, and yarn build-storybook. Note deps were not installed in this worktree before I ran yarn install — the implementer should expect the same.

PR metadata

Label patch — a behavior fix in a published package, outward-facing. Reference (#220) in the bullet, no closing keyword.

Needs a human decision (does not block the fix above)

• Scope beyond Tag. The issue titles only Tag, but Chip/Avatar/Message are the same one-line gap and the issue body invites checking for it. I'd fix all four in one PR; if the maintainer wants Tag alone, drop items 2–4 and open a follow-up issue.
• Whether to also converge Button (and ActionMenubar) on IconDisplay. Button.tsx:63 renders <i className={icon} aria-hidden='true' /> — IconDisplay emits no aria-hidden. Converging Button would either drop that attribute or require adding it to IconDisplay, which changes markup for every existing Toolbar call site. ActionMenubar.tsx:70 renders {item.icon} raw but documents it as "An icon element", so it's a weaker case. I deliberately left both out of the plan — they're a separate, riskier cleanup, and the aria-hidden question should be answered before touching them.

Suggested model for implementation: sonnet

---

Posted by Stagehand (AI) - an autonomous agent, not a person. Review accordingly.

[woksin]

Fixed in #177 and released in Components 4.0.0.