Web3 Front-End - connect to contract with ethers

Support
1

In my web front-end, I need the ability to interact with the Ethereum blockchain.

  1. It’s possible a user has MetaMask installed.
  2. It’s possible a user is using the web without MetaMask installed.
  3. It’s possible a user is using an old dApp browser.
  4. It’s possible a user is using a modern dApp browser.

The following code takes care of all possibilities, and injects ethers.js as a last resort:

if (window.ethereum) { // Modern dapp browsers...
	window.web3 = new Web3(ethereum);
} else if (window.web3) { // Legacy dapp browsers...
	window.web3 = new Web3(web3.currentProvider);
} else { // Non-dapp browsers...
	window.web3 = ethers; // ethersjs provided library
}

It works! Great! I can make web3.eth.getBalance() calls and such.

Here’s where it gets hairy:
It appears that the exposed interface for dealing with Contracts is not uniform across libraries, both in terms of the constructor and order of parameters.

Have I approached this entirely wrong?

Side question: Did MetaMask roll their own web3 library or are they using web3.js or something similar?

3 Likes
2

Hi @EvilJordan,

Front-end development is an area of expertise for me :slightly_frowning_face:
Hopefully someone in the community can answer this. Sorry not to be more immediately helpful.

I suggest looking into create-eth-app by @PaulRBerg.

2 Likes
3

How DARE you not know everything, @abcoathup!?

Thanks for the suggestion… I’ll pick through the code to see what I can see, but I avoid React and NPM prefab stuff for the front-end whenever possible. Framework bloat and endless dependencies are a stain on the world (I’m an old neckbeard).

My guess is the answer is “yeah, these things are completely non-standard at the moment and it’s a pain in the ass.”

The simple solution to this is to move all view-only calls server-side where I can control the library being used, but that shouldn’t be the answer.

1 Like
4

Hi @EvilJordan,

You could also look at https://github.com/OpenZeppelin/openzeppelin-network.js for some ideas.
:warning: This project is in maintenance mode. We are no longer actively developing new features, and will only be releasing fixes for high severity issues until July 2020.

I assume that there is an ethers.js approach, I’m just not familiar with it unfortunately.

The things I don’t know can fill a very large bucket. :smile:
I keep learning every day and sharing what I learn but the bucket keeps growing too.

1 Like
5

The answer is web3.js and ethers.js are just wildly different, and most examples out there are using web3.

This is now solved with a simple bit of code, to always use ethers.js:

// include your ethers.js library somewhere prior to this
let provider;
if (typeof(web3) !== 'undefined') {
	provider = new ethers.providers.Web3Provider(web3.currentProvider); // use Metamask or whatever the dApp browser provides
} else {
	provider = new ethers.getDefaultProvider(); // use ethers.js underlying fallbacks
}

Thanks, me!

1 Like
6

Well done on solving @EvilJordan

You could always write a guide on how to create a simple dapp with ethers.

1 Like
7

Perhaps I will once I have more functionality built out from which to pull examples!

1 Like
8

Hey @abcoathup, thanks for mentioning Create Eth App!

I skimmed through all replies and, while I’d love to shill my tool, it wouldn’t be the best solution to @EvilJordan’s issue.

What you’re looking for is web3-react. I can’t recommend it enough, it was built to solve this particular conundrum of standards across different web3 wallets. It works with React and Hooks. The Uniswap frontend is a great example of a project that uses web3-react under the hood.

With regards to ethers vs web3.js, I’d strongly recommend using the former, even if most code snippets on the Internet use the latter. Ethers is just much more robust and less error-prone, and the documentation is fantastic.

3 Likes