[$250] Update Search page to always show search input and type tabs at the top

[shawnborton]

Right now we face some inconsistent behavior with the Search page depending on if you use a LHN nav item or if you search via the router. The LHN has default navigational items that don't use search input across the top of the page, but we do indeed show a search input if you search for something via the router. Furthermore, the default Search experience does not show a type selector across the top, however we are planning to show one across the top if you searched for something via the router.

In order to clean up these consistencies, we're proposing these incremental updates to the search page:

• Always show a search input at the top of the page
• Do not show expense types in the LHN. Instead, use the LHN for default suggested searches as well as saved searches
  • The two default searches will be "All expenses" and "Expenses waiting on you" to start
• Move the status selector (All, drafts, outstanding, etc) to be within the RHP filters panel

That gives us something like this:

CleanShot.2024-11-11.at.16.52.54.mp4

On mobile, the idea is to use a UI like this where we use a full-page router experience that you can close in the top right corner after focusing:

CleanShot.2024-11-11.at.16.51.48.mp4

On the note of filters, the idea is to move Status into the list of filters in the RHP:

One small update though is we'd like to make it so you can select multiple statuses as once, which more closely matches OldDot's behavior for expense/report status selection:

cc @luacmartins @JmillsExpensify @trjExpensify @Expensify/design

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021864720653992598336
• Upwork Job ID: 1864720653992598336
• Last Price Increase: 2024-12-05

Issue Owner

Current Issue Owner: @anmurali

[luacmartins]

@Kicu anyone from SWM interested in working on this one?

[Kicu]

@luacmartins hm, right now Im actually refactoring this code, so that the input has the autocomplete behavior similar to router, and so that the query always stays correct, if a user keeps editing it and resubmitting.

The change described here would be affecting the (react) components flow in the header of the Search Results page, and I think it would be better if someone doing this waits for my PR.
I can open a draft later today so you could add HOLD to this issue, and my PR should be done withing 1-2 days I think + review.

And yes, we would definitely like to work on this in SWM, I'll post this internally and someone will pick it up. For now perhaps assign me to this?

[Kicu]

here is the aforementioned PR: #52568 still a draft, but now we can link it

[luacmartins]

I agree we should hold on your changes. Thanks for the linked PR and looking forward to getting someone from SWM assigned to the issue!

[shawnborton]

Another thing I wanted to note for this issue - I think it makes way more sense to bring the multi-select button out of the router so it sits below it like this:

Curious what everyone thinks about that though.

[dannymcclain]

I think it makes way more sense to bring the multi-select button out of the router so it sits below it like this

Where does it show up now? Inside the search input where the filters button is? Anyhoo, I agree and I think what you're showing in that mock looks good and makes sense. 👍

[shawnborton]

Yeah it currently replaces the filter icon within the search bar, which feels a little strange.

[dannymcclain]

Agree with that. Definitely like what you posted much better.

[shawnborton]

Not overdue, still working through this one.

[luacmartins]

Still holding

[melvin-bot]

@shawnborton, @luacmartins Eep! 4 days overdue now. Issues have feelings too...

[Kicu]

Waiting on merge of: #52568
I remember about this PR and someone from SWM will pick it up once 52568 is close to merging. Currently scope is growing a bit for the PR.

[shawnborton]

Not overdue, see comment above

[trjExpensify]

The linked PR has merged, so shall we take this issue off hold? I'm also going to move this now into #migrate, so we track it there as a key foundational issue to get in place for the rest of our recently discussed plans. Excited for it!

[luacmartins]

We'll be working on a follow up to that PR to fully enable the features on the Search results page, so I don't think we should remove the hold quite yet

[trjExpensify]

Alright, sounds good!

[Kicu]

We can now update the HOLD to be on this issue: #53126

I estimate the PR should be ready in 1-2 days.

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.89-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Simplify single line TextInput styling to allow for different heights #55343

If no regressions arise, payment will be issued on 2025-02-04. 🎊

For reference, here are some details about the assignees on this issue:

• @rayane-djouah requires payment through NewDot Manual Requests
• @SzymczakJ does not require payment (Contractor)

[melvin-bot]

BugZero Checklist: The PR adding this new feature has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@rayane-djouah] Please propose regression test steps to ensure the new feature will work correctly on production in further releases.
• [@anmurali] Link the GH issue for creating/updating the regression test once above steps have been agreed upon.

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

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

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

[SzymczakJ]

As it turns out the Reports Page performance was a blocker for us. I suspect that adding SearchRouterInput to it(with the RouterList underneath) was just a critical point when the whole page became just too heavy.
I will start working on performance issue right away and try to open up two PRs:

1. overalll performance boost for Reports Page,
2. reopen the old PR which I will also review and make more performant than it was before

WDYT about this plan @luacmartins?

[luacmartins]

Sounds good! Thanks for working on this!

[ikevin127]

@SzymczakJ #52317 (comment) sounds good to me!

We had a report of somebody encountering a Maximum update depth exceded. error when opening Reports page, which neither me nor luacmartins were able to reproduce while testing the PR, here's the Slack conversation, not sure there's much to do about it since we don't know why it's happening on their side but I thought I should mention it since a rework is planned.

♻ Edit:

There's been some developments from @pac-guerreiro in the Slack conversation linked above, some findings on possible reason as to why the issue happens on their side, quote:

If userCardList or workspaceCardFeeds is undefined, we default them as a new object, which causes allCards to be re-calculated

Since allCards is a dependency in a useEffect that invokes setAutocompleteSubstitutions, which starts an infinite loop where the component keeps re-rendering

To test this and be able to reproduce (on the previous PRs SearchPageHeaderInput logic which was reverted), you'd have to have cards saved / added (userCardList or workspaceCardFeeds).

My response in the Slack conversation was:

The findings make sense on why the logic would cause the error, since on first mount, the useOnyx value will be undefined (if no cached data is present) until the data is actually loaded from IndexedDB (which is not instant).

For this we can expose the useOnyx ResultsMetadata status which on first mount will be loading and then loaded when the data actually becomes available. But since we fallback the useOnyx values to {} on mount, when data is actually loaded and you do have cards saved / added -> results in infinite loop in that useEffect since when having cards the object will change from empty (fallback) to not empty (cards data).

We should keep this in mind and test on accounts with cards added as well to make sure this won't happen again.

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.92-6 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Redesign search to always show search input(mobile + desktop). #55078

If no regressions arise, payment will be issued on 2025-02-07. 🎊

For reference, here are some details about the assignees on this issue:

• @rayane-djouah requires payment through NewDot Manual Requests
• @SzymczakJ does not require payment (Contractor)

[melvin-bot]

BugZero Checklist: The PR adding this new feature has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@rayane-djouah] Please propose regression test steps to ensure the new feature will work correctly on production in further releases.
• [@anmurali] Link the GH issue for creating/updating the regression test once above steps have been agreed upon.

[SzymczakJ]

Update:
after some investigation, we have a promising solution for part of SearchPage performance problem, which implementation is still in progress. I will have to measure it thoroughly, so I'm sure it doesn't break anything else and I will post more detailed description when I'm sure it works.
@Kicu is also working on this issue, which is really helpful!

[luacmartins]

Thanks @SzymczakJ. That sounds promising.

[rayane-d]

Regarding BZ checklist #52317 (comment), I think no regression test is needed for this PR as it's a refactor

[melvin-bot]

📣 @rayane-d! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[rayane-d]

Requested in NewDot (for #52317 (comment))

[SzymczakJ]

Update:

1. I've tweaked the performance of my PR, so it doesn't add any additional overhead, when we compare it to main(according to the profiling that I've made, on average we're 20 ms faster on the navigation to Reports Page). Is it possible to give build from this PR to the testing team to make sure that on real devices the performance is not affected @luacmartins ?
2. Unfortunately I've noticed that on main, performance of navigating to Reports Page is much worse than it was last week(at least on simulators). I wasn't able to find the PR that slowed down the performance, but I wanted to let you know. I'll look for it root cause of it tomorrow.
3. I have a lot of ideas on how to speed up Search Page more and I would like to continue work on this, but it would be great to merge this PR first, since it doesn't intoduce performance issues anymore(of course after it being tested by test team).
   WDYT @luacmartins

[luacmartins]

Is it possible to give build from this PR to the testing team to make sure that on real devices the performance is not affected @luacmartins ?

I kicked off a build and will ask QA to test it once ready.

Unfortunately I've noticed that on main, performance of navigating to Reports Page is much worse than it was last week(at least on simulators). I wasn't able to find the PR that slowed down the performance, but I wanted to let you know. I'll look for it root cause of it tomorrow.

That's unfortunate, but not surprising given the number of changes we're making to Search. The only PR I'm aware of that was merged recently is this one

I have a lot of ideas on how to speed up Search Page more and I would like to continue work on this, but it would be great to merge this PR first, since it doesn't intoduce performance issues anymore(of course after it being tested by test team).
WDYT @luacmartins

I agree. I think we should make incremental changes here and tackle this with smaller PRs.

[garrettmknight]

@anmurali can you update the payment summary here?