While developing a DApp you have to somehow inject and manage web3 instance on your frontend. I have seen a lot of developers doing some in place solutions but recently I’ve discovered web3-react library thanks to @Dennison.
Do you use web3-react or similar library? Do you have a need for such a library? If yes, then which features would be the most important?
Looking forward to reading all your contributions on this subject.
I have used web3.js for dApps, most recently using the Choo framework.
In my spare time I have been working on a React Native (expo) mobile app for Peepeth, but it was problematic to get the web3 configuration right in expo, once I had it sorted I created a boilerplate https://github.com/abcoathup/expo-web3. For the mobile app I need private key generation and message signing.
Hey! I really like web3.js, still remember the first time I “spoke” to Ethereum and it answered it was amazing. Haven’t used any framework or ethers.js but I plan to keep exploring on this. We have an interesting topic here.
I’ve used only web3.js I like it since it does not force you into any framework, the documentation is great and there are a ton of examples already using it.
Hi! I also have used web3.js in my last project (Vue framework). I have chosen it because you can use it regardless of what framework you use. But probably if I used more often one frontend framework, I would try a dedicated library.
Have been using web3.js with manual networkConfig.js file
that looks something like this
with default netId == 1 if web3 is not injected.
All state reading calls are done thru my own custom rpc URL, and only signing tx is used with injected web3 instance
@spalladino it’s been awhile! I’d be happy to chime in. My front end toolset has evolved significantly since I started building dapps.
The first toolset was React, Redux and Web3.js 0.20. The callback version of web3.js was clunky, but it worked. Writing Redux code from scratch meant that the cache lifecycle was managed manually and there was a lot of boilerplate. The tools left much to be desired.
Next I tried Drizzle, which is a framework that wraps React, Redux and Web3.js 1.0. The framework provides basic Web3 state out-of-the-box (i.e. network, account, balance), but it’s approach to caching exposes the mechanism rather than abstracts it: for each web3 call users must keep track of a cache key to lookup the data in the Redux state. The results in much added complexity. Additionally, web3.js 1.0 was extremely buggy and lacked event subscriptions.
Finally what I realized is that web dapps are simply caches for remote data. For the most performant application possible, we needed a powerful caching framework that allowed us to invalidate portions of local state in response to remote changes. Enter the Apollo framework. We developed a custom “link” for Apollo that allows us to use GraphQL to speak to Ethereum clients called apollo-link-ethereum. The link uses ethers.js instead of web3.js, as it is actively maintained, well documented, and relatively bug-free.
Now, not all applications are going to need to cache smart contract data. After reading the above I had a quick look at web3-react, and it looks like a nice way to quickly put a small application together. If you build something with enough complexity, however, you’ll eventually need to optimize the application by having a global shared state. I highly recommend having a look at our framework for larger applications.
tldr; The best library to use to connect to Ethereum right now is ethers.js. For small user interfaces web3 component kits would suffice, but for anything larger you’ll need to consider caching.
Hope this helps! I’d love to hear other people’s thoughts as well.
Hey @mortimr! Thanks for dropping in!
Ethvtx is a cool project! Which projects use ethvtx? I would love to see it in action.
I can you see picked Embark for your main demo. What are the reasons for doing so?
For the mobile app I need private key generation and message signing.
Essentially you need a wallet because you can't use metamask, right? Have you written one yourself using web3.js?
Hey @ianbrtt. How is your experience so far with web3.js? Do you use 0.x version or 1.x version? Did you managed metamask/infura connection code yourself? Events like auth, lock, account change?
Hey @scammi. Thank for joining conversation. I have a question for you since you like to use pure web3.js. How do you handle metamask and infura connections? Do you write this code yourself? Does it react properly on events like auth, lock, account change, network change, disconnect and so on?
Hey @paulinablaszk! Thanks for joining in. Appreciated! Is your code for last project open source? Would like take a look on it!
How did you handled web3 infura, metamask connection management? Like reacting to events such as auth, lock, account change, network change, disconnect? Was it easy to write this kind of code?
Also how was web3.js integration into Vue? Was it super easy?
Sorry for so many questions but I am excited to learn about your dev experience
PS There is also library called vue-web3. You might be interested in it.
Hey @rstormsf. Thanks for contributing to this topic!
I have to admit that is quite a unique networkConfig. Haven't ever seen anything like that.
All state reading calls are done thru my own custom rpc URL, and only signing tx is used with injected web3 instance
That is exactly my experience. I figured it out a hard way that using metamask web3 provider for querying an Ethereum node is highly inefficient and unreliable. I had requests which simply dropped of or had taken like 30 seconds.
I can see you manage a Metamask state at askPermission function. Does it covers all the cases for you? Like auth, lock, network change, account change? Does it works smoothly?
Also I can see you ignore window.web3? Are you intentionally do not support legacy API?
I’d say because you can utilize web3 on many platforms and frameworks we can’t have on fits it all library. It is possible to write generic library for managing web3 provider abstraction but I would argue it is not possible to write one for every platform/framework. And even if it is possible it would be to heave and ugly. We already have libraries like web3-react and vue-web3. I am pretty certain we’ll see more libraries like web3-someframework.
I want the React-Native (expo) mobile app to be able to generate a private key, and then use the private key to sign messages (actions). The user could link the mobile app private key with their account using a dApp browser.
In a node version I used ethers.js to generate an account and do the signing.
I was having trouble with web3.js in React-Native (expo) getting it configured so that I could generate an account. I need to go back to this when I get a spare weekend.
Hey @asselstine. Thanks for joining with your deep response.
I personally had a quite similar history path with web3 libraries.
That is really cool that you’ve taken an action and created apollo-link-ethereum. I absolutely agree that caching layer is required for any not trivial Ethereum DApp for the sake of performance and stability.
At the same time you still have to sign transactions with Metamask/Trezor/Ledger. How do you typically manage that code? Is it easy for to manage state changes such as auth, lock, account change, network change? Is it easy to do with ethers.js?