[Due for payment 2025-02-27] [$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
• Automatic offers:
• ikevin127 | Contributor | 106182826

Issue Owner

Current Issue Owner: @lschurr

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

📣 @ikevin127 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job
Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

[shawnborton]

Let's also make sure we close the router on desktop when the user presses the escape key, cc @luacmartins to add that to your follow up list.

[garrettmknight]

@anmurali bump on the payment summary, plz.

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

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

• Add search input to mobile search page(with fixed performance) #56326

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

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

• @ikevin127 requires payment automatic offer (Contributor)
• @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:

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

[ikevin127]

• [@ikevin127] Please propose regression test steps to ensure the new feature will work correctly on production in further releases.

Regarding ☝ BZ Checklist, I think no regression test is needed for #56326 as it's a UI refactor.

[melvin-bot]

Issue is ready for payment but no BZ is assigned. @lschurr you are the lucky winner! Please verify the payment summary looks correct and complete the checklist. Thanks!

[rayane-d]

Please assign me for #52317 (comment)

[lschurr]

Looks like @anmurali is already assigned from BZ, so I'm going to remove my assignment.

[garrettmknight]

@lschurr Anu's no longer on BZ.

[lschurr]

Payment summary:

• Contributor on the first PR: @Kicu (no payment needed)
• Reviewer: $125 @rayane-d (to be paid in NewDot)
• Contributor on the second PR: @SzymczakJ (no payment needed)
• Reviewer: $250 @ikevin127 (paid in Upwork)

[lschurr]

We discussed internally and realized there was an error in payment on this one.

The correct payment summary is as follows:

• Contributor: @Kicu (no payment needed)
• Reviewer: $125 @rayane-d (to be paid in NewDot)
• Contributor: @SzymczakJ (no payment needed)
• Reviewer: $125 @ikevin127

The explanation is here:

• Simplify single line TextInput styling to allow for different heights reviewed by @rayane-d, which caused this regression
• Redesign search to always show search input(mobile + desktop) reviewed by @ikevin127, which caused a few regressions, e.g. this one

Due to the error, I've requested a refund of $125 in Upwork from @ikevin127

[ikevin127]

@lschurr I think there's a misunderstanding here due to multiple PRs and different contributors being paid in the same issue.

Here's a summary of my work for this issue:

1. Reviewed first PR:
   Redesign search to always show search input(mobile + desktop) as C+, which had a few regressions and was fully reverted - meaning no payment for me on this one.
2. Reviewed the second PR: Add search input to mobile search page(with fixed performance) that was a rework of the first one, which did not cause any regressions as far as I know - we merged with 2 UI issues which CME agreed on having follow-up PRs for.

Since we started from scratch on the second PR rework, and I performed another complete review (including past regressions testing) - it was correct to get the full $250 payment.

cc @luacmartins for confirmation

If confirmed otherwise, I noted down the refund request and will send it as soon as I get some available balance.

[luacmartins]

Reviewed first PR:
#55078 as C+, which had a few regressions and was fully #56053 - meaning no payment for me on this one.
Reviewed the second PR: #56326 that was a rework of the first one, which did not cause any regressions as far as I know - we merged with 2 UI issues which CME agreed on having follow-up PRs for.

@ikevin127 AFAIK this counts as a regression whether we fully revert the PR or work on a new fix for it.

[ikevin127]

@lschurr Refund issued, please let me know if anything else is needed from my side.