chore(send): type Send navigator with feature param list (Phase 3)

[weitingsun]

Description

Phase 3 of the incremental React Navigation typing migration — Send feature.

The redesigned Send stack (Routes.SEND.DEFAULT) was loosely typed as NestedNavigationParams | SendParams, so nested navigate('Send', { screen, params }) calls could not be checked against real screen param shapes. Call sites already navigate with { screen, params } (Amount / Asset / Recipient / RedesignedConfirmations); this PR aligns the types with that runtime pattern.

This is types-only — no intentional runtime navigation behavior change.

What changed

Feature param lists (app/components/Views/confirmations/components/send/types/navigation.ts)

• SendStackParamList — Amount, Asset, Recipient, RedesignedConfirmations
• SendScreenRouteParams — shared screen params (asset, location, predefinedRecipient, legacy txMeta)
• SendNavigationParamList — feature union + nested Send entry
• RedesignedConfirmations typed as ConfirmationParams | undefined

Navigator (app/components/Views/confirmations/components/send/send.tsx)

• createNativeStackNavigator<SendStackParamList>()

Root stack (app/core/NavigationService/types.ts)

• Send → NavigatorScreenParams<SendStackParamList> (replaces NestedNavigationParams | SendParams)
• Leaf Amount / Recipient / Asset routes reference SendStackParamList (Asset still unions with AssetViewParams for the token-details route of the same name)

Changelog

CHANGELOG entry:null

Related issues

Fixes:https://consensyssoftware.atlassian.net/browse/MCWP-674

Manual testing steps

N/A

Screenshots/Recordings

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.

Performance checks (if applicable)

• I've tested on Android
  • Ideally on a mid-range device; emulator is acceptable
• I've tested with a power user scenario
  • Use these power-user SRPs to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

For performance guidelines and tooling, see the Performance Guide.

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.

---

Note

Low Risk
Types-only change with no runtime navigation logic; low risk aside from possible compile-time breakage at mismatched call sites.

Overview
Phase 3 of the React Navigation typing migration for the redesigned Send flow: navigation is now described with explicit param lists instead of loose NestedNavigationParams / legacy Send types.

A new types/navigation.ts defines SendStackParamList (Amount, Asset, Recipient, RedesignedConfirmations), shared SendScreenRouteParams (asset, location, predefinedRecipient, legacy txMeta), and SendNavigationParamList for nested Send entry. The Send stack in send.tsx is wired as createNativeStackNavigator<SendStackParamList>().

RootStackParamList in NavigationService/types.ts now types Send as NavigatorScreenParams<SendStackParamList> and aligns root-level Amount, Recipient, and Asset with those screen params (Asset still unions AssetViewParams for the token-details route). Unused SendRecipientParams, SendAssetParams, and SendParams imports are dropped.

No intentional runtime navigation behavior change—compile-time safety only.

^{Reviewed by Cursor Bugbot for commit f1414b9. Bugbot is set up for automated code reviews on this repo. 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.

[metamask-ci]

PR template — items to address before "Ready for review"

Warnings — informational, address before merging:

• Pre-merge author checklist has unchecked items (e.g. "I've tested on Android"). Every box must be consciously checked — see docs/readme/ready-for-review.md.

See docs/readme/ready-for-review.md for the full Definition of Ready for Review.

[github-actions]

🔍 Smart E2E Test Selection

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

click to see 🤖 AI reasoning details

E2E Test Selection:
The PR makes TypeScript type-only changes to the Send flow navigation:

1. New file send/types/navigation.ts: Introduces SendStackParamList consolidating navigation params for the redesigned Send stack (Amount, Asset, Recipient, RedesignedConfirmations screens).

2. send.tsx: Adds the SendStackParamList generic to createNativeStackNavigator<SendStackParamList>() - purely a TypeScript type annotation, no runtime change.

3. NavigationService/types.ts (critical): Replaces old SendRecipientParams, SendAssetParams, SendParams imports with the new SendStackParamList type. The Recipient, Asset, Amount, and Send routes in RootStackParamList now use the new consolidated types. Confirmed via grep that the old types are no longer referenced anywhere in the codebase.

These are TypeScript type-level refactoring changes with no runtime behavior changes. However, since the Send flow navigation types in the critical NavigationService/types.ts are being modified, running SmokeConfirmations is appropriate to verify the send flow (ETH, ERC-20, BTC, SOL, TRX) still works correctly end-to-end. No other areas (swaps, staking, accounts, browser, etc.) are affected by these changes.

Performance Test Selection:
The changes are purely TypeScript type definitions for Send flow navigation params. There are no runtime behavior changes, no new components rendered, no new data fetching, and no changes to rendering logic. These type-only changes have zero performance impact.

View GitHub Actions results

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

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

See analysis details on SonarQube Cloud