[$250] Isolate Expensify's global modals

[mountiny]

Proposal here

Background

The root Expensify component serves two roles: it orchestrates application lifecycle (Onyx migration, splash screen, navigation, authentication) and renders six global UI elements that stay mounted for the entire session — GrowlNotification, DelegateNoAccessModalProvider, EmojiPicker, UpdateAppModal, ProactiveAppReviewModalManager, and ScreenShareRequestModal. These modals are stateless relative to the parent; they manage visibility internally or via imperative refs.

Expensify subscribes to five Onyx keys, several of which (LAST_VISITED_PATH, LAST_ROUTE) update during routine navigation. Because eslint-disable directives in the component cause React Compiler to bail out, every re-render produces fresh JSX references for all children — forcing React to walk each child fiber even when nothing changed. Profiling on web and iOS confirms the six modal fibers appear in 97–99% of commits, each costing ~0.5–2ms of reconciliation self-time despite their render functions being ~0.1ms no-ops.

Problem

When Expensify re-renders due to routine navigation-driven Onyx updates, if React reconciles the six co-located global modal subtrees that have no dependency on the changed state, then ~3–8ms of JS thread time per commit is wasted on fiber traversal that produces zero visual changes.

Solution

Move the six global modals out of Expensify and into a dedicated React.memo-wrapped child component. The new component owns only the state it needs (a single rarely-changing prop and one Onyx subscription), so React.memo's shallow comparison bails out on virtually every parent re-render — letting React skip the entire modal subtree instead of walking it. This eliminates ~3–8ms of wasted reconciliation per commit without changing any modal behaviour or visual output.

Measured improvements

• ~ 20% for web
• ~7 % for native

Scenario & measurements in the 🧵
Draft PR here

Issue Owner

Current Issue Owner: @jmusial

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022034235732288543075
• Upwork Job ID: 2034235732288543075
• Last Price Increase: 2026-03-18

[MelvinBot]

Proposal

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

The root Expensify component (src/Expensify.tsx) re-renders on every navigation event because it subscribes to ONYXKEYS.LAST_VISITED_PATH, which is updated in NavigationRoot.tsx on every route change. Because React Compiler bails out on Expensify.tsx (due to eslint-disable-next-line react-hooks/exhaustive-deps on two useEffect hooks), every re-render produces fresh JSX references for all inline children — including six global modal components that have zero dependency on the changed state. This wastes ~3–8 ms of JS thread time per commit on fiber traversal that produces no visual changes.

What is the root cause of that problem?

Two factors combine to cause the waste:

1. Frequent re-renders from navigation Onyx keys — LAST_VISITED_PATH updates on every navigation event (src/libs/Navigation/NavigationRoot.tsx:62), triggering useOnyx(ONYXKEYS.LAST_VISITED_PATH) in Expensify.tsx and re-rendering the entire component.

2. React Compiler bailout — Expensify.tsx has two useEffect hooks with intentionally incomplete dependency arrays (lines ~261 and ~271 with eslint-disable-next-line react-hooks/exhaustive-deps). The React Compiler's default suppression rules (react-hooks/exhaustive-deps and react-hooks/rules-of-hooks) cause it to bail out on the entire Expensify function. Without compiler optimization, fresh JSX element references are created for every child on every render, forcing React to walk each modal fiber (~0.5–2 ms each) even though their render functions are no-ops.

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

Extract the six global modals (GrowlNotification, DelegateNoAccessModalProvider/PopoverReportActionContextMenu, EmojiPicker, UpdateAppModal, ProactiveAppReviewModalManager, ScreenShareRequestModal) into a new ExpensifyGlobalModals child component.

This works because:

• The new component creates a React component boundary that the React Compiler CAN optimize (it has no exhaustive-deps suppressions — only react-hooks/refs which is not in the compiler's bailout list).
• The only prop passed is updateRequired (a boolean that is undefined for virtually all sessions and only set to true once if a forced update is needed) — extremely stable for compiler caching.
• The updateAvailable Onyx subscription is moved into the child, so changes to it no longer trigger re-renders of the entire Expensify component.
• Module-level createRef refs (growlRef, emojiPickerRef, contextMenuRef) are stable singleton references that won't invalidate the compiler's cache.

When Expensify re-renders due to navigation, the compiled ExpensifyGlobalModals checks its cache, finds dependencies unchanged, and returns the cached JSX tree — letting React skip the entire modal subtree.

Note: The issue description mentions React.memo wrapping, but the draft PR relies on React Compiler auto-memoization instead, which achieves the same effect (and is the preferred approach in this codebase where the compiler is globally enabled).

What alternative solutions did you explore? (Optional)

• Adding React.memo explicitly: Would add a prop-level bailout before even calling the function. Provides a marginal additional optimization over the compiler-only approach, but is redundant given the React Compiler is enabled project-wide.
• Fixing the eslint-disable directives in Expensify.tsx: Would allow the compiler to optimize the root component itself, but the intentional dependency omissions serve a purpose (mount-only effects) and changing them could introduce behavioral regressions.
• Using useMemo for the modal JSX block inline: Would cache the JSX within Expensify.tsx itself, but component extraction is cleaner and also isolates the updateAvailable subscription.

Draft PR: #85449

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @ShridharGoel (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022034235732288543075