packages/components/src/ui/chat/ChatInbox.stx draws the selected contact three ways — the avatar, the name, the role — and all three are plain text in a fixed header:
<Avatar :src="selectedAvatar" :alt="selectedName" size="md" className="shrink-0" />
<div class="flex-1">
<h2 class="font-semibold text-fg-strong" :text="selectedName"></h2>
<p class="mt-0.5 text-xs text-fg-muted" :text="selectedRole"></p>
</div>An app that has profiles has nowhere to put the link. In hq.training a chat contact now carries the handle of their public profile, and the native thread header opens it — tapping the face at the top of a thread goes to that person's page, the way Messages opens a contact card. The web thread, which is this component, cannot do the same, so the same app behaves two ways depending on which view you are in.
What would be enough. Either of these; the first is smaller.
- A
personslot (orheaderslot) on the selected-contact header, so the app decides what the face and name are. The component keeps its current markup as the default. - The component reads an optional
hrefoff a contact row —person.hreforperson.profile_url— and wraps the avatar and name in an<a>when it is set. Nothing changes for a contact without one.
A slot is the better shape: a link is one thing an app might want there, and an app that wants a menu, a presence dot or a "View athlete" button is not served by a second prop.
Not urgent — it blocks the web half of stacksjs/hq.training#222, and the native half ships without it.