Stabilize `selectEarnTokens` and `selectBridgeHistoryForAccount` (allocating result functions on hot paths)

[MajorLift]

Performance audit finding · Severity: Medium · Effort: Small-Medium · Fix risk: Simple · Test safety net: Partial
Owner: Earn / Bridge CODEOWNERS
Files: app/selectors/earnController/earn/index.ts:122, app/selectors/bridgeStatusController/index.ts:14

What is this about?

A per-selector triage of the ten highest-subscription components (51 selector definitions read; ruled-out verdicts in this issue's edit history and #31493) left two selectors standing — both allocate heavily on hot, always-visible paths:

1. selectEarnTokens (app/selectors/earnController/earn/index.ts:122) — a createDeepEqualSelector that rebuilds a large nested structure (earn tokens × markets × chains via .reduce) on every recompute, and deep-compares its sizable inputs on every check. Consumed by both WalletActions and TradeWalletActions, which sit on the primary action surfaces.
2. selectBridgeHistoryForAccount (app/selectors/bridgeStatusController/index.ts:14) — a plain createSelector whose result function allocates a fresh object via .reduce per recompute, handing consumers a new reference whenever the upstream recomputes even if the history is unchanged.

Why it matters

Both costs scale with power-user data (token count, bridge history length) and run at the batched-flush cadence for as long as their screens are mounted. These are the confirmed offenders out of 80+ candidate reads — the rest were verified stable/cheap and ruled out.

Scenario

N/A — see Technical Details.

Design

N/A — internal performance change; no UI/design impact.

Technical Details

For selectEarnTokens: narrow the inputs to the slices that actually change, split the mega-aggregation into composed memoized layers so a price tick doesn't rebuild the world, and verify whether the deep-equal input compare is still needed once inputs are narrow (see the reference-stability contract test in the mms-performance skill's mm-selector-cascade). For selectBridgeHistoryForAccount: stabilize the output with a resultEqualityCheck or narrow inputs so recomputes track actual history changes.

Threat Modeling Framework

N/A — performance-only change; behavior is preserved, no new data flow / trust boundary / attack surface.

Acceptance Criteria

• Both selectors return the same reference across unrelated flushes with unchanged data (assert toBe across two equal-content states).
• Profiler on a power-user profile: WalletActions/TradeWalletActions and bridge history consumers stop re-rendering on unrelated dispatches.

References

• Files: app/selectors/earnController/earn/index.ts:122, app/selectors/bridgeStatusController/index.ts:14
• Related: Stop deep-comparing the full transaction history per check in selectLocalTransactions #31499 (selectLocalTransactions, split out as dedicated), Fix 3 per-row parameterized-selector cache misses in TokenListItem (fresh object-literal args) #31492 (per-row parameterized misses), Audit the 19 useSelector reads on Wallet home for expensive and unstable selectors #31493 (Wallet home ruled out)
• Source: mms-performance per-selector triage (perf: Augment mms-performance with frontend learnings from the Extension performance audit skills#49)
• Status: UNVALIDATED (static evidence; needs profiler confirmation)

[metamask-ci]

Triage Agent -- Classification

Severity: Sev3 (confidence: 0.88) ✅

This is a performance optimization issue, not a functional bug. The app works correctly but has suboptimal Redux subscription patterns causing unnecessary re-renders. No features are broken, no data is lost, and no crashes occur. It affects performance on state-heavy screens but users have implicit workarounds (the app still functions). This is a proactive audit finding rather than a user-reported defect.

Size: size-L (confidence: 0.82) ⚠️ Advisory

The issue identifies 8 components each needing refactoring from multiple individual useSelector calls to consolidated memoized view selectors. Each component requires: (1) analyzing which selectors are related, (2) creating new composite memoized selectors, (3) refactoring the component to use the new selectors, (4) testing for correctness and performance improvement. This is a cross-component change touching 8+ component files plus creating/modifying selector files, requiring careful analysis of selector dependencies and equality semantics (shallow vs deep equal).
Not auto-applied -- confidence below threshold.

Team: team-mobile-platform ✅

Matched via area fallback: area-performance (no CODEOWNERS match)

---

Root Cause Analysis

Affected component: Multiple high-subscription React components (8 components with 9-19 useSelector calls each)

Each independent useSelector call in a React component creates a separate subscription to the Redux store. When any part of the Redux state changes, every subscription runs its selector and equality check independently. With 9-19 selectors per component, this means 9-19 separate subscription callbacks fire on every state change. If any one of them returns a new reference (even if the data is semantically equal), the component re-renders. The root cause is an architectural pattern where components directly consume many individual atomic selectors instead of using consolidated memoized 'view selectors' that combine related state reads into a single subscription with appropriate equality semantics (e.g., using createDeepEqualSelector or shallowEqual). The existing selector infrastructure in app/selectors/ already provides createSelector and createDeepEqualSelector utilities, but components are not leveraging them to consolidate reads.

Evidence:

• Detection recipe: grep -rc 'useSelector(' app/components --include='*.tsx' | awk -F: '$2>=8' identifies 8 components
• The codebase already has memoized selector patterns (createSelector, createDeepEqualSelector) in networkController.ts and preferencesController.ts
• React-Redux documentation confirms each useSelector creates an independent subscription
• Performance profiling would show re-renders on unrelated state changes

Suggested Fix

Confidence: medium: likely but needs investigation - the specific 8 components need to be identified via the grep recipe, and each component's selector consolidation strategy depends on the actual selectors used

For each of the 8 identified components, create a dedicated memoized 'view selector' using createDeepEqualSelector that combines all related state reads into a single derived object. Replace the multiple useSelector calls with a single useSelector call consuming the view selector. This reduces N subscriptions to 1 per component and leverages reselect memoization to prevent re-computation when inputs haven't changed.

Target files: app/selectors/networkController.ts, app/selectors/preferencesController.ts

Approach:

1. Run the detection recipe to identify all 8 components: grep -rc 'useSelector(' app/components --include='*.tsx' | awk -F: '$2>=8'
2. For each component, categorize its useSelector calls by domain (network, preferences, accounts, etc.)
3. For each component, create a new view selector in the appropriate selector file (or a new component-specific selector file) using createDeepEqualSelector that combines related reads into a single object: e.g., export const selectMyComponentView = createDeepEqualSelector(selectChainId, selectTicker, selectProviderType, (chainId, ticker, type) => ({ chainId, ticker, type }))
4. Replace the multiple useSelector calls in the component with a single const viewData = useSelector(selectMyComponentView)
5. Destructure the view data as needed in the component
6. For selectors that return primitives (strings, booleans, numbers), grouping into a single object with createDeepEqualSelector is sufficient since deep equality on primitives is cheap
7. For selectors returning objects/arrays, ensure the view selector uses createDeepEqualSelector to avoid false positives from reference inequality
8. Profile before and after with React DevTools Profiler to verify reduced re-renders
9. Consider using shallowEqual as the equality function for useSelector as an intermediate step if full refactoring is too large

---

Confidence threshold: 0.85. Labels marked ✅ were auto-applied. Labels marked ⚠️ are advisory only (below threshold).
To re-triage, remove the ta-bot-triage label and re-apply ta-needs-triage.
⚠️ Some dimensions could not be confidently classified. An engineer should review this issue.