refactor: remove ScreenComponent any cast from Bridge routes

[asalsys]

Description

Migrate BlockExplorersModal from prop-based route access to useRoute() hook with typed RouteProp generic, eliminating the type ScreenComponent = React.ComponentType<any> escape hatch from Bridge routes.

Part of the React Navigation v6 migration effort to remove no-explicit-any violations from route files.

Changes:

• BlockExplorersModal.tsx: Switch from (props: BlockExplorersModalProps) to useRoute() hook
• routes.tsx: Remove ScreenComponent type alias and as ScreenComponent cast
• BlockExplorersModal.test.tsx: Mock useRoute() instead of passing route as prop

Changelog

CHANGELOG entry: null

Related issues

Fixes:

Manual testing steps

N/A — pure refactoring with no user-facing behavior change. Existing unit tests cover the affected component.

Screenshots/Recordings

Before

N/A

After

N/A

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

Made with Cursor

---

Note

Low Risk
Low risk refactor limited to how route params are accessed and how tests set up navigation, with no expected behavioral changes beyond potential runtime issues if the route params are absent/mis-typed.

Overview
Refactors BlockExplorersModal to stop accepting a route prop and instead pull evmTxMeta/multiChainTx from React Navigation via useRoute() with a typed RouteProp.

Updates BlockExplorersModal.test.tsx to mock useRoute() and render the modal without passing route props, keeping existing assertions around explorer buttons and webview navigation.

^{Written by Cursor Bugbot for commit f2cc0ca. This will update automatically on new commits. Configure here.}

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[asalsys]

Closing: rebasing onto main since the navigation v6 branch was merged.

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: SmokeTrade
• Selected Performance tags: None (no tests recommended)
• Risk Level: low
• AI Confidence: 92%

click to see 🤖 AI reasoning details

E2E Test Selection:
The changes are a localized refactoring of the BlockExplorersModal component within the Bridge transaction details feature. The component was updated to use React Navigation's useRoute() hook internally instead of receiving route params as props. This is a standard React Navigation pattern change with no logic modifications.

Key observations:

1. No new functionality - pure refactoring of how route params are accessed
2. Only affects BlockExplorersModal in the Bridge/TransactionDetails directory
3. No shared components (TabBar, Browser, Modals, confirmations) are affected
4. No controllers, Engine, or state management changes
5. Test file updated to mock useRoute instead of passing props directly

SmokeTrade is selected because it covers bridge/swap flows including transaction details and history, which is where BlockExplorersModal is used. Per SmokeTrade's description, when selecting SmokeTrade for bridge flows, SmokeConfirmations should also be selected. However, since this is purely a UI refactoring of a modal that displays block explorer links (not the confirmation flow itself), and the risk is very low, SmokeConfirmations is included as a dependent tag per the tag description guidance.

Performance Test Selection:
The changes are a pure refactoring of how route params are accessed in a modal component (props vs useRoute hook). There are no performance implications - no new rendering logic, no data fetching changes, no list rendering, no state management changes. Performance tests are not warranted.

View GitHub Actions results

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

✅ E2E Fixture Validation — Schema is up to date
18 value mismatches detected (expected — fixture represents an existing user).
View details