[$1,000] Improve lists performance by not calling useOnyx in list items

[adhorodyski]

Goal of this effort is to make lists across EApp more performant.

We'll achieve this by moving useOnyx connections from within render items up the tree to the list level.
This PR should be used as an example.

Lists to cover:

• LHN fix(perf): directly pass props to lhn items #63362
• ReportActionsList with all child components of ReportActionsListItemRenderer listed here
• SearchList with items declared here

How to compare your results?

1. Record before+after performance traces using React Profiler.
2. Import these into https://kacper-mikolajczak.github.io/rcc/ (with the 'before' being a baseline).
3. Share your results with the PR

Issue Owner

Current Issue Owner: @trjExpensify

[mountiny]

Proposal in Slack here

[mountiny]

From convo with Adam:

What we will need to do is something like this:

• so it's List -> PureReportActionItem -> TransactionPreview (some useOnyx calls) -> TransactionPreviewContent (some useOnyx calls)
• should be List (some useOnyx calls) -> PureReportActionItem -> TransactionPreview -> TransactionPreviewContent

so at the end every child to PureReportActionItem moves its useOnyx up the tree and does not hold any connection

I think we could make all the items of the Search list one task and then divide up the ReportActionOne into multiple ones.

• MoneyRequestPreview
• MoneyRequestReportPreview
  • EmptyMoneyRequestReportPreview.tsx
  • MoneyRequestReportPreviewContent.tsx
• TransactionPreview
• ActionableItemButtons.tsx
• ChronosOOOListActions.tsx
• ExportIntegration.tsx
• ExportWithDropdownMenu.tsx
• IssueCardMessage.tsx
• MoneyReportView.tsx
• MoneyRequestAction.tsx
• MoneyRequestView.tsx
• ReportActionItemImage.tsx
• ReportActionItemImages.tsx
• ReportPreview.tsx
• TaskAction.tsx
• TaskPreview.tsx
• TaskView.tsx
• TripDetailsView.tsx
• TripRoomPreview.tsx

I think we can aim for a PR for each just to make it as easy to test and revert if needed, but if there are some really similar feel free to combine them to one PR (but not too many in one)

[mountiny]

@hoangzinh @Pujan92 Has been chosen to complete this task for $1000 each. Ideally you split up the work/ components on who will implement what and who will review it (vice versa). Can you please organize together on that?

Then please write a summary of the plan here for us and lets get cooking @adhorodyski @TMisiukiewicz Will help review the code as well. If you have any questions or anything is unclear, ping us in slack. @mjasikowski and me will be helping lead this from the internal team perspective.

[hoangzinh]

Hi @mountiny, will we wait for @mjasikowski to split up those into issues, then @Pujan92 and I will discuss how we divide those issues?

[hoangzinh]

When a PR is ready for review, will we loop @adhorodyski and @TMisiukiewicz to get early reviews, or wait until C+ completes the review checklist?