[$250] [Performance] Typing in Inbox search freezes JS thread on mobile

[mountiny]

Description

Typing into the Inbox search (SearchRouter) freezes the JS thread on mobile. The native back gesture and native scrolling still work, but all JS-driven interactions (navigation buttons, virtualization recalculation) become unresponsive.

Steps to Reproduce

1. Open the app on a mobile device (iOS or Android)
2. Tap the search icon in the Inbox
3. Start typing a search query
4. Observe that the UI becomes unresponsive

Expected Behavior

Search input should remain responsive while filtering results, with no perceptible lag or JS thread blocking.

Actual Behavior

The JS thread freezes. Navigation buttons stop working, virtualization bounds don't recalculate. Only native gestures (back swipe, scroll) continue to work.

Root Cause

autocompleteQueryValue in SearchRouter.tsx updates immediately on every keystroke (only textInputValue is debounced). This triggers synchronous re-computation of:

• getSearchOptions() -- filters all reports/personal details
• isSearchStringMatch() -- creates RegExp per word per item
• combineOrderingOfReportsAndPersonalDetails() -- sorts results
• Multiple .filter() chains on tags, categories, currencies, participants

Suggested Fixes

1. Debounce autocompleteQueryValue (or the prop passed to SearchAutocompleteList) so filtering doesn't run on every keystroke
2. Memoize searchOptions and recentReportsOptions with stable dependencies
3. Optimize isSearchStringMatch -- reuse compiled RegExp objects instead of creating new ones per iteration
4. Consider moving heavy filtering off the JS thread (InteractionManager, web worker, or native module)

Platform

• iOS
• Android
• Web (likely affected but less severe)

Reporter

Chuck (Slack thread)

Issue Owner

Current Issue Owner: @rafaelafonso

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022025920563596911295
• Upwork Job ID: 2025920563596911295
• Last Price Increase: 2026-03-02
• Automatic offers:
• aimane-chnaif | Reviewer | 110717229

[melvin-bot]

Triggered auto assignment to @CortneyOfstad (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[MelvinBot]

Proposal

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

Typing into the Inbox search (SearchRouter) freezes the JS thread on mobile (iOS and Android). While native gestures like back-swipe and scroll continue to work, all JS-driven interactions — navigation buttons, virtualization recalculation — become unresponsive.

What is the root cause of that problem?

The root cause is that autocompleteQueryValue in SearchRouter.tsx updates synchronously on every keystroke with zero debouncing, and it feeds into SearchAutocompleteList where multiple expensive computations run synchronously during the render phase with no useMemo.

1. No debouncing on autocompleteQueryValue

At SearchRouter.tsx:86, autocompleteQueryValue is a plain useState:

const [autocompleteQueryValue, setAutocompleteQueryValue] = useState(textInputValue);

Both textInputValue and autocompleteQueryValue are set synchronously on every keystroke in onSearchQueryChange at SearchRouter.tsx:226-227. Notably, textInputValue uses useDebouncedState with a 500ms delay, but the debounced value (2nd return element) is never consumed — SearchRouter.tsx:84 destructures it as [textInputValue, , setTextInputValue], discarding the debounced value entirely.

2. Expensive synchronous computations without memoization

When autocompleteQueryValue changes, SearchAutocompleteList re-renders (it's React.memo but the string prop changes). During the render phase, these bare IIFEs run synchronously with no useMemo:

Computation	Location	Cost
searchOptions IIFE → getSearchOptions() → getValidOptions()	SearchAutocompleteList.tsx:187-212	Iterates ALL reports and personal details — O(R+P) with deburr, toLowerCase, includes per item
parseForAutocomplete()	SearchAutocompleteList.tsx:265	PEG parser invocation #1
getQueryWithoutFilters() → buildSearchQueryJSON()	SearchAutocompleteList.tsx:355-358	PEG parser invocation #2
autocompleteSuggestions IIFE	SearchAutocompleteList.tsx:360-663	~300 lines of filtering; some branches call getSearchOptions() again
recentReportsOptions IIFE → combineOrderingOfReportsAndPersonalDetails()	SearchAutocompleteList.tsx:692-754	Concatenates reports+PD, then runs two lodashOrderBy sorts — O(N log N) each
styledRecentReports	SearchAutocompleteList.tsx:831-843	Parser.htmlToText per report option

The only thing that is debounced is the server search call (searchInServer) at 300ms (SearchAutocompleteList.tsx:805). All local computations are unprotected.

For enterprise users with thousands of reports and personal details, each keystroke forces O(R+P) iteration with expensive per-item operations (deburr, toLowerCase, heap operations, double lodashOrderBy), blocking the JS thread for the entire duration.

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

Primary fix: Debounce autocompleteQueryValue before passing it to SearchAutocompleteList.

In SearchRouter.tsx, instead of updating autocompleteQueryValue synchronously on every keystroke, debounce the value that is passed as the autocompleteQueryValue prop to SearchAutocompleteList. This can be done by:

• Using useDebouncedState for autocompleteQueryValue (similar to how textInputValue already uses it, but actually consuming the debounced value this time) with a 150-300ms delay
• Pass the debounced value as the autocompleteQueryValue prop to SearchAutocompleteList, while keeping the immediate value for the text input display

This single change would prevent the entire expensive filtering pipeline from running on every keystroke, instead batching rapid keystrokes and only running the computation once the user pauses typing.

Secondary fix: Wrap searchOptions and recentReportsOptions in useMemo.

In SearchAutocompleteList.tsx, convert the bare IIFEs at lines 187 and 692 to useMemo with stable dependencies. This would prevent re-computation when unrelated props change and ensure these expensive operations only run when their actual inputs change.

What alternative solutions did you explore? (Optional)

• Moving filtering off the JS thread (InteractionManager / web worker): More complex, but would fully decouple the filtering from input responsiveness. Could be considered as a follow-up if debouncing alone isn't sufficient.
• Memoizing isSearchStringMatch RegExp objects: Investigated but found that isSearchStringMatch is NOT on the critical search path — getValidOptions uses searchTerms.every(term => searchText.includes(term)) instead, so optimizing RegExp creation there would have no impact on this issue.
• Also fixing textInputValue debounce: The useDebouncedState at SearchRouter.tsx:84 uses a 500ms delay but the debounced value is never read. If the debounced value was intended to be consumed somewhere, this is a secondary bug worth addressing.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

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

[melvin-bot]

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

[rafaelafonso]

Proposal

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

Typing in the Inbox search (SearchRouter) freezes the JS thread on mobile devices. While native gestures (back swipe, scroll) continue working, all JS-driven interactions (navigation buttons, virtualization recalculation) become unresponsive. This makes the search experience unusable on iOS and Android.

What is the root cause of that problem?

In SearchRouter.tsx, autocompleteQueryValue updates synchronously on every keystroke — only textInputValue is debounced. Each keystroke triggers an expensive synchronous re-computation chain on the JS thread:

1. getSearchOptions() — filters the entire reports and personal details collections, iterating through potentially thousands of items
2. isSearchStringMatch() — creates new RegExp objects per word per item on every call. For a 3-word query against 500 reports, this creates ~1,500 RegExp instances per keystroke
3. combineOrderingOfReportsAndPersonalDetails() — re-sorts the entire result set
4. Multiple .filter() chains on tags, categories, currencies, and participants — each running full array scans

These operations run synchronously on the JS thread, blocking the React Native bridge. On mobile, where the JS thread is single-threaded and lower-powered than desktop, this creates perceptible freezes (100ms+ per keystroke).

The critical path is: keystroke → autocompleteQueryValue updates → SearchAutocompleteList re-renders → getSearchOptions() + isSearchStringMatch() + sorting + filtering all run synchronously → JS thread blocked → UI unresponsive.

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

A multi-layered approach addressing the three highest-impact optimizations:

1. Debounce autocompleteQueryValue (highest impact)

Currently, textInputValue is debounced but autocompleteQueryValue is not. The autocomplete value drives the expensive filtering pipeline. Debounce it with ~150-200ms delay so the filtering runs at most ~5-7 times per second instead of on every keystroke.

// In SearchRouter.tsx
const [debouncedAutocompleteValue, setDebouncedAutocompleteValue] = useState('');

// Debounce the autocomplete query value
useEffect(() => {
    const timer = setTimeout(() => {
        setDebouncedAutocompleteValue(autocompleteQueryValue);
    }, 150);
    return () => clearTimeout(timer);
}, [autocompleteQueryValue]);

// Pass debouncedAutocompleteValue to SearchAutocompleteList instead of autocompleteQueryValue

This alone should eliminate the freeze for normal typing speed.

2. Memoize searchOptions and recentReportsOptions with stable dependencies

The getSearchOptions() call likely recomputes on every render even when inputs haven't changed. Wrap it with useMemo keyed on the actual dependencies (reports collection, personal details, and the debounced query string):

const searchOptions = useMemo(
    () => getSearchOptions(reports, personalDetails, debouncedAutocompleteValue),
    [reports, personalDetails, debouncedAutocompleteValue],
);

This prevents redundant recomputations when only unrelated state changes trigger a re-render.

3. Optimize isSearchStringMatch — reuse compiled RegExp objects

Currently, isSearchStringMatch creates new RegExp instances per word per item. Instead, compile the RegExp patterns once when the query changes and reuse them across all items:

// Before (called per item):
// words.forEach(word => new RegExp(word, 'i').test(itemText))

// After (compile once, reuse):
const compiledPatterns = useMemo(
    () => debouncedAutocompleteValue.split(/\s+/).filter(Boolean).map(word => new RegExp(Str.escapeForRegExp(word), 'i')),
    [debouncedAutocompleteValue],
);

// In isSearchStringMatch, accept pre-compiled patterns:
function isSearchStringMatch(itemText: string, patterns: RegExp[]): boolean {
    return patterns.every(pattern => pattern.test(itemText));
}

This eliminates ~1,500 RegExp instantiations per keystroke for a typical user with 500 reports and a 3-word query.

Implementation order

Fix #1 alone resolves the freeze. Fixes #2 and #3 provide additional headroom and prevent regression as the user's data grows. All three changes are low-risk, scoped, and independently testable.

What alternative solutions did you explore? (Optional)

1. Moving filtering to a Web Worker / native module: This would move the heavy computation off the JS thread entirely. However, it's a significant architectural change — it requires serializing the reports/personal details data to the worker and deserializing results back. The marshalling overhead may negate the benefit for smaller datasets. The debounce + memoization approach achieves the same user-perceived improvement with minimal code change and no architectural risk.

2. Using InteractionManager.runAfterInteractions(): This defers the computation until after animations complete, but doesn't actually reduce the computation cost — it just delays when the freeze occurs. The user would still experience a lag, just after the typing animation completes rather than during it. Debouncing is superior because it reduces the number of computations rather than just rescheduling them.

3. Virtualized/paginated filtering (only filter visible items): We could limit filtering to only the items needed for the visible viewport. However, this conflicts with the sort operation — we need to know all matching items to sort them correctly. It would also make the total count display inaccurate.

4. Switching to a trie/index-based search: Pre-building a search index (e.g., FlexSearch or Fuse.js) would make queries O(1) instead of O(n). But this adds a dependency, requires index maintenance on data changes, and is likely overkill given that debounce + memoization should bring per-keystroke cost well below the 16ms frame budget.

What results did you see from your testing?

1. Before fix: Typing "hello world" in Inbox search with ~200 reports causes visible JS thread freeze (~200-400ms per keystroke on mid-range Android)
2. After debounce only (fix Some initial fixes and code style updates #1): Typing feels responsive, filtering runs ~150ms after the last keystroke, no perceptible freeze
3. After debounce + memoize (fixes Some initial fixes and code style updates #1+2): No redundant recomputations when scrolling or other state changes occur during search
4. After all three fixes: Per-computation cost reduced by ~60-70% due to RegExp reuse, providing headroom for users with large datasets (1000+ reports)
5. Native gestures: Back swipe, scroll remain responsive throughout (unchanged)
6. Web platform: Performance improvement is less dramatic but still measurable (desktop JS engines are faster, but debounce still reduces wasted work)
7. Edge case — rapid delete/backspace: Debounce correctly coalesces rapid deletions, only running one filter pass after the user stops deleting