Add top-level navigation suggestions to Search Router

[nabi-ebrahimi]

Explanation of Change

This PR introduces the core Search Router navigation infrastructure and adds navigation suggestions for the five top-level destinations:

• Home
• Inbox
• Spend
• Workspaces
• Account

Navigation suggestions are rendered inside the existing SelectionListWithSections flow, preserving keyboard focus, Enter selection, and existing Search Router row ordering.

The suggestions:

• Support plain queries and case-insensitive go / go to prefixes.
• Require at least three destination characters, except for the intentional bare go and go to queries.
• Use accent-insensitive matching.
• Sort results alphabetically and limit them to eight.
• Display localized Go to {destination} labels.
• Close Search Router before executing navigation to avoid modal and route-transition conflicts.
• Preserve the existing last Spend search.
• Open the Workspaces list instead of restoring a previously visited workspace subpage.

This is the first focused part of #92752. It intentionally does not add Spend submenu, Account settings, Workspace settings, Domain, or Create/FAB suggestions.

Fixed Issues

$ #92752
PROPOSAL: #92752 (comment)

Tests

1. Plain navigation query

   • Open Search Router.
   • Search separately for home, inbox, spend, workspaces, and account.
   • Select each navigation row.
   • Expected: The matching Go to ... row appears and opens the correct destination.

2. Navigation intent prefixes

   • Search for go inbox and go to inbox.
   • Repeat with mixed capitalization, such as GO TO INBOX.
   • Expected: All queries show Go to Inbox and selecting it opens Inbox.

3. Minimum query length

   • Search separately for a, ab, and acc.
   • Expected: No navigation row appears for a or ab. acc shows Go to Account.

4. Bare navigation intent and ordering

   • Search for go, then go to.
   • Expected: Both queries show the five top-level destinations, alphabetically ordered and limited to the navigation results supported by this PR.

5. Keyboard selection

   • Search for inbox.
   • Focus Go to Inbox using Arrow Up/Down and press Enter.
   • Expected: Search Router closes and Inbox opens once.

6. Spend navigation

   • Open Spend and enter a recognizable search.
   • Navigate elsewhere.
   • Use Search Router to select Go to Spend.
   • Expected: Spend opens using its existing last-search behavior.

7. Workspaces root navigation

   • Open a workspace subpage such as Members.
   • Navigate to Home.
   • Use Search Router to select Go to Workspaces.
   • Expected: The Workspaces list opens instead of the previously visited workspace subpage.

8. Modal close before navigation

   • Select any Go to ... row.
   • Reopen Search Router after arriving at the destination.
   • Expected: Search Router closes before navigation, the destination opens once, and no stale modal or delayed navigation remains.

9. Localized navigation text

   • Switch to one non-English language.
   • Search for a localized top-level destination.
   • Expected: The localized Go to {destination} row appears and navigates correctly.

• Verify that no errors appear in the JS console

Offline tests

1. Log in and allow the app to finish loading.
2. Disconnect from the network.
3. Open Search Router.
4. Search for Home, Inbox, Spend, Workspaces, and Account.
5. Select each destination.
6. Reconnect to the network.

Expected: Cached navigation suggestions remain available, local navigation does not crash, and the app recovers normally after reconnecting.

QA Steps

Same as Tests.

// TODO: These must be filled out, or the issue title must include "[No QA]."

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Screen.Recording.2026-07-15.at.8.07.14.AM.mov

Screen.Recording.2026-07-15.at.8.09.16.AM.mov

Android: mWeb Chrome

Screen_Recording_20260715_080309_Chrome.mp4

Screen_Recording_20260715_080352_Chrome.mp4

iOS: Native

Screen.Recording.2026-07-15.at.8.43.18.AM.mov

Screen.Recording.2026-07-15.at.8.44.00.AM.mov

iOS: mWeb Safari

Screen.Recording.2026-07-15.at.8.59.51.AM.mov

Screen.Recording.2026-07-15.at.9.01.40.AM.mov

MacOS: Chrome / Safari

01

Screen.Recording.2026-07-14.at.3.27.10.PM.mov

02

Screen.Recording.2026-07-14.at.3.31.18.PM.mov

03

Screen.Recording.2026-07-14.at.3.34.42.PM.mov

04

Screen.Recording.2026-07-15.at.7.30.59.AM.mov

05

Screen.Recording.2026-07-15.at.7.31.51.AM.mov

06

Screen.Recording.2026-07-15.at.7.34.17.AM.mov

07

Screen.Recording.2026-07-15.at.7.35.48.AM.mov

08

Screen.Recording.2026-07-15.at.7.44.36.AM.mov

09

Screen.Recording.2026-07-15.at.7.50.32.AM.mov

[melvin-bot]

Hey, I noticed you changed src/languages/en.ts in a PR from a fork. For security reasons, translations are not generated automatically for PRs from forks.

If you want to automatically generate translations for other locales, an Expensify employee will have to:

1. Look at the code and make sure there are no malicious changes.
2. Run the Generate static translations GitHub workflow. If you have write access and the K2 extension, you can simply click: [this button]

Alternatively, if you are an external contributor, you can run the translation script locally with your own OpenAI API key. To learn more, try running:

npx ts-node ./scripts/generateTranslations.ts --help

Typically, you'd want to translate only what you changed by running npx ts-node ./scripts/generateTranslations.ts --compare-ref main

[nabi-ebrahimi]

The unit test failures are also not related to our PR changes, thanks.

[melvin-bot]

@marufsharifi Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[marufsharifi]

@nabi-ebrahimi, could you please merge the main?

[marufsharifi]

Reviewer Checklist

• I have verified the author checklist is complete (all boxes are checked off).
• I verified the correct issue is linked in the ### Fixed Issues section above
• I verified testing steps are clear and they cover the changes made in this PR
  • I verified the steps for local testing are in the Tests section
  • I verified the steps for Staging and/or Production testing are in the QA steps section
  • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
• I checked that screenshots or videos are included for tests on all platforms
• I included screenshots or videos for tests on all platforms
• I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
• I verified tests pass on all platforms & I tested again on:
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: HybridApp
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
• I verified proper code patterns were followed (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I verified that this PR follows the guidelines as stated in the Review Guidelines
• I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
• I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

Screen.Recording.2026-07-15.at.7.49.20.PM.mov

Android: mWeb Chrome

Screen_Recording_20260715_193837_Chrome.mp4

iOS: HybridApp

Screen.Recording.2026-07-15.at.8.12.20.PM.mov

iOS: mWeb Safari

Screen.Recording.2026-07-15.at.8.29.01.PM.mov

MacOS: Chrome / Safari

Screen.Recording.2026-07-15.at.7.08.17.PM.mov

Screen.Recording.2026-07-15.at.7.09.56.PM.mov

Screen.Recording.2026-07-15.at.7.11.31.PM.mov

Screen.Recording.2026-07-15.at.7.12.05.PM.mov

Screen.Recording.2026-07-15.at.7.13.05.PM.mov

Screen.Recording.2026-07-15.at.7.14.27.PM.mov

Screen.Recording.2026-07-15.at.7.15.34.PM.mov

Screen.Recording.2026-07-15.at.7.18.09.PM.mov

Screen.Recording.2026-07-15.at.7.21.13.PM.mov

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 38eb02cfcb

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[marufsharifi]

@nabi-ebrahimi, could you please check the above comments? thanks.

[codecov]

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
src/CONST/index.ts	94.81% <ø> (ø)
...ts/Navigation/NavigationTabBar/SearchTabButton.tsx	70.83% <ø> (+22.26%)	⬆️
...s/Navigation/NavigationTabBar/getSearchTabRoute.ts	100.00% <100.00%> (ø)
...Search/SearchList/ListItem/SearchQueryListItem.tsx	95.45% <ø> (ø)
...onents/Search/SearchRouter/SearchRouterContext.tsx	81.81% <100.00%> (ø)
...rc/components/Search/SearchRouter/SearchRouter.tsx	58.44% <83.33%> (+1.10%)	⬆️
...ponents/Search/SearchRouter/toggleSearch/index.tsx	0.00% <0.00%> (ø)
.../Search/SearchRouter/toggleSearch/index.native.tsx	0.00% <0.00%> (ø)
...ponents/Search/SearchRouter/SearchRouterHelpers.ts	90.90% <90.90%> (ø)
...ts/Search/SearchRouter/SearchRouterModal/index.tsx	0.00% <0.00%> (ø)
... and 1 more
... and 13 files with indirect coverage changes

[marufsharifi]

@MelvinBot review

[nabi-ebrahimi]

@marufsharifi, it is done from my side, all yours.

[MelvinBot]

Review

Solid, well-scoped first step for #92752. The deferred-navigation approach (running action in onModalHide / dismissModal({afterTransition}) after the router closes) is clean and correctly avoids the modal/route-transition conflict. Tests are thorough and all CI is green. A few things worth addressing before merge:

🟡 Fuzzy matching also matches the Go to … label text

SearchRouterHelpers.ts:81 matches against item.text (the localized Go to {destination}) in addition to matchTerms. Since the whole point of stripNavigationIntentPrefix is to remove the go/go to intent tokens, folding them back in via the label produces spurious matches — e.g. to h matches Go to Home, o inbox matches Go to Inbox. Recommend matching only against matchTerms (the destination names), not item.text, so results reflect the destination rather than the label boilerplate.

🟡 Go to Spend doesn't fully mirror the Spend tab

useNavigationSuggestions.tsx:88-90 restores the last Spend search only from the Onyx queryJSON. The actual Spend tab (SearchTabButton.tsx:57-77) first restores the real last route from navigation state via getLastRoute (preserving its extra params) and only falls back to Onyx. So Go to Spend can land on a slightly different view than clicking the Spend tab. Fine as a first pass, but flagging it against the PR's "preserve the existing last Spend search" claim.

🟢 Unused rightElement wiring

SearchQueryListItem.tsx:68 adds rightHandSideComponent={item.rightElement}, but no navigation suggestion sets rightElement, and it isn't mentioned in the PR description. This changes behavior for every SearchQueryListItem consumer (autocomplete/saved/recent rows would now render a right element if one were ever present). If it isn't needed for this PR, drop it; if it's groundwork for a later part, a comment would help.

Notes / non-blocking

• Short-query exact-match path (for CJK destinations like 支出) correctly uses only matchTerms, which is consistent with the suggestion above for the fuzzy path.
• useNavigationSuggestions rebuilds items and suggestions on each render, but React Compiler compliance passes so this is auto-memoized — no action needed.
• Language entries look good: TS delimiters stay straight ASCII and the Go to {destination} content is localized per locale.

I didn't run the app; the above is from code + test review against the current diff.

[marufsharifi]

@Expensify/design, could you please share your feedback here? thanks.

[marufsharifi]

@nabi-ebrahimi, could you please check the above comment? thanks.

[nabi-ebrahimi]

@marufsharifi Thanks for the review, addressed above comments can you please do another review.

[marufsharifi]

Code looks good and tested, but there are a few minor feedback. thanks.

[trjExpensify]

Thanks for that. @nabi-ebrahimi over to you...

[nabi-ebrahimi]

@marufsharifi thanks for the detailed review. I addressed the valid comments, added the relevant regression coverage, and replied to the non-actionable or informational threads with context. Could you please take another look when you have a chance?

[marufsharifi]

@codex review

[nabi-ebrahimi]

@marufsharifi thanks for the thorough review. I addressed all valid and actionable comments, verified the related tests and checks, and replied with context where no change was required. Could you please take another look when convenient?

[marufsharifi]

LGTM

[carlosmiceli]

@nabi-ebrahimi @marufsharifi great, will review momentarily. to confirm, this PR would be the first item in this list, correct? -> #92752 (comment)

[carlosmiceli]

@trjExpensify @heyjennahay ready for product review

[trjExpensify]

First PR of several to roll out navigational search 👍

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

[OSBotify]

🚀 Deployed to staging by https://github.com/carlosmiceli in version: 9.4.42-0 🚀

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

[MelvinBot]

Help site review — changes required ✅

Yes, this PR introduces a user-facing behavior that isn't documented on the help site: members can now jump to a top-level destination by typing its name (or a go / go to prefix) in Search and selecting the Go to [destination] result.

The existing Navigating New Expensify article already documents the same five destinations (Home, Inbox, Spend, Workspaces, Account) via the navigation tabs but only covers reaching them through the tabs — so it's the right home for this new capability.

Draft help site PR: #96714

What I changed and why

Updated docs/articles/new-expensify/getting-started/Navigating-New-Expensify.md:

• Added a task-based section How to jump to a destination using Search (open Search, type a destination name or go / go to, select the Go to [destination] result), noting the three-character minimum and the alphabetical list shown for a bare go / go to.
• Added an FAQ entry: Can I use Search to move between sections of Expensify?
• Updated the description, keywords, and internalScope metadata.

Scope: This PR intentionally ships only the five top-level destinations and excludes Spend submenu, Account settings, Workspace settings, Domain, and Create/FAB suggestions — so the doc update is scoped to match the shipped behavior and can be expanded as later parts of #92752 land.

Written per docs/HELP_AUTHORING_GUIDELINES.md, docs/HELPSITE_NAMING_CONVENTIONS.md, and docs/TEMPLATE.md.

⚠️ I couldn't auto-assign the draft PR to you — GitHub reports nabi-ebrahimi as not assignable on this repo via my token. Please self-assign #96714. The HelpDot label has been applied.

@nabi-ebrahimi, please review the linked help site PR and confirm it reflects the current behavior. Then mark the linked help site PR Ready for review

[OSBotify]

🚀 Deployed to production by https://github.com/yuwenmemon in version: 9.4.42-1 🚀

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

Bundle Size Analysis (Sentry):

• Android