[Due for payment 2025-06-09] [$125] Per diem - Degraded performance in Per diem page

[jponikarchuk]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com 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): applausetester+khcategory19@applause.expensifail.com
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-06-10

Issue Owner

Current Issue Owner: @zanyrenney

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