How to Connect Web3.js to MetaMask in 2021

Alec M. Wantoch
Jan 18, 2020 · 3 min read

As of Q1 2020, MetaMask has officially stopped injecting Web3.js, and has updated the way you access the current provider. Here’s how to make sure your dApp doesn’t break, and how to make it more compatible with the rest of the ecosystem.

The Old(ish) Way

Prior to Q1 2020, MetaMask was injecting an outdated version of Web3.js, something like 0.20.x — and most people would just use the injected web3.currentProvider that MetaMask had exposed as the connection string to point their newer web3 version to.

The code would look something like this:

What this breaks down to is first checking if MetaMask is installed by checking if window.web3 was injected. If it was, then we replace the injected web3 with a newer version that we imported ourselves from somewhere like npm.

The important part to notice here is that we used the web3.currentProvider that MetaMask provided as our provider for the newer web3. This is what enabled the newer web3 version to talk to MetaMask and access the accounts and current network.

The window.ethereum.enable() line actually makes the popup UI request to connect your dApp to MetaMask, and window.web3 becomes the updated version.

Then, we could simply run the following on document load to initialize our dApp:

This would prompt the user to install MetaMask if it was not detected, otherwise, the dApp connection to MetaMask would be initialized.

The New, More Compatible Way

According to this article:

The primary motivation for these changes is to implement EIP-1102 and EIP-1193. This is great for everyone in the dApp community, since now Ethereum providers like MetaMask, Status, and Ethereum-compatible browsers will all have a standard to conform to for exposing their APIs.

The gist of the changes is basically that providers like MetaMask and Status must continue to inject window.ethereum, but now the window.ethereum object itself is a provider type that supports the methods defined in EIP-1102 and EIP-1193. No more having to check window.web3 for its currentProvider — we can simply use window.ethereum as the provider itself!

The code:

Super clean! Essentially, we check if window.ethereum exists, then create a window.web3 object with our own version of web3, using the window.ethereum object as the input provider .

In this case, the await window.ethereum.send('eth_requestAccounts') function calls the pop-up UI dialogue that asks the user’s permission to connect the dApp to MetaMask.

In this case, your dApp is now compatible with any EIP-1102 and EIP-1193 compliant Ethereum provider, making it accessible to many more potential users, and doesn’t lock your dApp into one provider.

If you enjoyed this article, I’d really appreciate if you check out a new tool I’m working on that allows you to easily distribute software, including NPM packages and wallet firmware, using Ethereum, IPFS, and Filecoin with a new open source tool, Valist — sign up for the beta at Valist.io!

We also have an awesome community of web3 and security engineers, come join our Discord server and hang out with us!

Accelerating the transition to Web3. Securely distribute software with valist.io