App: [$250] Multiple requests to `SearchForReport` when searching for a user

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: 1.4.63-11 Reproducible in staging?: y Reproducible in production?: y If this was caught during regression testing, add the test name, ID and link from TestRail: Email or phone of affected tester (no customers): Logs: https://stackoverflow.com/c/expensify/questions/4856 Expensify/Expensify Issue URL: Issue reported by: @iwiznia Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1713544197266279

Action Performed:

Click the search icon from the LHN
Open network tab
Type something in the search bar

Expected Result:

Shouldn’t be numerous requests to SearchForReport

Actual Result:

Numerous requests to SearchForReport is sent

For proposals - see this comment:

We should either add or change the code so that it debounces the calls in a “sane” manner, probably the same as we did for the userIsTyping events

Workaround:

unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari
MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/Expensify/App/assets/38435837/2e415c87-5457-4702-b731-68e5dcbda6e5

View all open jobs on GitHub

Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01c8c8aa1341923a49
Upwork Job ID: 1782550098085855232
Last Price Increase: 2024-04-29

About this issue

Original URL
State: open
Created 2 months ago
Comments: 23 (19 by maintainers)

Most upvoted comments

@ahmedGaber93 I believe we can avoid this by having a separate debounce time for API call (1s) and keeping the current debounce time for filtering as is (300ms, so it’s interactive right after the user types). We don’t have to make them the same value.

@tienifr yes, I think you need to follow that if we decide to use long debounce time for API >= 1s.

ahmedGaber93 on Apr 26, 2024

Still not sure if 1s is the best number… doing some live tests will probably help out to know.

@iwiznia Since the backend search API call itself now takes around 2.5s - 4s, I think “delaying calling the API” for an additional few hundreds milliseconds won’t make a difference to real users.

As long as the live search is smooth (for which we will keep the current debounce time), I think 1s is ok for the delay of the API call.

tienifr on Apr 26, 2024

@iwiznia There is another behavior appear after increasing the time, the result for the saved data in onyx storage will also debounce because filtering data depend on debouncedSearchValue change. Should we also solve this?

@ahmedGaber93 I believe we can avoid this by having a separate debounce time for API call (1s) and keeping the current debounce time for filtering as is (300ms, so it’s interactive right after the user types). We don’t have to make them the same value.

Then we have the best of both worlds here. What do you think?

tienifr on Apr 26, 2024