ethereum-abi-types-generator icon indicating copy to clipboard operation
ethereum-abi-types-generator copied to clipboard

Implementation with Web3 is nasty

Open dvlden opened this issue 3 years ago • 1 comments

To begin with – great project!

I found it very nasty that the example shown is doing as unknown as ContractContext on the instance of web3.eth.Contract. As I see web3 version that I'm using already has some typings. They aren't as great unfortunately. Things like events and methods are left as any. (probably more)

But for what I needed, this approach worked fine:

// ... more imports
import { Contract } from 'web3-eth-contract'
import { Factory as FactoryABI } from '../dist/Factory'

interface FactoryContract extends Contract {
  methods: FactoryABI
}

// ... later on
let factory: FactoryContract

// ... in an async fn
factory = await new web3.eth.Contract(JSON.parse(Factory.abi))
    .deploy({ data: Factory.evm.bytecode })
    .send({ from: accounts[0], gas: 1000000 })

await factory.methods.createCampaign('100').send({ ... })

So not sure if something else can be done here, but method typings are working as expected now... (I don't have any events atm)

For ethers the implementation seems better. Would you suggest ethers lib instead of web3? Not sure if there's anything you can do to improve implementation with Web3, but it'd be nice, if possible.

dvlden avatar Dec 17 '21 20:12 dvlden

Hey man! I have 100% focused on ethers integration a bit more then web3, somethings are any on web3 as I’ve just not had time to sort like event stuff etc! Overall web3 typings it generates are still very good and not missing too much. I would always advise using ethers over web3 it’s a much better IMO and built in typescript so the .d.ts files in the package are generated automatically. web3 typings have a lot of any as they were manually done (as the lib is JS).

in terms of the as unknown is because we are taking over the entire context of the contract on web3 which could run on different versions if you don’t unknown it on strict mode (even normal mode I think) it flags and errors. You can always use the (<ContractContext>) syntax instead which should not hurt your eyes to see unknown. Your syntax above only works as your deploying a contract which has an any type in web3. If you were just using a contract directly that approach would not compile in typescript.

I will have a look over the web3 integration for any missing stuff to make the integration better.. but as it’s using web3 in-house types along side it somethings are any from them and not us. This lib purely exposed the contract typings and that’s it the rest is down to the web3/ethers lib to sort (as it’s not this packages job right?!)

If you give me some lists of stuff you don’t like i can pick out the stuff which is us or them and I can also put some time aside to sort the event stuff out. On the ethers integration it does expose all the event typings but I think even on that I may be missing some places you can call events with (which may use ethers any over the packages overridden ones)

thanks for feedback goes a long way

joshstevens19 avatar Dec 17 '21 21:12 joshstevens19