feat(apollo-vertex): ai-chat message actions — copy, feedback, edit, regenerate [3/5]

[petervachon]

What this does

Adds the per-message action layer — the controls that let users interact with individual messages rather than just reading them.

• Copy message — copies the full text of any message to clipboard with a brief "Copied!" confirmation
• Thumbs up / thumbs down on assistant messages — surfaces a onFeedback callback so the host app can record quality signals
• Edit user message — tap the pencil on any user bubble to revise your message; the conversation rewinds to that point and re-sends, so the thread stays coherent
• Regenerate — reruns the last AI response without resending the user message, useful when the answer is off
• Actions appear on hover (desktop) or are always visible on touch, so they don't clutter the UI by default
• Shared state lives in AiChatProvider context so all message components can read it without prop-drilling

Test plan

• Hover a message — action bar appears
• Copy copies the message text and shows "Copied!" briefly
• Thumbs up/down fires onFeedback with the message ID and type
• Edit pencil opens inline edit mode; submitting rewinds history and re-sends
• Regenerate button (on latest assistant message) fires onRegenerate

🤖 Generated with Claude Code

[github-actions]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (PT)
apollo-design	🟢 Ready	Preview, Logs	May 11, 2026, 06:38:15 AM
apollo-docs	🟢 Ready	Preview, Logs	May 11, 2026, 06:35:12 AM
apollo-landing	🟢 Ready	Preview, Logs	May 11, 2026, 06:34:02 AM
apollo-ui-react	🟢 Ready	Preview, Logs	May 11, 2026, 06:36:04 AM
apollo-vertex	🟢 Ready	Preview, Logs	May 11, 2026, 06:36:39 AM

[github-actions]

Dependency License Review

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

License distribution

License	Packages
MIT	1826
ISC	104
Apache-2.0	69
BSD-3-Clause	30
BSD-2-Clause	24
Copyright 2022, UiPath, all rights reserved	9
BlueOak-1.0.0	8
MPL-2.0	5
MIT OR Apache-2.0	3
MIT-0	3
Unknown	3
Unlicense	3
CC0-1.0	3
LGPL-3.0-or-later	2
(MIT OR Apache-2.0)	2
Python-2.0	1
CC-BY-4.0	1
(MPL-2.0 OR Apache-2.0)	1
BSD	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.2.4	LGPL-3.0-or-later	LGPL pre-built binary, not linked
@img/sharp-libvips-linuxmusl-x64	1.2.4	LGPL-3.0-or-later	LGPL pre-built binary, not linked
@uipath/apollo-angular-elements	5.89.0	Copyright 2022, UiPath, all rights reserved	UiPath first-party package
@uipath/apollo-core	4.35.0, 4.35.1, 4.35.2	Copyright 2022, UiPath, all rights reserved	UiPath first-party package
@uipath/apollo-fonts	1.25.8	Copyright 2022, UiPath, all rights reserved	UiPath first-party package
@uipath/apollo-icons	1.33.7	Copyright 2022, UiPath, all rights reserved	UiPath first-party package
@uipath/apollo-mui5	2.31.26, 2.31.27	Copyright 2022, UiPath, all rights reserved	UiPath first-party package
@uipath/portal-shell	3.351.4	Copyright 2022, UiPath, all rights reserved	UiPath first-party package
@uipath/portal-shell-react	3.149.36	Copyright 2022, UiPath, all rights reserved	UiPath first-party package
@uipath/portal-shell-types	3.326.0	Copyright 2022, UiPath, all rights reserved	UiPath first-party package
@uipath/portal-shell-util	1.114.0	Copyright 2022, UiPath, all rights reserved	UiPath first-party package
@uipath/apollo-lab	25.12.0	Unknown	UiPath first-party package
@uipath/telemetry-client-web	5.1.0	Unknown	UiPath first-party package
khroma	2.1.0	Unknown	MIT per GitHub repo, missing license field in package.json
hyperx	2.5.4	BSD	BSD-2-Clause per LICENSE file, non-SPDX "BSD" in package.json

[0xr3ngar]

@petervachon since other PRs mentioned here were closed, can we close this PR as well?

[petervachon]

Hey @0xr3ngar this is part of an active stacked PR series ([1/5] #628 → [2/5] #629 → [3/5] #630 → [4/5] #631 → [5/5] #632). Not ready to close — happy to keep it open for review!

[0xr3ngar]

Hey @0xr3ngar this is part of an active stacked PR series ([1/5] #628 → [2/5] #629 → [3/5] #630 → [4/5] #631 → [5/5] #632). Not ready to close — happy to keep it open for review!

Ah okay since it is still active, please put this PR in draft and fix the merge conflicts of #629

[0xr3ngar]

@pieman1313 hey Razvan I feel like this is going in the wrong direction, the component and data structure seem super off. Can you take a deeper look into this and let me know if I'm going crazy or something, because the component structure feels super off, and we have to patch things with effects or contexts that I do not think should be there.

[0xr3ngar]

I would extract this copy state handling into a seperate component. This way the state const [copied, setCopied] = useState(false); and the handler handleCopy don't live in this component.

Extract into a generic component

import { useEffect, useState } from 'react';
import { useTranslation } from 'react-i18next';

type CopyToClipboardButtonProps = {
    copyValue: string;
};

export const CopyToClipboardButton = ({
    copyValue,
}: CopyToClipboardButtonProps) => {
    const [hasCopied, setHasCopied] = useState(false);

    const { t } = useTranslation();

    const onClickHandler = async () => {
        await navigator.clipboard
            .writeText(copyValue)
            .then(() => setHasCopied(true))
            .catch(() => setHasCopied(false));
    };

    useEffect(() => {
        let timeout: NodeJS.Timeout;
        if (hasCopied) {
            timeout = setTimeout(() => {
                setHasCopied(false);
            }, 1500);
        }
        return () => clearTimeout(timeout);
    }, [hasCopied]);

    return (
        <Button
            testId={TestId.copyToClipboard}
            size="small"
            variant="text"
            color={hasCopied ? 'success' : 'primary'}
            onClick={async () => {
                await onClickHandler();
            }}
            startIcon={hasCopied ? <CheckIcon /> : <FileCopyIcon />}
        >
            {hasCopied ? t('copied') : t('copy')}
        </Button>
    );
};

[0xr3ngar]

also why are we using and not the component from the lib?

[0xr3ngar]

all these Buttons are literally the same with the only difference being the handler + icon + text. Extract into a shared Component and just pass the handler + text + icon

[0xr3ngar]

I would call it positive | negative

[0xr3ngar]

why are these in the AiChatConfig type? these booleans make no sense to me. Why would a config have the isLoading boolean? Also the showCopyButton is sus? shouldn't these always be shown, same thing goes for showMessageActions

[0xr3ngar]

use component not raw

[0xr3ngar]

dont we also jhave a textarea component in the registry?

[0xr3ngar]

this is super sus, this feels like a code smell. Why is the isStreaming based on the loading and if there is no user and if the last msg id is the current message id

[0xr3ngar]

what is this? cant we create an authofocus ref and attach it to the button or textarea?

const autoFocus = (container: HTMLDivElement | null) => {
if (!container) return;
const focusable = container.querySelector(FOCUSABLE_SELECTOR);
focusable?.focus();
};

export const useAutoFocusFirst = () => {
return autoFocus;
};

const ref = useAutofucusFirst();

...

[0xr3ngar]

this is also super weird side effect that I think should never happen

[pieman1313]

@0xr3ngar valid callouts, @VKravchuk can you have a look? not sure about the provider altogether tbh

[0xr3ngar]

OK I started reviewing the code again but I see smells everywhere :panic:

rn the data flow feels pretty shady. We pass messages into <AiChat />, but then the consumer also maps over messages and renders <AiChatMessage /> manually. On top of that, getAiChatMessageProps re-derives streaming/latest/action state, AiChatMessage re-derives display text/content visibility, and the template owns tool rendering as children

So the same source of truth is being interpreted in a bunch of different places

1. AiChat handles empty state, loading, header, copy conversation, scroll, etc..
2. getAiChatMessageProps handles latest message/streaming/action visibility
3. AiChatMessage handles display text and whether the message is renderable
4. the template handles message mapping and tool rendering

that feels like a pretty big code smell, we’ve kind of split ownership in the worst middle-ground way- AiChat both owns and doesn’t own messages at the same time :/

It also creates a bunch of perf smells. During streaming, we’re constantly re-rendering/recomputing across multiple layers: the template maps every message again, tool parts are checked/rendered again, message props are re-derived, display text is rebuilt, and AiChat also walks messages for shell-level state like copy conversation/loading

I don’t think the current pattern/architecture is healthy at all. I think we need to go back to the drawing board and create a better architecture where message state is derived in one place instead of being re-interpreted and re-computed constantly across multiple components

@pieman1313