fix: show full addresses on join requests; tighten table user display - #1331
fix: show full addresses on join requests; tighten table user display#1331Megha-Dev-19 wants to merge 3 commits into
Conversation
🎬 E2E report — visual review✅ E2E tests passed · commit ▶ Open the live report — every test recorded as a Hosted on GitHub Pages (nothing committed to git) · rebuilt on every push · workflow run |
|
Saw the PR — kicking off a deep review now. Grab a coffee; this one's going to take a minute. Auto-review is configurable in Settings → Auto-review; comment |
Or tick a specific finding above, or comment |
![codaban[bot]](https://avatars.githubusercontent.com/in/3978882?s=60&v=4){kind=small}
There was a problem hiding this comment.
🐗 Codaban — deep review
Half is good, half of it isn't. The table cells (activity-table, proposals-table) really did need trimming — <User> with 8+8 truncation was eating the column — and swapping in a <TooltipUser> + shorter <Address> is the right call there. But the same scalpel got carried into the proposal-detail subtitles and quietly undid PR #1308, which three days ago added resolved profile-name rendering to the transaction-cell rows. So TokenCell, FunctionCallCell, and StakingCell now show raw account ids in venues that have all the horizontal space in the world, and only TokenCell's subtitle still has the tooltip to recover the friendly name. The <TooltipUser triggerProps={{ asChild: false }}> overrides in proposals-table/activity-table are also no-ops — that's already the Tooltip default. Approve-faithfully on the join-request / member-review additions; the proposal-cell side wants a rethink before this lands.
Verdict: 🔴 Request changes — 4 new findings to address.
🎯 Review effort: 2/5 · ~20 min
- 4 new findings
📝 Walkthrough
| File | Change |
|---|---|
nt-fe/components/user.tsx |
Adds truncateAddress prop (default true) on User + UserWithData; extends displayAddress handling so nearcom:-prefixed visible address still feeds explorer/profile with the bare id; centralises addressNode so the same render path is shared by truncate / no-truncate / highlight branches. |
nt-fe/app/(treasury)/[treasuryId]/members/components/member-review-step.tsx |
Passes truncateAddress={false} so each review row shows the full member id, not the trimmed 8+8. |
nt-fe/app/(treasury)/[treasuryId]/members/join-requests/page.tsx |
Same: truncateAddress={false} on the assign-step row so the join-request account id displays fully. |
nt-fe/features/activity/components/activity-table.tsx |
From/To columns re-implemented as <TooltipUser> wrapping a plain <Address> — drops the inner profile fetch path through <User> and shows the bare truncated id with hover-card treatment instead of name+address. |
nt-fe/features/proposals/components/proposals-table.tsx |
Requester cell likewise re-implemented as <TooltipUser> wrapping <Address>; same pattern as activity-table. |
nt-fe/features/proposals/components/expanded-view/batch-payment-expanded.tsx |
Adds withHoverCard to the recipient <User> inside the collapsed-trigger row so the per-recipient summary shows a tooltip card on hover. |
nt-fe/features/proposals/components/transaction-cell/token-cell.tsx |
Removed the profile-fetch + resolveUserDisplayName branch; subtitle is now always the formatted receiver address with 6+6 truncation regardless of whether a profile name exists. |
nt-fe/features/proposals/components/transaction-cell/function-call-cell.tsx |
Deleted the useProfile + resolveUserDisplayName block; the {receiver} interpolation to i18n now passes data.receiver verbatim. |
nt-fe/features/proposals/components/transaction-cell/staking-cell.tsx |
Removed its useProfile + resolveUserDisplayName block; t('validatorSubtitle', { address: validator }) is now invoked with the raw validator id. |
📋 Findings (4)
1. nt-fe/features/proposals/components/transaction-cell/token-cell.tsx:73 — 🎯 Correctness | 🟠 Major | 👍 Worth it
Subtitle in the proposal-detail TokenCell no longer surfaces a resolved profile name as it did until this PR. Previously the cell rendered <span className="min-w-0 truncate block">{displayName}</span> when the receiver had a profile (so 'Greg' showed up where the receiver was greg.near); the new code renders <Address displayReceiver prefixLength={6} suffixLength={6} /> for every case. The PR title frames the change as 'tighten table user display', but TokenCell is the subtitle inside ExpandedView, not a constrained table column — there is room, and reverting this takes away the only place the friendly name was rendered inline. Net result: a labelled-by-name user now reads greg.near (or nearcom:greg.near) everywhere in the proposal detail. Only the surrounding TooltipUser keeps the profile name a hover away, which is fine when the cell has the tooltip — but the non-isUser/non-TooltipUser path that was reachable before is also using the raw address now, with no hover-card fallback at all. Verified by reading token-cell.tsx lines 38–87 and the version that the diff removed. PR #1308 ('prefer DB profile and treasury names in account displays') added this friendly-name rendering on Aug 11; this diff rolls it back for this exact cell four days later, with no i18n / product reason named in the body.
2. nt-fe/features/proposals/components/transaction-cell/function-call-cell.tsx:13 — 🎯 Correctness | 🟠 Major | 👍 Worth it
Removed the useProfile + resolveUserDisplayName and now passes data.receiver straight into t("onReceiver", { receiver: data.receiver }). The subtitle of a function-call row in ExpandedView therefore always shows the raw contract account id (e.g. 'on some-dex.near') where it used to show the resolved name when one was on file (e.g. 'on Some Dex'). Same regression as token-cell.tsx for the same stated reason, except there is no TooltipUser wrapper here to recover the friendly name — <TitleSubtitleCell> renders a plain <div>. Anyone glancing at the proposals table to verify a function-call destination has to manually match the raw id against their address-book entry with no in-page affordance. Verified by reading function-call-cell.tsx:11-14 and the deleted block at HEAD~1 lines 12-19.
3. nt-fe/features/proposals/components/transaction-cell/staking-cell.tsx:41 — 🎯 Correctness | 🟠 Major | 👍 Worth it
Removed the validator useProfile + resolveUserDisplayName block; the validator subtitle in ExpandedView now reads as t('validatorSubtitle', { address: validator }) with the raw validator account id (e.g. 'staking with aurora-validator.near'). Same regression profile as the sibling cells — a validator that has a profile/address-book entry used to render its name, and the cell no longer has any hover-card wrapper that would surface the resolved name. The PR description names 'tighten table user display', but StakingCell is also a subtitle inside ExpandedView, not a table column. Verified by reading staking-cell.tsx:1-65 and comparing to the deleted block at HEAD~1 lines 35-44.
4. nt-fe/features/proposals/components/proposals-table.tsx:345 — 🎨 Style | 🟡 Minor | 🔹 Nitpick
triggerProps={{ asChild: false }} is a no-op override — Tooltip already sets asChild to false as the default, then spreads triggerProps after, so the explicit override here doesn't change anything observable. Activities-table lines 359 / 384 carry the same redundant override. Dead at the call site, harmless to ship, but worth pruning before the pattern propagates further.
Prompt for AI (new findings)
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Fix the following code review issues:
1. `nt-fe/features/proposals/components/transaction-cell/token-cell.tsx` line
73: Subtitle in the proposal-detail `TokenCell` no longer surfaces a resolved
profile name as it did until this PR. Previously the cell rendered `<span
className="min-w-0 truncate block">{displayName}</span>` when the receiver had a
profile (so 'Greg' showed up where the receiver was `greg.near`); the new code
renders `<Address displayReceiver prefixLength={6} suffixLength={6} />` for
every case. The PR title frames the change as 'tighten table user display', but
`TokenCell` is the subtitle inside `ExpandedView`, not a constrained table
column — there is room, and reverting this takes away the only place the
friendly name was rendered inline. Net result: a labelled-by-name user now reads
`greg.near` (or `nearcom:greg.near`) everywhere in the proposal detail. Only the
surrounding `TooltipUser` keeps the profile name a hover away, which is fine
when the cell has the tooltip — but the non-`isUser`/non-`TooltipUser` path that
was reachable before is also using the raw address now, with no hover-card
fallback at all. Verified by reading token-cell.tsx lines 38–87 and the version
that the diff removed. PR #1308 ('prefer DB profile and treasury names in
account displays') added this friendly-name rendering on Aug 11; this diff rolls
it back for this exact cell four days later, with no i18n / product reason named
in the body.
Suggested fix: Render the subtitle as either trimmed address *or* resolved
profile name — keep the old `{nameIsAddress ? <Address .../> :
<span>{displayName}</span>}` shape, but only invoke the profile fetch when a
tooltip hover card is around to take the rest of the surface. Concretely:
reintroduce `useProfile` here only if the spec insists on resolving names in
proposal details; otherwise at least keep `<TooltipUser>` wrapping the
subtitle so the tooltip still shows the resolved label even though the
truncated address is what fits inline.
2. `nt-fe/features/proposals/components/transaction-cell/function-call-cell.tsx`
line 13: Removed the `useProfile` + `resolveUserDisplayName` and now passes
`data.receiver` straight into `t("onReceiver", { receiver: data.receiver })`.
The subtitle of a function-call row in `ExpandedView` therefore always shows the
raw contract account id (e.g. 'on some-dex.near') where it used to show the
resolved name when one was on file (e.g. 'on Some Dex'). Same regression as
`token-cell.tsx` for the same stated reason, except there is no `TooltipUser`
wrapper here to recover the friendly name — `<TitleSubtitleCell>` renders a
plain `<div>`. Anyone glancing at the proposals table to verify a function-call
destination has to manually match the raw id against their address-book entry
with no in-page affordance. Verified by reading function-call-cell.tsx:11-14 and
the deleted block at HEAD~1 lines 12-19.
Suggested fix: Either restore the `useProfile` + `resolveUserDisplayName`
call before the i18n interpolate, so a known name appears inline, or wrap the
subtitle row's receiver in a `<TooltipUser>` and pass the resolved name as
the trigger content. The trivial path that does both is the smallest
restoring change: keep the hook call and the resolveUserDisplayName call you
removed.
3. `nt-fe/features/proposals/components/transaction-cell/staking-cell.tsx` line
41: Removed the validator `useProfile` + `resolveUserDisplayName` block; the
validator subtitle in `ExpandedView` now reads as `t('validatorSubtitle', {
address: validator })` with the raw validator account id (e.g. 'staking with
aurora-validator.near'). Same regression profile as the sibling cells — a
validator that has a profile/address-book entry used to render its name, and the
cell no longer has any hover-card wrapper that would surface the resolved name.
The PR description names 'tighten table user display', but `StakingCell` is also
a subtitle inside `ExpandedView`, not a table column. Verified by reading
staking-cell.tsx:1-65 and comparing to the deleted block at HEAD~1 lines 35-44.
Suggested fix: Reintroduce the resolver before the i18n call so a named
validator continues to read as its friendly name; or, if dropping the
resolution is the actual intent for compactness, wrap the subtitle's
validator label in a `<TooltipUser>` so users still have a way to see the
friendly name (and to copy the raw id) on hover.
4. `nt-fe/features/proposals/components/proposals-table.tsx` line 345:
`triggerProps={{ asChild: false }}` is a no-op override — `Tooltip` already sets
`asChild` to `false` as the default, then spreads `triggerProps` after, so the
explicit override here doesn't change anything observable. Activities-table
lines 359 / 384 carry the same redundant override. Dead at the call site,
harmless to ship, but worth pruning before the pattern propagates further.
Suggested fix: Drop the `triggerProps={{ asChild: false }}` line at proposal
requster cell, and the equivalent in activity-table; otherwise leave a short
`asChild: false` rationale as a comment near the Tooltip default so the next
reader doesn't assume it does something.
Flagging the wrong things? A CODABAN.md in the repo root steers what I read, what I ignore and how blunt I am — I honour it over my own defaults.
🐗 Codaban · deep review · reads the source, not just the diff
|
Saw the update — starting a deep review now. Grab a coffee; I'll be thorough whether you like it or not. Auto-review is configurable in Settings → Auto-review; comment |
Or tick a specific finding above, or comment |
There was a problem hiding this comment.
🐗 Codaban — deep review
Two of the three things this PR claims to do are fine, one of them is doing damage. 'Show full addresses on join requests' is the clean half — the new truncateAddress prop on User is precise, defaults are right, and the two callers use it correctly. 'Tighten table user display' is the half that bites back: the inline subtitle inside the proposal-detail cell now reads as greg.near (or nearcom:greg.near) where it used to read as the resolved profile name, and function-call-cell / staking-cell stripAllLabel path* give up the resolved name without even wrapping the result in a TooltipUser, so the friendly label is gone from the page entirely on those rows. The hover-card fallback that the prior pass asked for is in place for token-cell and the proposals/activity tables, but not for those two siblings — that's the bug-shaped hole the PR shipped around. Net: visible regression in 3 places, no test to paper over it, no comment to mark it as intentional beyond the PR title's tighten. Decision: don't ship it as-is.
Verdict: 🔴 Request changes — 3 new findings, and 3 earlier threads are still open.
🎯 Review effort: 3/5 · ~25 min
- 3 earlier findings still open
- 3 new findings
📝 Walkthrough
| File | Change |
|---|---|
nt-fe/components/user.tsx |
Adds truncateAddress prop with default true; centralizes the address-vs-name render block into an addressNode ternary so the full-address and ellipsized paths share a structure. |
nt-fe/app/(treasury)/[treasuryId]/members/components/member-review-step.tsx |
Passes truncateAddress={false} to the join-profile <User> so members see the full address on the review card. |
nt-fe/app/(treasury)/[treasuryId]/members/join-requests/page.tsx |
Replaces withHoverCard with truncateAddress={false} on the assign-step <User> so full addresses show. |
nt-fe/features/activity/components/activity-table.tsx |
Replaces <User variant="details" withHoverCard> with <TooltipUser><Address>…</TooltipUser> — drops the inline name+address two-line display, keeps the hover card. |
nt-fe/features/proposals/components/expanded-view/batch-payment-expanded.tsx |
Adds withHoverCard to the recipient <User> inside the per-payment collapsible (PaymentDisplay). |
nt-fe/features/proposals/components/proposals-table.tsx |
Replaces <User variant="details" withHoverCard> with <TooltipUser><Address>…</TooltipUser> for the requester column. |
nt-fe/features/proposals/components/transaction-cell/function-call-cell.tsx |
Drops useProfile + resolveUserDisplayName; subtitle now interpolates raw data.receiver into t('onReceiver'). |
nt-fe/features/proposals/components/transaction-cell/staking-cell.tsx |
Drops the validator useProfile block; validatorSubtitle now uses raw validator (and showAllLabel early-return has no TooltipUser fallback). |
nt-fe/features/proposals/components/transaction-cell/token-cell.tsx |
Switched the subtitle to a single <Address displayReceiver prefixLength=6 suffixLength=6> wrapped in <TooltipUser>; also pipes displayAddress={displayReceiver} to the tooltip card so the card shows the prefixed form. |
📋 Findings (3)
1. nt-fe/features/proposals/components/transaction-cell/function-call-cell.tsx:13 — 🎯 Correctness | 🟠 Major | 👍 Worth it
strips resolved name off the function-call subtitle and ships the raw data.receiver into t('onReceiver', { receiver: data.receiver }). The rendered subtitle is <div className="min-w-0 truncate">{subtitle}</div> inside <TitleSubtitleCell> — no TooltipUser wrap anywhere on this cell, so a contract account with an address-book entry (e.g. Some Dex → some-dex.near) is now unidentifiable to a treasury member scanning the row. The sibling token-cell did get a <TooltipUser> wrap in this same PR; this one didn't. Either restore the resolve (mirrors #1/#2 prior pass) or, minimally, wrap the rendered subtitle string in a <TooltipUser> so the friendly label still surfaces on hover.
2. nt-fe/features/proposals/components/transaction-cell/staking-cell.tsx:41 — 🎯 Correctness | 🟠 Major | 👍 Worth it
Same regression as function-call-cell, scoped to the showAllLabel early-return at line ~36: this branch returns <TitleSubtitleCell> with subtitle={t("validatorSubtitle", { address: validator })} interpolated raw, and there's no <TooltipUser> wrap. The non-early-return path delegates through <TokenCell> which does wrap a <TooltipUser> and recovers the resolved name on hover, so this branch is the only place the friendly validator label is silently lost. Restore the resolver before the i18n call, or wrap the subtitle in <TooltipUser accountId={validator}>.
3. nt-fe/features/proposals/components/proposals-table.tsx:343 — 🧹 Maintainability | 🟡 Minor | 🔹 Nitpick
The requester column switches from <User variant="details" withHoverCard> to <TooltipUser accountId={value}><Address address={value} /></TooltipUser> — the <Address> renders with default prefixLength={8}, suffixLength={8}, but the column's <TableCell> only constrains width via the parent wrapper. For a 64-char NEAR account id this works, but for now-defunct sub-accounts (alice.near is 10 chars < 8+8=16 → no ellipsis) the <Address> is fine, while for the longer string of the chainName-aware address the inner div has no truncate to enforce sharp ellipsis at tight column widths. Pre-existing pattern, not strictly a regression this PR introduced, but the changeover to <TooltipUser>+<Address> is the right place to add className="min-w-0 truncate" so the new wrap holds its width the way <User variant="details"> did.
Prompt for AI (new findings)
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Fix the following code review issues:
1. `nt-fe/features/proposals/components/transaction-cell/function-call-cell.tsx`
line 13: `strips` resolved name off the function-call subtitle and ships the raw
`data.receiver` into `t('onReceiver', { receiver: data.receiver })`. The
rendered subtitle is `<div className="min-w-0 truncate">{subtitle}</div>` inside
`<TitleSubtitleCell>` — no `TooltipUser` wrap anywhere on this cell, so a
contract account with an address-book entry (e.g. `Some Dex` → `some-dex.near`)
is now unidentifiable to a treasury member scanning the row. The sibling
`token-cell` *did* get a `<TooltipUser>` wrap in this same PR; this one didn't.
Either restore the resolve (mirrors #1/#2 prior pass) or, minimally, wrap the
rendered subtitle string in a `<TooltipUser>` so the friendly label still
surfaces on hover.
Suggested fix: const t = useTranslations("proposals.expanded");
const { data: profile } = useProfile(data.receiver);
const label = resolveUserDisplayName({
accountId: data.receiver,
profileName: profile?.name,
addressBookName: profile?.addressBookName,
});
const subtitle = (
<TooltipUser accountId={data.receiver} preferAddressBook>
<span>{t("onReceiver", { receiver: label })}</span>
</TooltipUser>
);
2. `nt-fe/features/proposals/components/transaction-cell/staking-cell.tsx` line
41: Same regression as `function-call-cell`, scoped to the `showAllLabel`
early-return at line ~36: this branch returns `<TitleSubtitleCell>` with
`subtitle={t("validatorSubtitle", { address: validator })}` interpolated raw,
and there's no `<TooltipUser>` wrap. The non-early-return path delegates through
`<TokenCell>` which *does* wrap a `<TooltipUser>` and recovers the resolved name
on hover, so this branch is the only place the friendly validator label is
silently lost. Restore the resolver before the i18n call, or wrap the subtitle
in `<TooltipUser accountId={validator}>`.
Suggested fix: const { data: profile } = useProfile(validator ?? null);
const label = validator
? resolveUserDisplayName({
accountId: validator,
profileName: profile?.name,
addressBookName: profile?.addressBookName,
})
: validator;
// inside TitleSubtitleCell's subtitle prop:
subtitle={
validator
? <TooltipUser accountId={validator}>
{t("validatorSubtitle", { address: label ?? "" })}
</TooltipUser>
: undefined
}
3. `nt-fe/features/proposals/components/proposals-table.tsx` line 343: The
`requester` column switches from `<User variant="details" withHoverCard>` to
`<TooltipUser accountId={value}><Address address={value} /></TooltipUser>` — the
`<Address>` renders with default `prefixLength={8}`, `suffixLength={8}`, but the
column's `<TableCell>` only constrains width via the parent wrapper. For a
64-char NEAR account id this works, but for now-defunct sub-accounts
(`alice.near` is 10 chars < 8+8=16 → no ellipsis) the `<Address>` is fine, while
for the longer string of the chainName-aware address the inner div has no
`truncate` to enforce sharp ellipsis at tight column widths. Pre-existing
pattern, not strictly a regression this PR introduced, but the changeover to
`<TooltipUser>+<Address>` is the right place to add `className="min-w-0
truncate"` so the new wrap holds its width the way `<User variant="details">`
did.
Suggested fix: <TooltipUser accountId={value}>
<Address address={value} className="min-w-0 truncate" />
</TooltipUser>
Flagging the wrong things? A CODABAN.md in the repo root steers what I read, what I ignore and how blunt I am — I honour it over my own defaults.
🐗 Codaban · deep review · reads the source, not just the diff
findings 1–3 are intentional. TokenCell / FunctionCallCell / StakingCell render in the requests table (via TransactionCell), not only expanded details. Per design we show address-only there (no name without avatar); profile names stay on hover / in request details. Finding 4 fixed (dropped the no-op triggerProps).
There was a problem hiding this comment.
🐗 Codaban — deep review
Half-trade, half-fix. 'Tighten table user display' sheds friendly names from every transaction subtitle in the proposals table — fine where TooltipUser was already wrapping the cell, plain regression where it wasn't (function-call, staking's showAllLabel branch, and the requester column). 'Show full addresses on join requests' gets its target with a tidy truncateAddress={false} and no ellipsis gymnastics; the join-requests and member-review flows now actually look readable on a long NEAR id. The cleanup commit at HEAD is one line of editorial polish that does nothing in either direction. Six prior threads still stand; the author has ticked them off as 'follow-up' rather than followed through — that's a tracked deferral and I'll allow it, but the asymmetry across the three sibling cells should not survive to the follow-up.
Verdict: ✅ Approved — 6 earlier threads left open as an optional nit; clear it whenever, it's not blocking.
🎯 Review effort: 3/5 · ~25 min
- 6 earlier findings still open
- 0 new findings
📝 Walkthrough
| File | Change |
|---|---|
nt-fe/components/user.tsx |
Adds truncateAddress prop (default true) — when false, renders full address via ; otherwise matches the previous Address/HighlightedText path. |
nt-fe/app/(treasury)/[treasuryId]/members/join-requests/page.tsx |
Switches the join-request member pill from withHoverCard to truncateAddress={false} so the full account id renders inline. |
nt-fe/app/(treasury)/[treasuryId]/members/components/member-review-step.tsx |
Adds truncateAddress={false} to the review-step ; alongside the join-requests page, this commits to no ellipsis in member review. |
nt-fe/features/activity/components/activity-table.tsx |
Replaces in From/To cells with ; loses inline friendly name but keeps hover-card recovery. |
nt-fe/features/proposals/components/expanded-view/batch-payment-expanded.tsx |
Adds withHoverCard to the recipient User; small UX win. |
nt-fe/features/proposals/components/proposals-table.tsx |
Requester column switches from to ; cleanup commit also drops triggerProps={{asChild:false}}. |
nt-fe/features/proposals/components/transaction-cell/token-cell.tsx |
Drops useProfile + resolveUserDisplayName; subtitle always renders . TooltipUser wrap preserved so hover recovers the friendly label. |
nt-fe/features/proposals/components/transaction-cell/function-call-cell.tsx |
Drops useProfile + resolveUserDisplayName; subtitle now interpolates raw data.receiver into 'onReceiver' i18n. No TooltipUser wrapper. |
nt-fe/features/proposals/components/transaction-cell/staking-cell.tsx |
Drops useProfile + resolveUserDisplayName; showAllLabel branch interpolates raw validator into validatorSubtitle. No TooltipUser wrap on this branch. |
🐗 Codaban · deep review · reads the source, not just the diff
1 participant
Fix address/name display issues raised by Olha.
When profile image is not available, show address only instead of name+address display.
🐗 Auto-generated by Codaban
Summary
This PR refactors the
UserandUserWithDatacomponents to support a newtruncateAddressprop, allowing callers to opt out of middle-ellipsis address truncation and display full addresses. It also introduces aTooltipUserwrapper pattern across several table and cell components to simplify how user addresses are rendered with tooltips, removing redundant profile lookups and display name resolution logic from individual cells.Key Changes
components/user.tsxtruncateAddressprop (defaulttrue) to bothUserandUserWithData, controlling whether addresses are truncated with middle ellipsis or shown in full withbreak-all.addressNodethat handles truncation, highlight, and non-truncation cases.max-w-fullwhen truncation is disabled.TooltipUserfor use as a lightweight tooltip wrapper around arbitrary address content.Member review & join requests
truncateAddress={false}inMemberReviewStepandJoinRequestsAssignStepto show full addresses in those contexts.withHoverCardprop usage in join requests in favor of the new truncation control.Activity table
UserwithTooltipUserwrapping anAddresscomponent for both "from" and "to" columns, simplifying rendering and removing profile-based display logic.Proposals table
UserwithTooltipUser+Addressfor the proposer column.Batch payment expanded view
withHoverCardto theUsercomponent for recipient display.Transaction cells (function-call, staking, token)
useProfilecalls andresolveUserDisplayNameusage fromFunctionCallCell,StakingCell, andTokenCell, instead displaying raw addresses directly.TokenCellto always render anAddresscomponent insideTooltipUser, eliminating the name-vs-address branching logic.