Explanation

While debugging an issue with SwapsController's provider instance being updated too soon due to the remove networkId refactor, I noticed many of our controllers listen to NetworkController:stateChange which fires numerous times each time the network switches. Some of these controllers keep track of the chainId it's last seen between these events to ensure it only fires off any necessary side effects once. Some controllers don't keep track of if it's seen the chainId at all and will fire off the side effects for each and every stateChange event. Using chainId as a guard isn't even necessarily correct in some cases as the provider may have changed despite the chainId remaining the same.

It seems more appropriate/accurate for these controllers to be listening to NetworkController:networkDidChange instead which only fires once for each network switch, and after the provider proxy has been updated to point at the right RPC endpoint.

Currently the NetworkController:networkDidChange event is a little bit inconvenient to consume because generally any listeners to this event would want to know what the network changed to / what the current state of things are to determine next steps. This PR adds NetworkState to the NetworkController:networkWillChange and NetworkController:networkDidChange event payloads

References

• See: https://github.com/MetaMask/MetaMask-planning/issues/1713

Changelog

@metamask/network-controller

• CHANGED: NetworkController:networkWillChange includes NetworkState as the first and only item in the payload
• CHANGED: NetworkController:networkDidChange includes NetworkState as the first and only item in the payload

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