Improve performance of reasonForReportToBeInOptionList

[mountiny]

Coming from here

Background

The Left Hand Navigation (LHN) sidebar displays a list of reports relevant to the user. To determine which reports appear, the system calls a function—reasonForReportToBeInOptionList—for every report during each LHN render. In typical accounts, this can mean hundreds of calls per render. The function performs multiple checks, including data lookups, state evaluations, and conditional logic. Because it runs so frequently, even small inefficiencies compound into noticeable UI delays. The current implementation includes repeated lookups, redundant function calls, and expensive computations that execute regardless of whether they are needed.

Problem

When the LHN render process triggers repeated evaluations of reasonForReportToBeInOptionList across many reports, if the function performs redundant or unnecessarily expensive operations, then overall UI rendering slows down.

Solution

Reorganize the function to minimize unnecessary work and enable faster short‑circuiting:
Reorder conditional checks so the cheapest evaluations occur first, allowing early exit when possible.Cache repeated data lookups and function results within the scope of a single evaluation to avoid recomputing identical values.Defer expensive computations until after all cheaper checks have passed, ensuring they only run when absolutely necessary.

These changes reduce redundant operations and improve the function’s execution time. Measurements show an 8% performance improvement in function’s execution time. Large accounts with many unread reports will benefit the most from these changes.

Issue Owner

Current Issue Owner: @elirangoshen

[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.

[mehdiakiki]

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

Every time the LHN sidebar renders, it calls reasonForReportToBeInOptionList for every report in the list itself. In case of hundreds of reports, the lag gets real.
The function makes Onyx calls/lookups, uses arrays, and calls expensive helpers before it checks cheaper things that would make it exit earlier. Sot that's exactly what needs to be fixed.

What is the root cause of that problem?

I went through the function in src/libs/ReportUtils.ts (line 9207) and found a handful of things that jumped out:

The parentReportAction lookup runs before we even know the report is valid.

We eagerly build an array we usually don't need. We do Object.values(currentReportActions) right after validation and that creates a fresh array every single call.

The currentReportId comparison is buried way too deep. Checking report.reportID === currentReportId is basically free since tht's just a str comparison. But that's currently in between of other onyx lookups that are expensive succh as canAccessReport etc...

We compute shouldHideReport before checking isPinned. isPinned is cheap but other functions are more expensives and are called before it.

isEmptyReport and shouldHideReport these two functions are also computed too early, so the reports that exit early should not have to call these.

In the focus mode block, we re-fetch actions we already have. We are calling expensive getOneTransactionThreadReportID before checking if the report is muted which could avoid that check entirely

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

Everything stays within reasonForReportToBeInOptionList in src/libs/ReportUtils.ts. So the idea, is to re-order teh checks so that the cheap ones run first. Basically, use the principle of lazy execution whenever that's possible and feasible.

1. Validate the basics before touching Onyx

Right now parentReportAction gets resolved and the null guard runs after it. They need to be flipped.

2. Need to check if we get the focused report immediately after validation

if (report.reportID === currentReportId) {
    return CONST.REPORT_IN_LHN_REASONS.IS_FOCUSED;
}

This is the cheapest exit we have and it fires every time the user has a report open. There's no reason it should run after a bunch of Onyx lookups for actions and parent reports

3. Move draftComment and isPinned checks earlier in the function's execution

Both are simple property reads.

4. Defer isEmptyReport and shouldHideReport to later on on where they are actually being used

Basically, we need to move isEmptyChat and canHideReport computations just before the first condition that's using it.

5. For the focus mode path, check the mute condition first and then reuse what we already fetched

if (isInFocusMode) {
    if (getReportNotificationPreference(report) === CONST.REPORT.NOTIFICATION_PREFERENCE.MUTE) {
        return null;
    }
    const oneTransactionThreadReportID = getOneTransactionThreadReportID(
        report, chatReport, currentReportActions   // reuse instead of re-fetching
    );
    const oneTransactionThreadReport = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${oneTransactionThreadReportID}`];
    return isUnread(report, oneTransactionThreadReport, isReportArchived)
        ? CONST.REPORT_IN_LHN_REASONS.IS_UNREAD
        : null;
}

So we avoid getOneTransactionThreadReportID lookup and at the same time we avoid calling Onyx a second time

6. Drop the isInDefaultMode variable.

Cosmetic change That's a minimal change but yet it is only used once and that's just !isInFocusMode we could just use it as is inline.

These changes do not change how the function works, but they provide changes that limit unneeded calls and wasted computations that compound when hundreds of reports are being loaded.
So the existing tests in tests/unit/ReportUtilsTest.ts should pass without needing new tests.

What alternative solutions did you explore? (Optional)

We could move this to a derived Onyx value so that it recomputes only when the source of truth data actually changes, rather than per re-render of LHN. This is an architectural change and we need ot make sure we track all the dependencies in order to ensure data is correct. And I could explore this option if the team deems this approach viable.

[elirangoshen]

Daily update: I prepared it for review and There's conflicts so I will deal with them. I had higher priority assignment as well so I couldn't do much progress today.

[elirangoshen]

I address the comments and now the pr is ready for review