Tooltip content is typed string but renders any ReactNode

[einari]

What happens

Tooltip's content is typed string, but the implementation renders it straight through as the
children of Tooltip.Popup:

export interface TooltipProps {
    content?: string;
    ...
}

jsx(Tooltip$1.Popup, { className: "cratis-tooltip-popup", children: content })

So any ReactNode renders correctly at runtime - the type is simply narrower than the component.

Why it matters

Help content is the natural case: a tooltip holding a couple of paragraphs and a "Learn more" link
is ordinary, and it works today - but only if you cast:

<Tooltip content={help as unknown as string} position='right'>

That cast is not describing anything true, and it silences the compiler for the whole expression,
so a genuine mistake in help would no longer be caught. A consumer that does not want the cast has
to either flatten rich help into a string or stop using the wrapper, which is the thing the wrapper
exists to prevent (primereact/tooltip directly).

Suggested

Widen to content?: React.ReactNode. It matches what the component already does, is source-compatible
for every existing call site (string is a ReactNode), and needs no runtime change.

Observed on @cratis/components as resolved in an application today; worked around locally with the
cast above, referencing this issue.

[cratis-direct]

Plan

Plan — #230: Widen Tooltip's content prop to ReactNode

Context confirmed in the codebase

• Source/Common/Tooltip.tsx (TooltipProps.content) is typed string (line 23), but Source/Common/TooltipImplementation.tsx only ever does if (!content || disabled) return children; (truthiness check) and <AriaTooltip>{content}</AriaTooltip> — both are already ReactNode-safe at runtime. No component (Tooltip.tsx/TooltipImplementation.tsx) does any string-specific operation (.length, .trim(), etc.) on content. This is a pure type-narrowing bug, exactly as the issue describes.
• Every current caller (ObjectNavigationalBar, SchemaEditor, TypeCell, NameCell, ObjectContentEditor, ToolbarButton, ToolbarFolder, ToolbarFanOutItem, the stories, and the specs) passes a plain string (or undefined) into content. Since string is assignable to ReactNode, widening the type is fully source-compatible — no call site needs to change.
• ToolbarFanOutItem.tsx and Button.tsx have their own, separate tooltip?: string / tooltip: string props (not Tooltip's content) that they forward into content={...}. Those remain valid strings under the wider content?: ReactNode and are out of scope for this issue — the issue only asks about Tooltip's own prop.

Implementation steps

1. Source/Common/Tooltip.tsx

   • Add ReactNode to the existing type-only import: import type { ReactElement, ReactNode } from 'react';
   • Change content?: string; → content?: ReactNode;
   • Update the JSDoc above it from /** Text displayed inside the tooltip. Empty content disables the tooltip. */ to something like /** Content displayed inside the tooltip. Empty content disables the tooltip. */ — the prop table doc (auto-generated by Storybook's react-docgen-typescript) should describe what the prop now actually accepts.

2. Source/Common/TooltipImplementation.tsx — no change needed. It destructures content from the shared TooltipProps type and already handles it as an opaque renderable value; the falsy-disables-tooltip behavior (!content) is unaffected by the wider type.

3. Source/Common/Tooltip.stories.tsx (recommended, matches storybook.md's "Showcase — cover the meaningful axes" and frontend-quality.md's story requirement for changed reusable components) — add one story demonstrating rich ReactNode content, mirroring the exact use case from the issue (a couple of paragraphs and a link), e.g. a RichContent story rendering content={<div>...help text...<a>Learn more</a></div>}. This documents the new capability and gives a regression check that JSX content renders through renderToStaticMarkup/Storybook without the cast.

4. Specs — no existing spec needs to change (for_Tooltip/when_rendered/*.ts, when_the_trigger_receives_focus.tsx all pass strings, which stay valid). No new spec is strictly required since behavior is unchanged — the type change has no runtime branch to cover. If desired for extra confidence, an optional spec asserting the trigger still renders when content is a React element (not just a string) could be added under for_Tooltip/when_rendered/, but this is not required by the project's "don't test trivial pass-throughs" guidance since TooltipImplementation doesn't branch on content's type.

5. Quality gates (Components is a framework-profile repo — framework.md applies): yarn lint and npx tsc -b zero errors; yarn test for the Tooltip spec folder; build-storybook to confirm the new story compiles.

Order

Single small change — step 1 (type + doc) is the only required edit; step 3 (story) is additive and can land in the same commit. No backend involved, no proxy generation, no cross-file sequencing concerns.

Judgment call left to the PR author (not blocking implementation)

Per pull-requests.md, exactly one of major/minor/patch/no-release is required on the PR. This change is source-compatible for all existing callers and doesn't alter runtime behavior — it only corrects the declared type to match what the component already does. Recommend labeling it patch (a type-accuracy bug fix), but minor is defensible too (it unlocks a genuinely new consumer capability — rich ReactNode content without a cast). This is a labeling choice at PR time, not something that changes the code.

---

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