[HOLD App #53126] 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:

https://github.com/user-attachments/assets/8661de75-afb9-40fb-99f1-f17ae490f615

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:

https://github.com/user-attachments/assets/40070501-1cec-4b7e-afef-fc242a389859

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

[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: https://github.com/Expensify/App/pull/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[bot]]

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

[Kicu]

Waiting on merge of: https://github.com/Expensify/App/pull/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: https://github.com/Expensify/App/issues/53126

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

[trjExpensify]

Done!

[melvin-bot[bot]]

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

[shawnborton]

Not overdue, we're working on it.