perf: only call expensive getSearchOptions once#54681
Conversation
Reviewer Checklist
Screenshots/VideosAndroid: NativeScreen.Recording.2025-01-03.at.13.16.40.mp4Android: mWeb ChromeScreen.Recording.2025-01-03.at.13.18.23.mp4iOS: NativeScreen.Recording.2025-01-03.at.13.12.01.mp4iOS: mWeb SafariScreen.Recording.2025-01-03.at.13.14.09.mp4MacOS: Chrome / SafariScreen.Recording.2025-01-03.at.13.09.03.mp4MacOS: DesktopScreen.Recording.2025-01-03.at.13.09.35.mp4 |
suneox
left a comment
There was a problem hiding this comment.
This change still works the same as the current behavior
There was a problem hiding this comment.
This PR looks good, and if it speeds things up then that's great and we can merge it. The injecting of searchOptions seems like a good idea
I wanted to share a few thoughts about why search is built the way it is, maybe it will will be helpful in future @hannojg
Check out this graph of search related components:

tl;dr
- In the beginning we had just Router as a popover that we could open anywhere in
E/App - later we wanted to have the exact same autocomplete list on the "Search (results) Page", So me and Jakub have split router into:
SearchRouterandSearchRouterList - right now Router can be accessed from Search in some cases, but cannot in others (if you have Input visible in search, then you will focus it); Input on
SearchPageandSearchRouterare exclusive - however soon, as part of #52317, we will make the Input be always displayed, and so the
SearchRoutercomponent will never be displayed on the Search page - maybe this can lead to some further enhancements
|
Hey @hannojg - FYI @marcaaron is on parental leave so will be OOO for a few months. If you need another reviewer from the Expensify team, you'll need to find someone else. |
|
@luacmartins do you mind taking a look here as you worked a lot on Search? I already reviewed this and it's not a very big change. |
luacmartins
left a comment
There was a problem hiding this comment.
LGTM! Thanks for working on this improvement.
|
@hannojg we have conflicts |
…etSearchOptions-once
|
Conflicts fixed! |
|
Thanks! |
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
|
🚀 Deployed to staging by https://github.com/luacmartins in version: 9.0.85-0 🚀
|
1 similar comment
|
🚀 Deployed to staging by https://github.com/luacmartins in version: 9.0.85-0 🚀
|
|
🚀 Deployed to staging by https://github.com/luacmartins in version: 9.0.85-0 🚀
|
1 similar comment
|
🚀 Deployed to staging by https://github.com/luacmartins in version: 9.0.85-0 🚀
|
|
🚀 Deployed to staging by https://github.com/luacmartins in version: 9.0.85-0 🚀
|
|
🚀 Deployed to production by https://github.com/mountiny in version: 9.0.85-4 🚀
|
|
🚀 Deployed to production by https://github.com/mountiny in version: 9.0.85-4 🚀
|
Explanation of Change
Calling
getSearchOptionsis expensive. Before this PR we were callinggetSearchOptionstwice when opening the search page, once inSearchRouterand once inSearchRouterList.To show the negative effect of that, here are the performance numbers on a lower end android device, where the impact of calling
getSearchOptionstwice is highlighted:it can be seen that of the
6194.89msto open the search page790.51mswere "wasted" by creating the search options twice.Fixed Issues
$ #46590
PROPOSAL: #46590
Tests
Offline tests
QA Steps
Same as testing steps
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
XRecorder_31122024_141510.mp4
Android: mWeb Chrome
XRecorder_31122024_143305.mp4
iOS: Native
Simulator.Screen.Recording.-.iPhone.16.Pro.-.2024-12-31.at.14.27.58.mp4
iOS: mWeb Safari
Uploading Simulator Screen Recording - iPhone 16 Pro - 2024-12-31 at 14.28.31.mp4…
MacOS: Chrome / Safari
CleanShot.2024-12-31.at.14.06.58.mp4
MacOS: Desktop
CleanShot.2024-12-31.at.14.37.28.mp4