[$0] Per diem - Degraded performance in Per diem page

[jponikarchuk]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.1.43-7
Reproducible in staging?: Yes
Reproducible in production?: Unable to check, new feature
If this was caught during regression testing, add the test name, ID and link from TestRail: #60488
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team
Device used: Mac 15.3 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Workspace has per diem rates (use the file below).

1. Go to staging.new.expensify.com
2. Go to workspace settings > Per diem
3. Click on the checkbox of any item.
4. Note that the dropdown button appears first then the checkbox is only marked after a few seconds.
5. On mweb Chrome, tap on the search field and search for a country.
6. Note that typing on the search field is laggy and the search results delay.

Expected Result:

In Step 4, the checkbox will appear marked at the same time as when the dropdown button appears.
In Step 6, on mweb, typing on the search field will not be laggy and the search results will return instantly.

Actual Result:

In Step 4, the dropdown button appears first then the checkbox is only marked after a few seconds.
In Step 6, on mweb, typing on the search field is laggy and the search results delay.

When Step 3 to 6 are performed a few times, both web and mweb devices heat up a lot.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6827135_1746860743185.web.mp4

Bug6827135_1746860743237.mweb_chrome.mp4

Bug6827135_1746860809922!logs-2025-05-10_07_06_29.572.txt

Bug6827135_1746860743195!German_Per_Diem_-Dependent_Tags___2.csv

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021922118344435967366
• Upwork Job ID: 1922118344435967366
• Last Price Increase: 2025-05-13

Issue Owner

Current Issue Owner: @thesahindia

[melvin-bot]

Triggered auto assignment to @zanyrenney (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.

[melvin-bot]

Triggered auto assignment to @pecanoro (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[Eskalifer1]

Hi, I found a bug that is partially related to this task as it also causes performance issues. Is it possible to create a separate task for that with my suggestion for that? I would have raised this issue in Slack, but I still haven't been granted access there, so I can't ask it there yet

2025-05-10.15.30.59.mov

Proposal

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

Per diem - Degraded performance in Per diem page

What is the root cause of that problem?

The problem of constant rendering of the component arises due to a change in the memory reference to the allRatesArray and allSubRates objects

App/src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx

Lines 140 to 144 in 81b1b49

	const allRatesArray = Object.values(customUnitRates);
	const allSubRates = getSubRatesData(allRatesArray);

As a result, although the objects remain unchanged, they have a different memory reference and are therefore considered new objects, which, as a result, causes the subRatesList to change through useMemo:

App/src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx

Line 196 in 81b1b49

[allSubRates, selectedPerDiem, canSelectMultiple, styles.flex2, styles.alignItemsStart, styles.textSupporting, styles.label, styles.pl2, styles.alignSelfEnd],

Which, in turn, re-render the entire component:

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

We need to add useMemo for these 2 objects

 const allRatesArray = useMemo(() => Object.values(customUnitRates), [customUnitRates]);

    const allSubRates = useMemo(() => getSubRatesData(allRatesArray), [allRatesArray]);

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

None

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[Eskalifer1]

Proposal

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

Per diem - Degraded performance in Per diem page

What is the root cause of that problem?

If you take a closer look, the problem is not only for this page, but for all pages that use the useSearchResults hook, it's just that on other pages the operations are performed faster, which is why the difference is very small and hard to notice.

The problem is as follows:

App/src/hooks/useSearchResults.ts

Line 10 in 81b1b49

function useSearchResults<TValue>(data: TValue[], filterData: (datum: TValue, searchInput: string) => boolean, sortData: (data: TValue[]) => TValue[] = (d) => d) {

This hook uses useTransition to de-prioritize certain tasks, so an extra render is performed, and the change itself is performed in useEffect, resulting in only one change but 3 renders.

In turn, the button uses the local state of the component, not the state from the filteredValue,

App/src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx

Line 129 in 81b1b49

const [selectedPerDiem, setSelectedPerDiem] = useState<SubRateData[]>([]);

Because of this, we have selectedPerDiem changing on the first render, useEffect is used for 2 renders, and useTransition is used for the third render, which changes the state of the table

App/src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx

Line 284 in 81b1b49

customText={translate('workspace.common.selected', {count: selectedPerDiem.length})}

App/src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx

Lines 205 to 207 in 81b1b49

	const [inputValue, setInputValue, filteredSubRatesList] = useSearchResults(subRatesList, filterRate, sortRates);
	const sections = useMemo(() => [{data: filteredSubRatesList, isDisabled: false}], [filteredSubRatesList]);

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

The problem clearly arises because of useTransition, because it is through it that changes occur in useEffect that causes every single render, if you remove the logic from useTransition, then the hook will look like this:

function useSearchResults<TValue>(data: TValue[], filterData: (datum: TValue, searchInput: string) => boolean, sortData: (data: TValue[]) => TValue[] = (d) => d) {
 const [inputValue, setInputValue] = useState('');
 const prevData = usePrevious(data);

    const normalizedSearchQuery = inputValue.trim().toLowerCase();
 const filtered = normalizedSearchQuery.length ? data.filter((item) => filterData(item, normalizedSearchQuery)) : data;
 const sorted = sortData(filtered);

    useEffect(() => {
 if (prevData.length <= CONST.SEARCH_ITEM_LIMIT || data.length > CONST.SEARCH_ITEM_LIMIT) {
 return;
 }
 setInputValue('');
 }, [data, prevData]);

    return [inputValue, setInputValue, sorted] as const;
}

With this approach, only one render will occur and the changes will be synchronized and occur simultaneously, but then the logic from useTransition is lost (I don't know what it is for, but I'm sure it is needed, because it would not be added for nothing).

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

None

What alternative solutions did you explore? (Optional)

Another way to avoid changing the useSearchResults hook is to set the “Selected” button to a value from the filteredSubRatesList instead of the local state, so that both the button and the table use the same value, but in this case, it may have a bad impact on the UX, since the changes will not occur immediately, but with a delay
Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[pecanoro]

@daledah Are you handling it here? So I can assign you to the issue

[daledah]

@pecanoro Yes, I'm looking for RCA and solution for this issue.

[daledah]

Slightly improved the performance here. I'll investigate and improve further.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[francoisl]

Opening to external contributors to help speed things up with getting a resolution for this.
For context, we already know the issue is coming from #60488. @daledah also already has a partial linked fix in this comment.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~021922118344435967366

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @s77rt (External)

[pecanoro]

@s77rt We have a proposal, can you take a look to see if it fixes the issue?

[kavimuru]

Still repro in 44-6 version.

https://github.com/user-attachments/assets/793555bd-af9c-485c-b342-0b0f8206654d
https://github.com/user-attachments/assets/a1e8e6f0-a8ea-4f13-a5c4-e9460ae5497a

[mountiny]

Screen.Recording.2025-05-13.at.13.53.50.mov

confirmed that this is ok for 100 entries and barely noticeable for less which is the normal number of per diem rates, hence demoting.

However assigned @daledah and @thesahindia to handle it as this is a regression from the new PR and should be fixed urgently. Do not post proposals on new issues until these are resolved please

[LorenzoBloedow]

Since this has been demoted, just wanted to share what I learned while investigating this issue and a potential solution...

I used both the React profiler and Chrome Devtools and found that it seems all Views are rendered when selected as not a single component had a self time of more than 4ms (and most had around 0.5ms, which when multiplying by 1400 is 700ms).

Take this with a grain of salt since I didn't spend much time investigating but I think we should optimistically select items, triggering the render only for visible items while storing the actual amount of selected items lazily with InteractionManager and at the same time setting a loading flag, and when the user finally performs an action if the loading flag is true, (most of the time it probably won't be) show a loading spinner, otherwise instantly perform the action.

[thesahindia]

Any updates, @daledah?

[daledah]

I'm still looking for exact root cause and solution for this issue. Will give an update soon.

[daledah]

Still investigating

[daledah]

I have a PR here, improved a bit on the selection performance.