Uplift common Onyx subscriptions from ReportActionItem to parent list components

[mountiny]

Problem

ReportActionItem is rendered once per report action in a FlatList. It contains several useOnyx calls that subscribe to the same global Onyx key for every instance. For a list of N report actions, each of these common keys gets N identical subscriptions instead of 1.

For example, with 50 visible report actions, ONYXKEYS.CARD_LIST alone creates 50 separate subscriptions that all return the same data.

Proposed Solution

Move all common (non-instance-specific) Onyx subscriptions from ReportActionItem to the parent list components (ReportActionsList and MoneyRequestReportActionsList), and pass the data as props through the component chain.

Subscriptions to uplift (8 total):

Key	Variable
ONYXKEYS.NVP_INTRO_SELECTED	introSelected
ONYXKEYS.COLLECTION.TRANSACTION_DRAFT	allTransactionDrafts
ONYXKEYS.CARD_LIST	cardList
ONYXKEYS.BANK_ACCOUNT_LIST	bankAccountList
ONYXKEYS.PERSONAL_POLICY_ID	personalPolicyID
ONYXKEYS.COLLECTION.REPORT_METADATA{reportID}	reportMetadata
ONYXKEYS.COLLECTION.POLICY_TAGS{policyIDForTags}	policyTags
usePolicyForMovingExpenses() hook (3 internal subscriptions)	policyForMovingExpensesID

Instance-specific subscriptions that remain in ReportActionItem:

• useOriginalReportID (depends on each action)
• useReportIsArchived (depends on originalReportID)
• useReportTransactions (per-action iouReport)
• linkedTransactionRouteError (per-action transactionID)

Impact

• Eliminates ~8 redundant Onyx subscriptions per list item (plus 3 from the usePolicyForMovingExpenses hook)
• For a typical list of 50 report actions, this removes ~400-550 redundant subscription registrations
• Follows the existing pattern already used for allReports, policies, personalDetails, etc.

[melvin-bot]

@mountiny Still overdue 6 days?! Let's take care of this!

[mountiny]

@adhorodyski @TMisiukiewicz What is the status of this proposal now? #83205 (comment)

[TMisiukiewicz]

@mountiny I vibe-refactored 😅 LHN to use useOnyx directly in the list items. The plan now is to:

• assess if we are still hitting the same issue as we did in the past
• if yes, identify what are the core bottlenecks in Onyx right now that prevent us from using it on this level

Will share results once I do all the measurements. Is it a good candidate for a separate issue from this one?

When it comes to this issue in particular, I believe @adhorodyski had some ideas to refactor it to match the "composition over configuration" rule

[mountiny]

That sounds like a good plan @TMisiukiewicz! Sounds like the main goal is to test the performance of useOnyx though so that would be the issue to put that effort under

[TMisiukiewicz]

I did the measurements, and unfortunately we are still hitting the same issue that we had in the past. My decomposition of LHN ended up with ~50 useOnyx calls on item-level and provided great results when it comes to re-renders - the footprint is minimal, because it re-renders only parts that really need it.

However, the core problem is scrolling the list - when we do that, it constantly creates and destroys that ~50 hooks in every component that goes into the viewport, which runs entire ~400 LOC machinery, including multiple refs, effects, connecting/disconnecting etc for each one of them. Tested it on release build on Android and just a couple of fast scrolls on a list with 5k reports caused 100% CPU usage for multiple seconds that led to killing the app.

I'm in touch with @fabioh8010 and we are trying to validate some ideas to make useOnyx as simple as possible

[melvin-bot]

@mountiny Whoops! This issue is 2 days overdue. Let's get this updated quick!

[mountiny]

I think we can close this one now as we will handle it separately once the useOnyx improvements are in place