[No QA] MenuItem decomposition - usages with avatars by war-in · Pull Request #98862 · Expensify/App

war-in · 2026-08-18T11:27:12Z

Explanation of Change

Part 2 of the MenuItem decomposition — the avatar-led rows. Adds the Leading and Label primitives, a typography variant on Description, testID on Root and the presets, and a MenuItemEntity preset, then migrates the avatar call sites.

Two notes for reviewers:

MenuItemEntity is deliberately narrow — a UserAvatar plus an always-on chevron. Rows needing a workspace avatar, an ID-driven ReportActionAvatars, or no chevron drop to raw composition rather than growing the preset.
MenuItem.Description gained a variant. placeholder reproduces the legacy font bump that happened automatically when a row had no title, so title-less rows keep rendering at the standalone size.

Fixed Issues

$ #99408
PROPOSAL:

Tests

Run npm run storybook and open the Components/MenuItemComparison story
Verify that in every card of the Phase 2 — avatars section, the Legacy, Composable and Preset renders are identical
Verify that the Phase 1 — icon rows cards below are still identical

Migrated rows, checked against main side by side:

Open Settings > Security > Add copilot, pick a member and continue, and verify the confirmation row shows their avatar, name and login
Open Settings > Profile > Status and verify each delegator row shows an avatar, display name and login, spaced evenly
Open Settings > Security, set a vacation delegate, and verify the row shows the delegate's avatar, name and login; clear it and verify the empty row shows Vacation delegate at the larger standalone font size
Start a new task from the global create menu and verify the Assignee and Share rows show avatars, labels, tooltips on hover, the Required hint while Share is empty, and the chevron
Open a workspace > Members > a member and verify the Profile row still navigates and is spaced from the section below
Open Settings > Security > multifactor authentication revoke page and verify each device row shows its title with a working Revoke button on the right
Send an invoice from the global create menu and verify the Send from field shows the workspace avatar, name and Workspace, and only shows a chevron when the sender can be changed

Offline tests

Mostly N/A — a component refactor with no API or Onyx changes. One row keeps offline feedback:

Go offline
Open Settings > Security and set a vacation delegate
Verify the delegate row greys out with the pending style, and that the error row and its dismiss action still appear below it when the request fails

QA Steps

N/A

PR Author Checklist

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

# Conflicts: # src/pages/workspace/companyCards/assignCard/ConfirmationStep.tsx

codecov · 2026-08-18T11:31:17Z

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
src/components/MenuItem/index.ts	`100.00% <ø> (ø)`
src/components/MenuItem/layout/MenuItemLeading.tsx	`100.00% <100.00%> (ø)`
src/components/MenuItem/layout/MenuItemRoot.tsx	`92.85% <100.00%> (ø)`
...omponents/MenuItem/leaves/leading/MenuItemIcon.tsx	`100.00% <100.00%> (ø)`
.../components/MenuItem/leaves/text/MenuItemTitle.tsx	`100.00% <100.00%> (ø)`
...em/leaves/text/description/MenuItemDescription.tsx	`100.00% <100.00%> (ø)`
...ext/description/MenuItemDescriptionPlaceholder.tsx	`100.00% <100.00%> (ø)`
src/components/MenuItem/presets/MenuItemAction.tsx	`100.00% <100.00%> (ø)`
...ents/MenuItem/presets/MenuItemAvatarNavigation.tsx	`100.00% <100.00%> (ø)`
...components/MenuItem/presets/MenuItemEmptyField.tsx	`100.00% <100.00%> (ø)`
... and 20 more
... and 18 files with indirect coverage changes

war-in · 2026-08-18T14:47:01Z

@codex review

war-in · 2026-08-18T14:47:07Z

@MelvinBot review

chatgpt-codex-connector · 2026-08-18T14:56:25Z

Codex Review: Didn't find any major issues. You're on a roll.

Reviewed commit: e1333cc5d2

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

MelvinBot · 2026-08-18T15:15:30Z

Review — looks solid ✅

This is a faithful, well-scoped continuation of the MenuItem decomposition. The migrations are mechanical and preserve behavior, the new primitives (Leading, Label, Description variant, testID) are cleanly typed, and the MenuItemEntity preset is appropriately narrow. All real CI checks are green (typecheck, ESLint, Bun/jest, Storybook, Oxfmt), new files hit 100% coverage, and the only red check is Check independent approval (the approval gate, not a code failure).

I spot-checked a few behavior-parity concerns and verified two of the migrated rows at runtime on web — both render correctly:

Migrated row	Result
New Task `Assignee` / `Share` (`TaskFieldRow`)	avatar + bold title + supporting line + chevron, aligned ✅
Vacation delegate empty state (`placeholder` variant)	single standalone-size line + chevron ✅

Parity checks I confirmed against the legacy component

Required hint gating (DynamicNewTaskPage). Old MenuItem only rendered rightLabel under {!title && !!rightLabel && !errorText} (MenuItem/MenuItem.tsx:1160). The new shouldShowRequiredLabel={!shareDestination?.displayName} reproduces exactly that (title empty ⇒ hint shown) — no regression.
Trailing spacing. menuItemTrailing uses gap2, matching the old mr2 between rightLabel and the right icon, so the Required + chevron pairing keeps its gap.
Type narrowing. MenuItem.Title accessibilityLabel={displayName} typechecks because const hasValue = !!displayName narrows displayName inside the hasValue && branch — clean.

Non-blocking notes

Default-avatar color on the UBO / beneficial-owner rows. BeneficialOwnersList and CompanyOwnersListUBO dropped displayInDefaultIconColor (plus iconWidth/Height={40}) when moving to MenuItemEntity with accountID={CONST.DEFAULT_NUMBER_ID} (BeneficialOwnersList.tsx). UserAvatar with no source renders the default avatar for that ID, which should match, but these flows aren't in your Test steps — worth an eyeball to confirm the fallback tint is identical to main.
DelegatorList lost styles.pr2. The old row carried containerStyle={[styles.pr2, styles.mt1]}; the new wrapper is [styles.mt1, styles.gap1] (DelegatorList.tsx:38), so the trailing right padding is gone. Almost certainly intentional given the new Row padding, just flagging it.

Nothing here blocks. Nice, tidy migration.

Runtime verification below.

New Task confirm page — migrated Assignee and Share rows (avatar, bold title, supporting line, chevron)

Vacation delegate placeholder — single standalone-size line with a chevron

JakubKorytko

good split, and the typography matches legacy where it counts. I checked the placeholder variant against legacy descriptionTextStyles and they are the same.

Two things I would fix before merge. The cardholder avatar in ConfirmationStep now renders the grey fallback instead of the coloured default. And the subscript avatar no longer follows the row's hover state. Everything else is API shape and consistency.

JakubKorytko · 2026-08-19T09:59:28Z

-                    return;
+        <>
+            <View style={[styles.ph5, styles.mt2]}>
+                <MenuItem.Label>{translate('workspace.invoices.sendFrom')}</MenuItem.Label>


MenuItem.Label is outside Root here but inside Root in ScheduleCallConfirmationPage and TaskFieldRow. Both are right: this one matches legacy isLabelHoverable={false}, the others match the default true. But MenuItemLabel's doc only says "The label above a menu item's Row", so nothing records that the placement is what decides whether the label picks up the row's hover background. Worth saying so in the component doc.

Actually, we decided to always show the label outside the pressable, so I'll fix those usages. Thanks for noticing!

JakubKorytko · 2026-08-19T10:08:36Z

@MelvinBot could you double-check that all of my comments in the review are accurate?

MelvinBot · 2026-08-19T10:12:42Z

Double-checked all three against the source on this branch — all three are accurate. ✅

1. placeholder variant == legacy descriptionTextStyles — accurate.
The no-title legacy path applies getFontSizeStyle(variables.fontSizeNormal) + getLineHeightStyle(variables.fontSizeNormalHeight) over textLabelSupporting (MenuItem/MenuItem.tsx:693-702), and the new PLACEHOLDER variant applies the exact same two on the same base (MenuItemDescription.tsx:50). Typography matches.

2. ConfirmationStep cardholder avatar → grey fallback instead of coloured default — accurate (real regression).
Old passed icon={cardholder?.avatar ?? getDefaultAvatarURL({accountID})}, so a missing avatar became the coloured default keyed to the account. New passes avatarSource={cardholder?.avatar} (i.e. undefined when absent) (ConfirmationStep.tsx:196-197). UserAvatar only derives the coloured default from accountID when the source is a default-avatar URL string — isDefaultAvatar(undefined) is false (UserAvatarUtils.ts:197-213), so getAvatar returns undefined (:412-423) and UserAvatar renders the grey FallbackAvatar (UserAvatar.tsx:73). Only bites when cardholder.avatar is genuinely empty (users with a backend default-avatar URL still resolve to the coloured default, since that URL passes isDefaultAvatar).

Fix: pass the coloured default as the source, e.g. avatarSource={cardholder?.avatar ?? getDefaultAvatarURL({accountID: cardholderAccountID ?? CONST.DEFAULT_NUMBER_ID})}. Same latent gap exists on any MenuItemEntity call that relies on accountID alone with no avatarSource (e.g. the UBO lists) — worth deciding whether MenuItemEntity/UserAvatar should treat undefined source + real accountID as the coloured default so callers don't each have to.

3. Subscript avatar no longer follows the row's hover state — accurate.
The legacy ID-driven path fed the row's interaction state into the avatar: subscriptAvatarBorderColor={getSubscriptAvatarBackgroundColor(isHovered, pressed, …)} plus pressed/isHovered-dependent secondaryAvatarContainerStyle (MenuItem/MenuItem.tsx:926-937). The migrated rows render ReportActionAvatars bare in MenuItem.Leading with only singleAvatarContainerStyle and none of those props (DynamicNewTaskPage.tsx:269-270, :284-285), so the subscript border no longer blends into the hovered/pressed row background. The concrete case is the interactive Task Share row (workspace expense chat → subscript badge); the ScheduleCall specialist row is non-interactive, so it's unaffected.

Fix needs the compound API to surface the row's hover/press state into the leading cell — the same interaction state MenuItem.Icon already consumes — so ReportActionAvatars there can set subscriptAvatarBorderColor. Right now MenuItem.Leading doesn't expose it.

Net: the two "fix before merge" items are legit regressions, and both are edge/hover states that wouldn't show up in a static side-by-side — nice catches. Neither is a blocker for the split itself.

JakubKorytko · 2026-08-19T10:13:51Z

@MelvinBot there is more than 3 of my comments in the review, I think it is around 14 comments in total, could you double-check that all of my comments in the review are accurate?

MelvinBot · 2026-08-19T10:23:35Z

I went through all 14 inline comments against the code on this branch. Your two "fix before merge" calls are both real bugs, and 12 of the 14 comments are accurate as written. Two need a correction: the subscript-hover comment reaches the right conclusion via a wrong mechanism, and the DelegatorList padding comment has the numbers backwards.

Verdict per comment

Comment	Verdict
Cardholder grey fallback (`ConfirmationStep`)	✅ Accurate — real bug
`MenuItemEntity` doc says "default avatar" but renders grey fallback	✅ Accurate
`source={icons.FallbackAvatar}` is a no-op (`CompanyOwnersListUBO`)	✅ Accurate
`callFunctionIfActionIsAllowed` dropped on raw-composition rows	✅ Accurate (real, low-impact)
`MENU_ITEM_DESCRIPTION_VARIANT` not re-exported from the barrel	✅ Accurate
Story `MenuItem.Label` placement ≠ call sites (spacing)	✅ Accurate
`InvoiceSenderField` label placement / hover doc	✅ Accurate
Story `Onyx.merge` runs at import, unawaited	✅ Accurate
Icon+title+desc hand-composed 3× → preset?	✅ Accurate (count checks out)
Presets have no `style` escape hatch	✅ Accurate
Ternary simpler than the record	✅ Accurate
`filter(Boolean)` on `[title, description]`	🟡 Accurate with a nuance
Subscript avatar loses hover state (`TaskFieldRow`)	🟡 Bug is real, mechanism is wrong
`DelegatorList` lost `pr2` right padding	❌ Numbers inverted

The two corrections

1. Subscript hover (comment) — the seam is real, but not for the reason stated. You wrote that the ready-made ReportActionAvatars node "can never reach" MenuItemInteractionContext. It actually can: MenuItemRoot renders children inside the provider (MenuItemRoot.tsx:96-105), and React context resolves by tree position at render time, not by where the element was constructed. So a node built in DynamicNewTaskPage but rendered under <MenuItem.Leading> is inside the provider and could read the hover state — the real reason the ring doesn't react is simply that ReportActionAvatars/SubscriptAvatar don't consume that context and the call site passes no subscriptAvatarBorderColor. Everything else lines up: legacy fed the ring a hover/press-derived color (MenuItem.tsx:927-938), and when the prop is omitted the ring falls back to a static theme.componentBG (SubscriptAvatar.tsx:71) while the row hovers to hoverComponentBG → visible seam on a policy_expense_chat share destination. One minor add: the seam only appears when the Share row is interactive (!task?.parentReportID); when it's locked to a parent report there's no hover so no seam. Because the node genuinely renders inside the provider, your MenuItem.Avatars leaf idea is the cleaner of the two fixes — it can just consume the context.

2. DelegatorList padding (comment) — the direction is backwards. pr2 is paddingRight: 8 (spacing.ts:630), not an 8px addition on top of the 20. As you say, the more specific paddingRight wins in Yoga — so it overrides popoverMenuItem's paddingHorizontal: 20, giving the old row 8px of right padding, not 28px. The new row has no containerStyle and MenuItem.Root applies popoverMenuItem directly (MenuItemRoot.tsx:79), so right padding is now 20px. Net: the row went from 8px → 20px on the right, so the one-line login gets ~12px less room and truncates sooner, the opposite of "8px more room." The observation that pr2 was dropped and spacing shifted is correct — just the magnitude and direction are off.

One nuance

filter(Boolean) (comment): right that with both title and description typed as required string the filter is effectively dead weight — but not literally "can never drop anything": string still admits '', and an empty-string description would be filtered out ("title, " vs "title"). Your suggested fix (description?: string) is the right call and makes the filter do real work.

Bottom line

Both of your headline "fix before merge" bugs — the cardholder grey avatar and the subscript hover seam — are genuine (I verified the avatar-resolution chain through getAvatar/isDefaultAvatar/useFallBackAvatar and the legacy vs new subscript wiring). The rest of the review is accurate. Just tweak the hover comment's mechanism and flip the DelegatorList padding numbers.

MelvinBot · 2026-08-19T10:33:18Z

I went through all 14 and traced each claim to source on the PR head (e1333cc). 11 hold up exactly as written, 2 are right but have a small imprecision, and 1 reaches the wrong conclusion (though it does flag a real change). Details below.

#	Comment (file:line)	Verdict
1	`ConfirmationStep.tsx:196` — cardholder default avatar	✅ Accurate
2	`DynamicNewTaskPage.tsx:286` — subscript hover ring seam	✅ Accurate
3	`MenuItemRoot.tsx:42` — dropped `callFunctionIfActionIsAllowed`	✅ Accurate
4	`MenuItemEntity.tsx:34` — doc doesn't match `UserAvatar`	✅ Accurate
5	`MenuItemComparison.stories.tsx:160` — label `mb2` not identical	✅ Accurate
6	`MenuItemDescription.tsx:64` — variant not re-exported from barrel	✅ Accurate
7	`IOURequestEditReportCommon.tsx:319` — icon+title+description hand-composed 3×	✅ Accurate
8	`WorkspaceMemberDetailsPage.tsx:431` — no style escape hatch	✅ Accurate
9	`MenuItemDescription.tsx:48` — record vs ternary	⚠️ Accurate, one wrong sub-detail
10	`CompanyOwnersListUBO.tsx:94` — `FallbackAvatar` is a no-op	✅ Accurate
11	`MenuItemEntity.tsx:54` — `filter(Boolean)` redundant	⚠️ Accurate, tiny caveat
12	`DelegatorList.tsx:32` — right padding change	❌ Conclusion is backwards
13	`InvoiceSenderField.tsx:69` — label hover-placement doc	✅ Accurate
14	`MenuItemComparison.stories.tsx:49` — module-scope `Onyx.merge`	✅ Accurate

The one that's wrong

#12 (DelegatorList padding) — your conclusion is reversed. Every sub-fact you cite is correct (pr2 = paddingRight: 8, popoverMenuItem = paddingHorizontal: 20, and legacy put containerStyle on the same pressable). But the comment says the more specific paddingRight wins and then computes 28px (20 + 8) — that's additive, which contradicts the "wins" premise. If paddingRight: 8 wins over paddingHorizontal: 20, legacy right padding was 8px, and the migrated row (bare popoverMenuItem) is now 20px. So the row gained ~12px of right padding and the one-line login has less room before truncating — the opposite of "about 8px more room." The underlying point (padding did change) is real; the direction and magnitude are off.

The two with a small imprecision

#9 (MenuItemDescription record): the record-with-both-branches-built-every-render observation is correct and MenuItemDescriptionVariantStyles is indeed used only here. But MenuItemDescriptionVariant is not "used elsewhere" — it's file-local (defined and used only in MenuItemDescription.tsx, never exported); consumers import the MENU_ITEM_DESCRIPTION_VARIANT const, not the type. So both aliases are local, which if anything strengthens the "simplify to a ternary" suggestion.

#11 (MenuItemEntity filter(Boolean)): correct that title/description are both required string, so for every value actually passed today it's equivalent to a plain join. Strictly though, filter(Boolean) isn't a pure no-op — an empty-string description ('') is falsy and would be dropped, avoiding a trailing ", ". Minor, and it doesn't change your suggestion to make description optional.

Notes on a couple of the accurate ones

Add Expensify eslint #3: confirmed — MenuItemRoot passes onPress straight through with no callFunctionIfActionIsAllowed, while the presets wrap it. One extra wrinkle: the presets call callFunctionIfActionIsAllowed(onPress) with a single arg, so they don't forward isAnonymousAction the way legacy did — the raw-composition rows still lose the guard entirely, as you said.
Moving files and folders a little #4: the sibling accountID doc just above it ("Picks the default avatar when avatarSource is absent") has the same inaccuracy and is worth fixing in the same pass.
Fix babel build on master #5: the story is inconsistent rather than uniformly unwrapped — the cards near lines 160 and 602 drop the mb2 wrapper, but others (≈520, ≈563) keep it, so only those two cards mismatch legacy.
Convert the store to using promises #6: minor — it's actually 4 call sites deep-importing the const, but your core point (it's the only deep import into leaves/ from outside the folder) holds.

Net: your review is in good shape. The only substantive correction is #12's direction/number; #9 and #11 each have a one-line inaccuracy that doesn't undermine the suggestion.

MelvinBot · 2026-08-19T11:14:03Z

I wasn't able to kick off the adhoc builds from here — dispatching workflows is blocked in my environment, so nothing was triggered.

Adhoc builds come from the Build and deploy apps for testing workflow (testBuild.yml), which is workflow_dispatch-only. To run it:

Open Actions → Build and deploy apps for testing → Run workflow
Set APP_PULL_REQUEST_URL to https://github.com/Expensify/App/pull/98862
Tick I reviewed this pull request and verified that it does not contain any malicious code
Leave Web / iOS / Android checked as needed, then Run workflow

One heads-up: the workflow gate requires the person dispatching it to be an Expensify employee with write access to Expensify/App. Your account currently resolves to read on the repo, so if the run bounces at the "Validate build request" step, you'll need a teammate with write access (e.g. your C+ reviewer or an internal engineer) to start it for you.

Pujan92

LGTM!

war-in · 2026-08-31T13:26:15Z

@roryabraham it's all yours

roryabraham

Looking really close, just noticed a couple small things.

# Conflicts: # src/components/VacationDelegateMenuItem.tsx

war-in · 2026-09-01T12:55:40Z

@roryabraham both comments addressed

github-actions · 2026-09-01T18:15:35Z

🚧 roryabraham has triggered a test Expensify/App build. You can view the workflow run here.

OSBotify · 2026-09-01T18:17:02Z

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

github-actions · 2026-09-01T18:19:16Z

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #98862.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-1307b28-b66008c-d074b73588aaa129038dd9f45cdf331beb9176b7/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-1307b28-b66008c-4b8f0b291eb720eaf7231b96ba8593f6c2737d1a/index.html

Web 🕸️
https://98862.pr-testing.expensify.com

👀 View the workflow run that generated this build 👀

OSBotify · 2026-09-02T00:35:54Z

🚀 Deployed to staging by https://github.com/roryabraham in version: 9.4.66-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

MelvinBot · 2026-09-02T00:39:22Z

🤖 No help site changes are required for this PR. I did not create a docs PR.

This is Part 2 of the MenuItem decomposition — an internal component refactor. Nothing a help site article documents changed.

How I checked

I reviewed all 34 changed files against App/docs/articles:

No copy changed. The PR touches zero src/languages/*.ts files. Every migrated call site keeps the exact same translation key it used before — common.vacationDelegate, task.assignee, common.share, common.required, multifactorAuthentication.revoke.revoke, workspace.common.workspace, workspace.companyCards.assignNewCards.title, and so on. The keys just moved from props (title=, description=, label=) onto the new composable children (<MenuItem.Title>, <MenuItem.Description>, <MenuItem.RightLabel>).

The only new hardcoded strings are Storybook fixtures. Strings like Vacation delegate, John Doe, and Expensify Inc appear only in src/stories/MenuItemComparison.stories.tsx, which never ships to users.

No behavior or navigation changed. Your own test plan is a side-by-side identity check against main — the Legacy, Composable, and Preset renders must be pixel-identical. The Description variant="placeholder" exists specifically to preserve the legacy font bump on title-less rows, not to change it. No new settings, tabs, buttons, or flows were added, and no existing ones were renamed or moved.

Affected surfaces already documented on the help site are unchanged in the UI: Copilot confirmation, vacation delegate, task assignee and share rows, workspace member profile, multifactor authentication revoke, company card assignment, and invoice sender. Each renders the same labels in the same places as before.

Since help site articles describe what users see and do — not how components are composed internally — there is nothing to update.

If you expected a user-visible change here that I missed, reply with the specific screen and I'll take another look.

view run

kavimuru · 2026-09-02T00:47:13Z

@war-in Just to ensure , we don't have to QA this PR

roryabraham · 2026-09-02T05:08:18Z

I think regression tests are sufficient

OSBotify · 2026-09-02T21:11:22Z

🚀 Deployed to staging by https://github.com/roryabraham in version: 9.4.68-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	cancelled 🔪

MelvinBot · 2026-09-02T21:15:31Z

🤖 No help site changes required. I did not create a docs PR.

This is an internal component refactor (part 2 of the MenuItem decomposition). Nothing a help site article describes has changed — no new feature, no renamed setting, no altered navigation path, and no new or removed user-facing copy.

How I checked

1. No copy or translation changes. No src/languages/*.ts file is touched. Every translate() key in the diff is preserved — the keys just move from MenuItem props to composed children. For example, in src/components/MoneyRequestConfirmationList/sections/InvoiceSenderField.tsx, description={translate('workspace.common.workspace')} becomes <MenuItem.Description>{translate('workspace.common.workspace')}</MenuItem.Description>. Same string, same row.

2. No behavior changes. The PR body states it is a component refactor with no API or Onyx changes, and the PR is marked [No QA]. Conditional logic such as the Send from chevron is extracted to a named variable (isInteractive) but keeps the same condition.

3. The only new strings are Storybook-only. All the new literal text ("John Doe", "Phase 2 — avatars", "Assignee") lives in src/stories/MenuItemComparison.stories.tsx, which is a developer-facing Storybook fixture and never ships to users.

4. Affected flows already documented correctly. I checked the articles covering the migrated rows — including Delegate-when-out-of-office.md and Manage-Copilot-Access.md. They describe settings paths and outcomes, not row layout, so they remain accurate.

If a follow-up phase of this decomposition does change a visible label or flow, ping me again and I'll open the docs PR then.

view run

OSBotify · 2026-09-02T21:48:38Z

🚀 Deployed to production by https://github.com/francoisl in version: 9.4.68-1 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

Bundle Size Analysis (Sentry):

Android

war-in added 6 commits August 17, 2026 12:57

feat: add primitives to support menu item with avatars

1496e71

feat: add MenuItemEntity

ff567b6

refactor: migrate avatar-related callsites

a966434

refactor: extract variant styles for description

053be2e

Merge branch 'main' into war-in/menu-item-decomposition-entity

29de266

# Conflicts: # src/pages/workspace/companyCards/assignCard/ConfirmationStep.tsx

feat: add testID to root and presets

37561ce

melvin-bot Bot assigned war-in Aug 18, 2026

war-in added 4 commits August 18, 2026 14:27

chore: MenuItemComparison.stories.tsx update

61809ab

fix: move description variants to MenuItemDescription

f404831

fix: improve spacing and correctness

d2df096

fix: pass accessibilityLabel to skip rerenders

e1333cc

war-in mentioned this pull request Aug 18, 2026

MenuItem — composition over configuration #96202

Open

JakubKorytko reviewed Aug 19, 2026

View reviewed changes

war-in added 6 commits August 20, 2026 08:34

Merge branch 'main' into war-in/menu-item-decomposition-entity

e37b6f3

feat: add MenuItemField

0dd9b7c

fix: remove unnecessary MenuItemDescriptionVariantStyles

bb62688

fix: don't filter when both exist

03b670e

fix: move onyx data to loaders

81218ae

fix: remove unnecessary FallbackAvatar

be33b2b

Pujan92 approved these changes Aug 31, 2026

View reviewed changes

melvin-bot Bot requested a review from roryabraham August 31, 2026 12:15

war-in added 2 commits August 31, 2026 14:56

Merge branch 'main' into war-in/menu-item-decomposition-entity

af9163c

fix: ConfirmDelegatePageTest

8917e51

fix: ConfirmDelegatePageTest

f10dbce

roryabraham requested changes Aug 31, 2026

View reviewed changes

Comment thread src/components/MenuItem/leaves/text/MenuItemDescription.tsx Outdated

Comment thread src/components/MenuItem/presets/MenuItemEmptyField.tsx Outdated

war-in added 3 commits September 1, 2026 13:01

Merge branch 'main' into war-in/menu-item-decomposition-entity

fc08e5b

# Conflicts: # src/components/VacationDelegateMenuItem.tsx

fix: split description into default and placeholder version

3d16db5

fix: remove optional onPress from MenuItemEmptyField

0066307

war-in force-pushed the war-in/menu-item-decomposition-entity branch from fbba7cc to 0066307 Compare September 1, 2026 12:54

war-in added 2 commits September 1, 2026 18:47

Merge branch 'main' into war-in/menu-item-decomposition-entity

9665e3a

tests: update VacationDelegateMenuItemTest

4482a44

roryabraham approved these changes Sep 1, 2026

View reviewed changes

roryabraham merged commit 1307b28 into Expensify:main Sep 1, 2026
34 of 35 checks passed

OSBotify mentioned this pull request Sep 2, 2026

Deploy Checklist: New Expensify 2026-09-02 #100087

Closed

82 tasks

roryabraham changed the title ~~MenuItem decomposition - usages with avatars~~ [No QA] MenuItem decomposition - usages with avatars Sep 2, 2026

melvin-bot Bot mentioned this pull request Sep 2, 2026

[Due for payment 2026-09-09] MenuItem decomposition Phase 2 — MenuItemEntity preset (avatar rows) #99408

Closed

MelvinBot mentioned this pull request Sep 3, 2026

[Due for payment 2026-09-17] MenuItem decomposition Phase 3 — MenuItemWithTopDescription replacement preset #100312

Open

Uh oh!

Conversation

war-in commented Aug 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation of Change

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

codecov Bot commented Aug 18, 2026 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

war-in commented Aug 18, 2026

Uh oh!

war-in commented Aug 18, 2026

Uh oh!

chatgpt-codex-connector Bot commented Aug 18, 2026

Uh oh!

MelvinBot commented Aug 18, 2026

Review — looks solid ✅

Non-blocking notes

New Task confirm page — migrated Assignee and Share rows (avatar, bold title, supporting line, chevron)

Vacation delegate placeholder — single standalone-size line with a chevron

Uh oh!

JakubKorytko left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

JakubKorytko Aug 19, 2026

Choose a reason for hiding this comment

Uh oh!

war-in Aug 21, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

JakubKorytko commented Aug 19, 2026

Uh oh!

MelvinBot commented Aug 19, 2026

Uh oh!

JakubKorytko commented Aug 19, 2026

Uh oh!

MelvinBot commented Aug 19, 2026

Verdict per comment

The two corrections

One nuance

Bottom line

Uh oh!

MelvinBot commented Aug 19, 2026

The one that's wrong

The two with a small imprecision

Notes on a couple of the accurate ones

Uh oh!

MelvinBot commented Aug 19, 2026

Uh oh!

Pujan92 left a comment

Choose a reason for hiding this comment

Uh oh!

war-in commented Aug 31, 2026

Uh oh!

roryabraham left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

war-in commented Sep 1, 2026

Uh oh!

Uh oh!

github-actions Bot commented Sep 1, 2026

war-in commented Aug 18, 2026 •

edited

Loading

codecov Bot commented Aug 18, 2026 •

edited by github-actions Bot

Loading

JakubKorytko left a comment •

edited

Loading