Description

Reason for the change:
The SwitchAccountTypeModal component was using the useRoute() hook internally to access route parameters. This approach has several drawbacks:

• Tightly couples the component to the navigation context
• Makes type derivation less explicit (required unsafe type assertion: (route?.params as { address: Hex })?.address)
• Reduces testability as tests needed to mock the useRoute hook globally
• No graceful handling when address parameter is missing

Improvement/Solution:

• Refactored SwitchAccountTypeModal to receive route as a prop instead of calling useRoute() internally
• Added proper TypeScript interfaces: SwitchAccountTypeModalRouteParams, SwitchAccountTypeModalParamList, and SwitchAccountTypeModalProps
• Added fallback UI with "No account selected" message when no address is available from route params
• Added missing key prop to AccountNetworkRow component in the map function (fixes React key warning)
• Significantly expanded test coverage:
  • Organized tests into logical describe blocks (rendering, route params handling, navigation, hook integration)
  • Added tests for empty network list, multiple networks, loading state
  • Added tests for address matching/non-matching scenarios
  • Added test for hook integration to verify correct address is passed

Changelog

CHANGELOG entry: null

Related issues

Fixes: N/A (internal refactoring)

Manual testing steps

Feature: Switch Account Type Modal (EIP-7702)

  Scenario: User opens switch account type modal with valid address
    Given the user has an account upgraded to a smart account on a supported network
    And the user is viewing account details

    When user taps on "Switch account type"
    Then user should see the Switch Account Type modal
    And user should see their account name
    And user should see the list of networks where the account is upgraded
    And each network row should show "Smart account" status

  Scenario: User switches back to regular account
    Given the user is viewing the Switch Account Type modal
    And the account is currently a smart account on Sepolia

    When user taps "Switch back" on the Sepolia row
    Then the account should be downgraded to a regular account on Sepolia

  Scenario: User navigates back from modal
    Given the user is viewing the Switch Account Type modal

    When user taps the back button
    Then the modal should close
    And user should return to the previous screen

  Scenario: Modal shows loading state while fetching network data
    Given the network data is still being fetched

    When user opens the Switch Account Type modal
    Then user should see a loading spinner
    And the network list should not be visible

Screenshots/Recordings

Before

N/A - No visual changes (except for new fallback state)

After

N/A - No visual changes (except for new fallback state when no address is available)

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.