-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: bump network controller 21.0.0 #11292
Conversation
Bitrise✅✅✅ Commit hash: dbf808b Note
|
72c0e3d
to
1601553
Compare
Bitrise❌❌❌ Commit hash: 0a56a68 Note
Tip
|
Quality Gate passedIssues Measures |
chainId === CHAIN_IDS.LINEA_MAINNET || | ||
chainId === CHAIN_IDS.GOERLI | ||
) { | ||
return null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is renderRpcNetworks
skipped except for this set of hardcoded known chains? Is there any difference in functionality between the two cases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We skip rendering certain networks in the if
block because we need to handle them separately to manage their order and display settings. Specifically, test networks (testnets) need to appear at the bottom of the list, and their visibility should be controlled by a toggle option (whether to show or hide them).
For the primary networks, Mainnet and Linea, they should always appear as the first and second items in the network list by default.
- Mainnet is rendered using the
renderMainnet
function. - Linea is rendered with the
renderLineaMainnet
function. - All other networks are rendered through the
renderRpcNetworks
function. - Test networks (testnets) are rendered using the
renderOtherNetworks
function.
To manage the display order and ensure proper handling, we exclude these specific networks from the networkConfiguration
state, allowing us to render them with greater control in the desired order.
Bitrise🔄🔄🔄 Commit hash: 0a76ef0 Note
|
Bitrise✅✅✅ Commit hash: 0a76ef0 Note
|
This pull request was merged into this feature branch, so I need approval on that feature branch. I'm keeping the PR open to make the review process easier. |
…etworks with Distinct ChainIDs and Multiple RPC URLs (#11705) <!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> ## **Description** This PR refactors our network configuration to eliminate the use of multiple networks with the same ChainID but different RPC URLs. Instead, we are moving towards a setup where each network is uniquely identified by a distinct ChainID and can have multiple RPC URLs associated with it. This PR includes three merge commits. The first primarily addresses the Network Controller upgrade, as outlined in issue #[11229](#11229). The second commit contains the script for migrating the state to v21, and the third commit includes all the UI changes along with the fix for the e2e tests. For more details, please refer to [this](https://github.com/orgs/MetaMask/projects/120/views/1) . related PRs: - #11292 - #11622 - #11436 <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> ## **Related issues** Fixes: #[11229](#11229) #[11232](#11232) #[11234](#11234) #11233 ## **Manual testing steps** 1. Go to add network flow and test ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** https://drive.google.com/drive/folders/149Xji42k5of5Vl8nBlI0pFYFgPnWqILH?usp=drive_link <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** - [x] I’ve followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I’ve included tests if applicable - [x] I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I’ve applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). 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.
Description
This PR updates the network-controller from version 20.0.0 to 21.0.0. The migration introduces changes in the handling of network configurations, particularly regarding how network data is structured and referenced.
Key Changes:
Consolidation of Network Configurations:
Network configurations in v21 are now organized by chainId in a new networkConfigurationsByChainId structure, replacing the networkConfigurations section in v20.
The new structure supports multiple RPC endpoints per network, as seen in the list of rpcEndpoints, with support for Infura-based connections (e.g., https://mainnet.infura.io/v3/{infuraProjectId}).
Remark
Related PRS
Related issues
Fixes: #11229
Manual testing steps
Screenshots/Recordings
Before
After
Pre-merge author checklist
Pre-merge reviewer checklist