40 lines
1.6 KiB
Plaintext
40 lines
1.6 KiB
Plaintext
_section: Best Practices @<best-practices>
|
|
|
|
_subsection: Network Changes
|
|
|
|
Handling a change in the network (e.g. Ropsten vs Mainnet) is
|
|
incredibly complex and a slight failure can at best make your
|
|
application seem confusing and at worst cause the loss of funds,
|
|
leak private data or misrepresent what an action performed.
|
|
|
|
Luckily, standard users should likely never change their networks
|
|
unless tricked to do so or they make a mistake.
|
|
|
|
This is a problem you mainly need to worry about for developers, and
|
|
most developers should understand the vast array of issues surrounding
|
|
a network change during application operation and will understand the
|
|
page reloading (which is already the default behaviour in many clients).
|
|
|
|
So, the best practice when a network change occurs is to simply
|
|
refresh the page. This should cause all your UI components to
|
|
reset to a known-safe state, including any banners and warnings
|
|
to your users if they are on an unsupported network.
|
|
|
|
This can be accomplished by using the following function:
|
|
|
|
_code: Automatically Refresh on Network Change @lang<script>
|
|
|
|
// Force page refreshes on network changes
|
|
{
|
|
// The "any" network will allow spontaneous network changes
|
|
const provider = new ethers.providers.Web3Provider(window.ethereum, "any");
|
|
provider.on("network", (newNetwork, oldNetwork) => {
|
|
// When a Provider makes its initial connection, it emits a "network"
|
|
// event with a null oldNetwork along with the newNetwork. So, if the
|
|
// oldNetwork exists, it represents a changing network
|
|
if (oldNetwork) {
|
|
window.location.reload();
|
|
}
|
|
});
|
|
}
|