Decompose PureReportActionItem to isolate hooks per action type

[cristipaval]

Problem

PureReportActionItem is a 2,200+ line monolith with 100+ if/else if branches. Every render evaluates the full chain and runs all top-level hooks (useOnyx, useMemo) regardless of which action type is actually being displayed.

Proposed fix

Extract groups of related branches into focused child components (PolicyChangeLogContent, ApprovalFlowContent, PaymentContent, etc.), then move action-type-specific hooks into those children so they only run when needed.

Issue Owner

Current Issue Owner: @LukasMod

[LukasMod]

I'm trying to keep phases clean so it will be possible to prepare PRs commit by commit later.
First I want to check how much we can get from low-risk changes in component structure only with this strategy.

Done:

• Phase 1: Add unit tests (c564c511c1e)
• Phase 2: Extract 4 content renderers: SimpleMessageContent, PaymentContent, PolicyChangeLogContent, ApprovalFlowContent (62e0b39961f)
• Phase 3 (ActionableWhisperContent): Extract 3 actionable whisper branches (fraud alert, join request, mention whisper) into a self-contained component with their own button logic (dd852e7f55d)
• Phase 4 (ChatMessageContent): Extract the default chat message branch along with 3 useOnyx calls, 2 custom hooks, actionableItemButtons useMemo, moderation state, and 2 context provider useMemos (2a04dc707df)
• Phase 5 (ModifiedExpenseContent + ReimbursementDeQueuedContent): Extract remaining content renderers (4c923d0f4f8 + 570e13e2f87)

Current results:

I stopped refactor to get some measurements. Metric itself and profiler results sadly stays the same. There is noise in results so no winner so far. For sure its getting more readable with each step (8 new components from PureReportActionItem).
I noticed some consistency in Performance trace improvements when tested chat with ~90 items:

• ReportActionItem: 240ms → 165ms (-31%, total time for all list items)
• PureReportActionItem: 92ms → 66ms (-28%, total time for all list items)
• -6 subscription per message (-12%)
• -425 total onyx subscriptions

---

In progress (low risk):

• Phase 6: Push cardList into self-subscribing CardBrokenConnectionContent
• Phase 7: Push taskReport into TaskPreview
• Phase 8: Push linkedReport + iouReportOfLinkedReport into TripRoomPreview

[LukasMod]

I finished phases 6-8 and 3 more ideas:

• Phase 9: Push userBillingGracePeriodEnds into ChatMessageContent
• Phase 10: Extract ReimbursementQueuedContent — remove bankAccountList + missingPaymentMethod from per-item path and move it down to specific branch
• Phase 11: Conditional useOnyx in ReportActionItemMessage for IOU branch

With phase 11 I managed to get some consistent improvement in span metric.
PureReportActionItem was reduced from ~2250 lines to ~1400.
Each comment message creates 14 less useOnyx subscriptions.

Phase	Avg Span	Span Delta	Subs/msg	Sub Delta
Baseline	838ms	--	+52	--
Phase 5	824ms	(noise)	+46	-6 (-12%)
Phase 10	843ms	(noise)	+41	-11 (-21%)
Phase 11	773ms	-65ms (-8%)	+38	-14 (-27%)

I will split main PR to small ones

[LukasMod]

Update:
Phase 1 (unit tests): #87347 - ready for review
Phase 2 (basic split): I will prepare four small PRs, one for each new grouping component. I’ll keep this based on the unit test branch for now and mark it as a draft until the tests are merged.

1. refactor: PureReportActionItem, add SimpleMessageContent #87359
2. refactor: PureReportActionItem, add PaymentContent #87399
3. refactor: PureReportActionItem, add ApprovalFlowContent #87462
4. refactor: PureReportActionItem, add PolicyChangeLogContent #87492

Phase 3 (Whisper components): #87507 (-1 useOnyx from moving down useReportIsArchived)

[cristipaval]

Thanks @LukasMod! Love the investigation and the detailed updates!