Debounce search page and reduce number of tooltips created

[marcaaron]

Details

Noticed we were creating a ton of tooltips for the "rooms" that are returning in search results. Sometimes 100+ tooltips which caused performance to degrade. Also added some debounce in since we are filtering the options rather often and triggering re-renders. When we can wait until the user is done typing to do this.

Fixed Issues

Fixes #3601

Tests

QA Steps

1. Command + k to bring up search function
2. Verify typing is smooth
3. Verify search results appear reasonably fast

Tested On

• Web
• Mobile Web
• Desktop
• iOS
• Android

Screenshots

Web

Mobile Web

Desktop

iOS

Android

[robertjchen]

Great fix! 👍

[OSBotify]

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

[Julesssss]

Hey @marcaaron, I believe this line introduced a regression to the IOU Request flow. If you create an IOU from within a DM, participantList is null, causing a crash.

[Julesssss]

Here's the issue, I've assigned it to you as I'm about to end my day. Feel free to assign it to me for Monday if you aren't able to pick this up.

[marcaaron]

Fix was merged #3675

[OSBotify]

🚀 Deployed to staging in version: 1.0.71-1🚀

platform	result
🤖 android 🤖	success ✅
🖥 desktop 🖥	success ✅
🍎 iOS 🍎	success ✅
🕸 web 🕸	success ✅

[Julesssss]

Thanks for fixing 👍

I was a bit unsure about the deployBlocker label in this case, as this PR hadn't yet been deployed. Does it make sense to apply the label to an issue that hasn't yet been deployed to staging? Wouldn't that have the potential to block an in-progress release candidate for a deployBlocker issue that isn't part of that release? Or are we excluding deployBlocker issues that are not yet on staging?

CC @roryabraham

[roryabraham]

The deployBlocker label doesn't actually "physically" block anything – the only way we check to see if all deploy blockers are resolved is by looking at the issue body for the open StagingDeployCash. If there are any unchecked boxes, then we'll block the production deploy.

So it's safe to add the DeployBlockerCash label to a PR that has not yet been deployed. If another staging or production deploy happens, then the deploy blocker should be added to the checklist. Does that make sense?

[Julesssss]

Awesome, yes it does. Thanks for explaining!

[OSBotify]

🚀 Deployed to production in version: 1.0.73-3🚀

platform	result
🤖 android 🤖	success ✅
🖥 desktop 🖥	success ✅
🍎 iOS 🍎	success ✅
🕸 web 🕸	success ✅

[fedirjh]

Hey there, I want to point out that this PR introduced a regression in #17200 where the search list displays an invalid phone number error but still displays the phone number in the result for a brief moment. The headerMessage should’ve been debounced with debouncedUpdateOptions which would ensure data consistency.