[$250] New Feature: Reduce desktop LHN row height to improve navigation visibility

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.34-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @shawnborton
Slack conversation (hyperlinked to channel name): #Product

Action Performed:

Description:

As more features are added to NewDot, the Left Hand Navigation (LHN) sections for Reports, Workspaces, and Account are becoming increasingly long. This causes many navigation items to fall out of view, requiring additional scrolling.
To improve visibility and allow more items to fit on screen, the row height on desktop should be reduced from 52px to 44px. This change will make the navigation more compact while maintaining usability.
For mobile, the current row height should remain unchanged to preserve comfortable tap targets.

Steps to Reproduce:

1. Open New Expensify on desktop
2. Navigate to the LHN sections such as Reports, Workspaces, or Account
3. Observe that the list can become long and items fall out of view quickly

Expected Result:

Desktop LHN rows use a 44px height, allowing more items to appear on screen.
Mobile LHN rows remain at 52px to maintain larger tap targets.

Actual Result:

LHN rows currently use 52px height on desktop, limiting the number of visible items and increasing scrolling.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @eVoloshchak

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022031165788903552118
• Upwork Job ID: 2031165788903552118
• Last Price Increase: 2026-03-10

[melvin-bot]

Triggered auto assignment to @CortneyOfstad (NewFeature), see https://stackoverflowteams.com/c/expensify/questions/14418#:~:text=BugZero%20process%20steps%20for%20feature%20requests for more details. Please add this Feature request to a GH project, as outlined in the SO. Remember to draft any necessary HelpDot updates by following the instructions here.

[melvin-bot]

Triggered auto assignment to Design team member for new feature review - @dannymcclain (NewFeature)

[dannymcclain]

Muahaha more GitCoin for meeeeeeee!

[dannymcclain]

(Just kidding @shawnborton)

[TaduJR]

Proposal

Please re-state the problem that we are trying to solve in this issue.

The settings navigation sidebar menus (Account, Workspaces, Reports) use a fixed 52px row height on all platforms. On desktop, this wastes vertical space and forces users to scroll to reach items that could otherwise fit on screen.

What is the root cause of that problem?

All sidebar navigation menu items share the sectionMenuItem style, which has a hardcoded height: 52 with no platform differentiation:

App/src/styles/index.ts

Lines 2827 to 2833 in 83a7b8e

	sectionMenuItem: {
	borderRadius: 8,
	paddingHorizontal: 16,
	paddingVertical: 8,
	height: 52,
	alignItems: 'center',
	},

This style is applied as wrapperStyle to MenuItem components in all affected pages:

• Account settings — InitialSettingsPage.tsx passes wrapperStyle={styles.sectionMenuItem}:

App/src/pages/settings/InitialSettingsPage.tsx

Line 457 in 83a7b8e

wrapperStyle={styles.sectionMenuItem}

• Workspace settings — WorkspaceInitialPage.tsx passes the same style to HighlightableMenuItem:

App/src/pages/workspace/WorkspaceInitialPage.tsx

Line 477 in 83a7b8e

wrapperStyle={styles.sectionMenuItem}

• Search/Reports sidebar — SearchTypeMenuItem.tsx applies it directly in its style array:

App/src/pages/Search/SearchTypeMenuItem.tsx

Line 46 in 83a7b8e

styles.sectionMenuItem,

• Saved searches — SavedSearchList.tsx:

App/src/pages/Search/SavedSearchList.tsx

Line 116 in 83a7b8e

wrapperStyle={styles.sectionMenuItem}

HighlightableMenuItem also reads styles.sectionMenuItem.height directly for its animation dimensions:

App/src/components/HighlightableMenuItem.tsx

Lines 22 to 23 in 83a7b8e

	height: flattenedWrapperStyles?.height ? Number(flattenedWrapperStyles.height) : styles.sectionMenuItem.height,
	borderRadius: flattenedWrapperStyles?.borderRadius ? Number(flattenedWrapperStyles.borderRadius) : styles.sectionMenuItem.borderRadius,

Since sectionMenuItem is a static style object with no responsive branching, desktop inherits the 52px height designed for mobile touch targets.

What changes do you think we should make in order to solve the problem?

1. Convert sectionMenuItem to a function-based style in styles/index.ts, following the existing pattern used by topLevelNavigationTabBar, OnboardingNavigatorInnerView, and others that accept shouldUseNarrowLayout:

App/src/styles/index.ts

Lines 2827 to 2833 in 83a7b8e

	sectionMenuItem: {
	borderRadius: 8,
	paddingHorizontal: 16,
	paddingVertical: 8,
	height: 52,
	alignItems: 'center',
	},

- sectionMenuItem: {
-     borderRadius: 8,
-     paddingHorizontal: 16,
-     paddingVertical: 8,
-     height: 52,
-     alignItems: 'center',
- },
+ sectionMenuItem: (shouldUseNarrowLayout: boolean) => ({
+     borderRadius: 8,
+     paddingHorizontal: 16,
+     paddingVertical: shouldUseNarrowLayout ? 8 : 4,
+     height: shouldUseNarrowLayout ? 52 : 44,
+     alignItems: 'center' as const,
+ }),

2. Update consuming components to call styles.sectionMenuItem(shouldUseNarrowLayout) instead of referencing the static object. All these pages already have shouldUseNarrowLayout from useResponsiveLayout():

• InitialSettingsPage.tsx (already has it at line 137):

App/src/pages/settings/InitialSettingsPage.tsx

Line 457 in 83a7b8e

wrapperStyle={styles.sectionMenuItem}

- wrapperStyle={styles.sectionMenuItem}
+ wrapperStyle={styles.sectionMenuItem(shouldUseNarrowLayout)}

• WorkspaceInitialPage.tsx (already has it at line 92):

App/src/pages/workspace/WorkspaceInitialPage.tsx

Line 477 in 83a7b8e

wrapperStyle={styles.sectionMenuItem}

- wrapperStyle={styles.sectionMenuItem}
+ wrapperStyle={styles.sectionMenuItem(shouldUseNarrowLayout)}

• SearchTypeMenuItem.tsx — add useResponsiveLayout() and pass the flag:

App/src/pages/Search/SearchTypeMenuItem.tsx

Line 46 in 83a7b8e

styles.sectionMenuItem,

+ const {shouldUseNarrowLayout} = useResponsiveLayout();
  ...
- styles.sectionMenuItem,
+ styles.sectionMenuItem(shouldUseNarrowLayout),

• SavedSearchList.tsx — same pattern:

App/src/pages/Search/SavedSearchList.tsx

Line 116 in 83a7b8e

wrapperStyle={styles.sectionMenuItem}

- wrapperStyle={styles.sectionMenuItem}
+ wrapperStyle={styles.sectionMenuItem(shouldUseNarrowLayout)}

• DomainInitialPage.tsx:

App/src/pages/domain/DomainInitialPage.tsx

Line 155 in 83a7b8e

wrapperStyle={styles.sectionMenuItem}

- wrapperStyle={styles.sectionMenuItem}
+ wrapperStyle={styles.sectionMenuItem(shouldUseNarrowLayout)}

3. Update HighlightableMenuItem.tsx fallback to call the function:

App/src/components/HighlightableMenuItem.tsx

Lines 22 to 23 in 83a7b8e

	height: flattenedWrapperStyles?.height ? Number(flattenedWrapperStyles.height) : styles.sectionMenuItem.height,
	borderRadius: flattenedWrapperStyles?.borderRadius ? Number(flattenedWrapperStyles.borderRadius) : styles.sectionMenuItem.borderRadius,

Since HighlightableMenuItem already receives wrapperStyle from its parent (which will now contain the correct resolved height), the fallback just needs to call the function with a default:

- height: flattenedWrapperStyles?.height ? Number(flattenedWrapperStyles.height) : styles.sectionMenuItem.height,
- borderRadius: flattenedWrapperStyles?.borderRadius ? Number(flattenedWrapperStyles.borderRadius) : styles.sectionMenuItem.borderRadius,
+ height: flattenedWrapperStyles?.height ? Number(flattenedWrapperStyles.height) : styles.sectionMenuItem(true).height,
+ borderRadius: flattenedWrapperStyles?.borderRadius ? Number(flattenedWrapperStyles.borderRadius) : styles.sectionMenuItem(true).borderRadius,

In practice the fallback is never hit since all callers pass wrapperStyle, so the true default (mobile size) is a safe conservative fallback.