[Awaiting payment 2026-03-06] Improve MoneyRequestReportTransactionItem render time

[rlinoz]

Optimize the re-renders and render time of MoneyRequestReportTransactionItem and its tree.

Issue Owner

Current Issue Owner: @greg-schroeder

[melvin-bot]

Triggered auto assignment to @greg-schroeder (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

MoneyRequestReportTransactionItem has poor render performance, causing sluggish UI when viewing reports with many transactions — especially during interactions like selecting/deselecting transactions.

What is the root cause of that problem?

There are three compounding root causes:

1. No memoization on the item component or its main child

Neither MoneyRequestReportTransactionItem (MoneyRequestReportTransactionItem.tsx:161) nor TransactionItemRow (TransactionItemRow/index.tsx:825) is wrapped in React.memo. Every parent re-render cascades unconditionally to every transaction row and its entire subtree.

2. Unstable callback references cause full-list re-renders on every selection change

In MoneyRequestReportTransactionList, the callbacks toggleTransaction (line 238), isTransactionSelected (line 251), handleLongPress (line 436), and handleOnPress (line 451) all depend on selectedTransactionIDs from useSearchContext(). When any single transaction is selected/deselected, selectedTransactionIDs gets a new array reference, which invalidates all four callback references, triggering a re-render of the parent list — and since the child items aren't memoized, every item re-renders.

3. No virtualization

The transaction list renders all items via .map() (MoneyRequestReportTransactionList.tsx:579-597) with no virtualization. Every transaction item is mounted and rendered regardless of whether it's visible on screen.

Additionally, each TransactionItemRow render is expensive:

• A columnComponent useMemo with ~30 dependencies builds JSX for all ~25 column types (TransactionItemRow/index.tsx:271-620), including a call to computeReportName() which traverses report hierarchies
• Child components TypeCell, ChatBubbleCell, and TransactionItemRowRBR create 7 Onyx subscriptions per row (3 from RBR, 3 from ChatBubbleCell, 1 from TypeCell)
• TotalCell calls getTransactionDetails() which computes far more than just the amount
• Inline arrow functions in MoneyRequestReportTransactionItem (lines 114, 126, 129, 149, 152) create new function references every render

What changes do you think we should make in order to solve the problem?

Step 1: Wrap MoneyRequestReportTransactionItem in React.memo

This is the highest-impact, lowest-risk change. It prevents unnecessary re-renders when props haven't actually changed.

Step 2: Stabilize callback references in the parent list

• Remove selectedTransactionIDs from toggleTransaction's dependency array by using a functional update pattern or a ref:

  // Use a ref to avoid dependency on selectedTransactionIDs
  const selectedTransactionIDsRef = useRef(selectedTransactionIDs);
  selectedTransactionIDsRef.current = selectedTransactionIDs;
  
  const toggleTransaction = useCallback((transactionID: string) => {
      const current = selectedTransactionIDsRef.current;
      // ... toggle logic using current
  }, [setSelectedTransactions]);
  

• Pass isSelected as a pre-computed boolean prop (already done) but ensure the parent doesn't cause re-renders by stabilizing the callbacks above.

Step 3: Convert inline arrow functions in MoneyRequestReportTransactionItem to stable callbacks

Replace the inline onPress, onLongPress, and onButtonPress handlers with useCallback-wrapped versions that depend on transaction.transactionID (which is stable).

Step 4 (optional, higher effort): Wrap TransactionItemRow in React.memo

This provides a second layer of defense and benefits other consumers of TransactionItemRow (like TransactionListItem in search).

What alternative solutions did you explore? (Optional)

• Virtualizing the transaction list (FlatList/FlashList): This would limit render work to visible items, similar to how SearchList uses FlashList. However, this is a larger architectural change and the transaction list is typically not hundreds of items long.
• Reducing per-item Onyx subscriptions: The 7 Onyx subscriptions per row (from TypeCell, ChatBubbleCell, TransactionItemRowRBR) could be hoisted to the list level and passed down as props. This would reduce subscription overhead but is a larger refactor.
• Splitting the columnComponent useMemo: Instead of one giant useMemo for all ~25 columns, compute only the columns that are actually displayed. This reduces wasted work but is less impactful than memoization.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.