[frankkluijtmans]

Summary

Adds MessageThread to Apollo Vertex: an e-mail style conversation, extracted from the supplier communications thread. Follow-up to #1528.

Thread structure

MessageThreadHeader
  title · status badge · meta · actions

MessageThread  (newest first by default)
└─ message
   ├─ header toggle     avatar · sender · date
   │                    subject
   │                    excerpt (collapsed) / "to …" (expanded)
   ├─ actions           beside the header, outside the toggle
   └─ expanded body     notice · plain-text body · footer

The latest message starts expanded. Older ones collapse to sender, subject and a one-line excerpt. The header is one button that stays mounted in both states, so focus never moves. A single-message thread is always expanded and has no toggle.

Interface

Messages are plain data. The component owns layout and UI states. Only footer takes a React node (e.g. a reply form). Everything else is typed so consumers describe intent, not markup:

{
  id: "3",
  sender: "Sam Lee",
  senderEmail: "sam.lee@example.com",
  recipients: ["IT Support"],
  sentAt: "2026-11-08T08:05:00Z",
  subject: "Re: Laptop replacement request",
  body: "Could you ship the new one to the Berlin office?",
  notice: {
    status: "warning",
    label: "Address change",
    actions: [{ label: "Confirm address", onClick: confirm }],
  },
  actions: [{ label: "Forward", icon: Forward, onClick: forward }],
  footer: <ReplyForm />,
}

• body is plain text and keeps line breaks.
• notice is info | warning | error. Collapsed: badge. Expanded: alert with its actions.
• MessageThreadHeader takes title, badge, meta and actions.

Expansion is designed for several use cases without extra branching:

Use case	Behaviour
Live thread	Appended messages expand (including batches). History prepended later stays collapsed.
Async load	Mounting with [] then loading data expands only the latest.
Inbox detail	key={selectedId} resets expansion per conversation.
Persist state	Controlled via expandedIds / onExpandedChange.
Chat-like order	order="oldest-first".

Shared Action

Action { label, onClick, disabled?, icon? } lives in lib/action.ts and is exported from the package root. It describes something the user can do; rendering stays up to the consuming component.

MessageThread uses it for notice actions, message actions and header actions (first = primary button). Other components with the same shape today (AI chat message actions, solution-tests buttons, filter options) can adopt it later without inventing another type.

Also: the Inbox demo opens conversations as a thread.

[github-actions]

Dependency License Review

• ✅ 1958 package(s) scanned
• ✅ No license issues found
• ⚠️ 2 package(s) excluded (see details below)

License distribution

License	Packages
MIT	1722
ISC	91
Apache-2.0	57
BSD-3-Clause	28
BSD-2-Clause	23
BlueOak-1.0.0	8
MPL-2.0	4
CC0-1.0	4
MIT-0	3
MIT OR Apache-2.0	2
(MIT OR Apache-2.0)	2
Unlicense	2
LGPL-3.0-or-later	1
Python-2.0	1
CC-BY-4.0	1
(MPL-2.0 OR Apache-2.0)	1
Unknown	1
Artistic-2.0	1
(WTFPL OR MIT)	1
(BSD-2-Clause OR MIT OR Apache-2.0)	1
CC-BY-3.0	1
0BSD	1
(MIT OR CC0-1.0)	1
MIT AND ISC	1

Excluded packages

Package	Version	License	Reason
@img/sharp-libvips-linux-x64	1.3.4	LGPL-3.0-or-later	LGPL pre-built binary, not linked
khroma	2.1.0	Unknown	MIT per GitHub repo, missing license field in package.json

[Copilot]

🟡 Changes recommended

Batched updates leave some incoming messages collapsed, and expanding or collapsing a message replaces the focused control without restoring keyboard focus.

2 open issues

• Expand all newly appended messages in uncontrolled mode · New
• Preserve focus when toggling message disclosure · New

What changed in this PR

Adds Apollo Vertex’s MessageThread pattern, completing the conversation detail view introduced by the Inbox pattern in #1528.

Changes:

• Adds message and thread headers, expandable history, per-message slots, localized labels, and unit tests.
• Registers and exports the pattern with documentation and an interactive reply demo.
• Updates the Inbox demo to display multi-message conversations.

File	Description
packages/​apollo-vertex/​tsconfig.json	Adds the message-thread import alias.
packages/​apollo-vertex/​skills/​vertex-component-catalog/​SKILL.md	Adds usage guidance to the component catalog.
packages/​apollo-vertex/​registry/​message-thread/​message-thread.tsx	Implements the thread, header, and expansion state.
packages/​apollo-vertex/​registry/​message-thread/​message-thread.test.tsx	Tests rendering, ordering, expansion, and controlled behavior.
packages/​apollo-vertex/​registry.json	Registers the pattern and its dependencies.
packages/​apollo-vertex/​locales/​en.json	Adds English message-header and collapse labels.
packages/​apollo-vertex/​entries/​index.ts	Exports the new components and types.
apps/​apollo-vertex/​templates/​MessageThreadTemplate.tsx	Adds an interactive conversation and reply demo.
apps/​apollo-vertex/​templates/​InboxTemplate.tsx	Displays selected conversations using MessageThread.
apps/​apollo-vertex/​content/​docs/​patterns/​meta.json	Adds the pattern to documentation navigation.
apps/​apollo-vertex/​content/​docs/​patterns/​message-thread.mdx	Documents installation, usage, slots, and API.
apps/​apollo-vertex/​content/​docs/​patterns/​inbox.mdx	Links to MessageThread for conversation details.

_{Review effort: Balanced}

[github-actions]

📊 Coverage + size by package

Per-package coverage and bundle size on this PR. New-line coverage = of the source lines this PR adds or changes, the % hit by tests.

Package	Coverage	New-line coverage	Packed (gzip)	Unpacked	vs main
@uipath/apollo-core	—	—	—	—	—
@uipath/apollo-react	—	—	—	—	—
@uipath/apollo-ui-icons	—	—	—	—	—
@uipath/apollo-vertex	92.6%	100.0% (53/53)	350.1 KB	1.98 MB	+4.2 KB
@uipath/apollo-wind	—	—	—	—	—
@uipath/ap-chat	—	—	—	—	—

_{"Coverage" is each package's own coverage.include scope (e.g. apollo-core instruments only scripts/). "Packed"/"Unpacked" come from npm pack --dry-run and only cover built packages — "—" means not measured this run (package not affected / not built). "vs main" is the packed (gzipped) delta against the last successful main build (the package-sizes artifact from the Release workflow); "—" there means no main baseline was available this run. The baseline is main's latest build, not this PR's exact merge-base, so it includes any drift since the branch diverged. Packages with no vitest config are omitted.}

[github-actions]

Storybook visual diff

✅ No stories are affected by this PR's changes; nothing to compare. Logs

Updated (PT): Nov 12, 2026, 05:37:17 AM

[Copilot]

🟡 Changes recommended

Batched updates expand only the latest arriving message, leaving other new messages collapsed and violating the documented behavior that each arrival opens.

1 open issue

• Expand every newly arrived message in batched updates · New

2 resolved since last review

• Preserve focus when toggling message disclosure
• Expand all newly appended messages in uncontrolled mode

_{Review effort: Balanced}

[ruudandriessen]

Looks:
Its weird I can click the row to open but not to close? The component feels not really fleshed out TBH

Docs:
The usage in the docs is also weird - it's referencing some "conversation" which isnt really there? Can we instead use the real props. The fact we are mapping them already feels weird

Components:
Basically EVERYTHING is just a react node - can we not have a better interface? At this point it's not really a proper generic component - it's just a "whatever you wanna drop in goes"?

[frankkluijtmans]

Looks: Its weird I can click the row to open but not to close? The component feels not really fleshed out TBH

Docs: The usage in the docs is also weird - it's referencing some "conversation" which isnt really there? Can we instead use the real props. The fact we are mapping them already feels weird

Components: Basically EVERYTHING is just a react node - can we not have a better interface? At this point it's not really a proper generic component - it's just a "whatever you wanna drop in goes"?

Looks: In it's expanded state it's not really a row anymore. I can tweak it a bit so there's a more compact e-mail header that feels like a somewhat stable toggle for expand/collapsed states.

Docs: Yeah, I can replace this hypothetical conversation object with just straight up values for the props.

Components: All of the slots aren't great. While porting I pressed on making things like status indications and custom elements as flexible as possible, but this is a bit too loose. Things like warning, error states and subject, recipients etc. can also be represented in a different way with enforced UI states.

To summarize, I'll go through the props and see what really needs to be a react node. Right now I think only actions and footer need that type to ensure it covers the supplier inbox use-case.

[Copilot]

🔵 Needs a closer look

The bundled LocaleProvider leaves i18next interpolation escaping enabled, causing recipient names containing ampersands or apostrophes to render as literal HTML entities in React text.

No open issues 🎉

_{Review effort: Balanced}

[frankkluijtmans]

@ruudandriessen I mainly cleaned up the interface quite a bit. It was sloppy to rely on React.Node props to this extent. Only footer is left as a component prop, in supplier comms that's where we'd render the Agent Analysis and Proposed Action.

Otherwise I created a generic Action interface. We define actions all over te place and mostly in the same way. I figured we could introduce a generic interface for it. I can also follow up and replace some of the other specific action interface we don't really need.

[Copilot]

🟡 Changes recommended

Recipient names are double-escaped because i18next interpolation escaping remains enabled, causing HTML entities to appear literally in message-thread text.

1 open issue

• Disable i18next escaping to preserve recipient names · New

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Translation interpolation HTML-escapes recipient names before React renders them as text, causing special characters to appear as literal HTML entities in message details.

1 open issue

• Recipient names display HTML entities due to double escaping · New

1 resolved since last review

• Disable i18next escaping to preserve recipient names

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Recipient names containing special characters are incorrectly displayed as literal HTML entities because i18next interpolation escaping remains enabled for text already safely rendered by React.

No open issues 🎉

1 resolved since last review

• Recipient names display HTML entities due to double escaping

_{Review effort: Balanced}

[ruudandriessen]

much nicer, but have one note; the time changes between closed/open which is weird:

Same with the "to" actually 🤔

[frankkluijtmans]

much nicer, but have one note; the time changes between closed/open which is weird:

Same with the "to" actually 🤔

Let's just always show relative time and then have a tooltip showing the full timestamp, I think that's an improvement too. With regards to the To field; I'm definitely not obfuscating the sender e-mail so then the only option would be to always show it.

[Copilot]

🟡 Changes recommended

Recipient names render with literal HTML entities due to interpolation escaping, and keyboard users cannot reveal the full timestamp.

1 open issue

• Make timestamps accessible to keyboard users · New

_{Review effort: Balanced}