Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Group network configurations by chain (#4286)
## Explanation
<!--
Thanks for your contribution! Take a moment to answer these questions so
that reviewers have the information they need to properly understand
your changes:
* What is the current state of things and why does it need to change?
* What is the solution your changes offer and how does it work?
* Are there any changes whose purpose might not obvious to those
unfamiliar with the domain?
* If your primary goal was to update one package but you found you had
to update another one along the way, why did you do so?
* If you had to upgrade a dependency, why did you do so?
-->
Currently, in the client, it is possible to have multiple networks with
different RPC endpoint URLs representing the same chain. This creates a
problem because if all we have is a chain ID, we don't know which URL to
use for requests.
To solve this, we plan on consolidating the UX on the client side such
that each network corresponds to exactly one chain. Users can then
select which default RPC URL they'd like to use for requests. This
commit implements the controller changes necessary to support this UX.
Here are some more details on the changes here:
- The concept of a network configuration has been repurposed such that
instead of representing an RPC endpoint, it now represents a whole
chain.
- A network configuration may have multiple RPC endpoints, and one of
them must be designated as the default.
- Some RPC endpoints are special in that they represent Infura API URLs;
these have the same object shape as "non-Infura" (custom) RPC endpoints,
but the Infura project ID is hidden and injected into the RPC URL when
creating the network client.
- There is no longer a 1-to-1 relationship between network configuration
and network client; rather, the 1-to-1 relationship exists between RPC
endpoint and network client. This means that the ID of the network
client which is created for an RPC endpoint is stored on that RPC
endpoint instead of the whole network configuration.
- The `networkConfigurations` state property has been replaced with
`networkConfigurationsByChainId`. This continues to be an object, but
the data inside is organized such that network configurations are
identified by chain ID instead of network client ID as they were
previously.
- The methods `upsertNetworkConfiguration` and
`removeNetworkConfiguration` have been removed. These methods always did
more than simply add or remove a network configuration; they also
updated the registry of network clients. Instead, these methods have
been replaced with `addNetwork`, `updateNetwork`, and `removeNetwork`.
- `addNetwork` creates new network clients for each RPC endpoint in the
given network configuration.
- `updateNetwork` takes a chain ID referring to a network configuration
and a draft version of that network configuration, and adds or removes
network clients for added or removed RPC
endpoints.
- `removeNetwork` takes a chain ID referring to a network configuration
and removes the network clients for each of its RPC endpoints.
- In addition, due to the changes to network configuration itself, there
are new restrictions on `networkConfigurationsByChainId`, which are
validated on initialization and on update. These are:
- The network controller cannot be initialized with an empty collection
of network configurations. This is because there must be a selected
network client so that consumers have a provider to use out of the gate.
- Consequently, the last network configuration cannot be removed.
- The network configuration that contains a reference to the currently
selected network client cannot be removed.
- The chain ID of a network configuration must match the same chain that
it's filed under in `networkConfigurationsByChainId`.
- No two network configurations can have the same chain ID.
- A RPC endpoint in a network configuration must have a well-formed URL.
- A network configuration cannot have duplicate RPC endpoints.
- No two RPC endpoints (regardless of network configuration) can have
the same URL. Equality is currently determined by normalizing URLs as
per RFC 3986 and may include data like request headers in the future.
- If a network configuration has an Infura RPC endpoint, its chain ID
must match the set chain ID of the network configuration.
- Changing the chain ID of a network configuration is possible, but any
existing Infura RPC endpoint must be replaced with the one that matches
the new chain ID.
- No two RPC endpoints (regardless of network configuration) can have
the same network client ID.
- Finally, the `trackMetaMetricsEvent` option has been removed from the
constructor. This was previously used in `upsertNetworkConfiguration` to
create a MetaMetrics event when a new network added, but I've added a
new event `NetworkController:networkAdded` to allow the client to do
this on its own accord.
## References
<!--
Are there any issues that this pull request is tied to? Are there other
links that reviewers should consult to understand these changes better?
For example:
* Fixes #12345
* Related to #67890
-->
Fixes #4189.
Fixes #3793.
## Changelog
<!--
If you're making any consumer-facing changes, list those changes here as
if you were updating a changelog, using the template below as a guide.
(CATEGORY is one of BREAKING, ADDED, CHANGED, DEPRECATED, REMOVED, or
FIXED. For security-related issues, follow the Security Advisory
process.)
Please take care to name the exact pieces of the API you've added or
changed (e.g. types, interfaces, functions, or methods).
If there are any breaking changes, make sure to offer a solution for
consumers to follow once they upgrade to the changes.
Finally, if you're only making changes to development scripts or tests,
you may replace the template below with "None".
-->
(Updated in the PR.)
## Checklist
- [ ] I've updated the test suite for new or updated code as appropriate
- [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or
updated code as appropriate
- [ ] I've highlighted breaking changes using the "BREAKING" category
above as appropriate
---------
Co-authored-by: Jongsun Suh <[email protected]>
Co-authored-by: Brian Bergeron <[email protected]>
Co-authored-by: Michele Esposito <[email protected]>
Co-authored-by: Michele Esposito <[email protected]>- Loading branch information
5 people
authored
Sep 3, 2024
1 parent
b4d5f3e
commit 442a300