good to have a contract class exported to reuse

[ethdev279]

import { publicClient } from './client'
import { wagmiAbi } from './abi'

const data = await publicClient.readContract({
  address: '0xFBA3912Ca04dd458c843e2EE08967fC04f3579c2',
  abi: wagmiAbi,
  functionName: 'totalSupply',
})

its kind of weird to specify address and abi everytime we wanted to call contract function. I know you guys adopted this from wagmi. but can we break this pattern? what if we have a contract class exported and sothat we can instantiate with it address and abi once and reuse everywhere? like how etheres Contract class is doing?

like this:

import { publicClient, ContractClient } from './client'

const contract = new ContractClient(address, abi, account);

@alcuadrado @kolber

[glitch-txs]

Yep, an alternative I can think of could be something like this:

import { publicClient } from './client'

const myContract = {
    abi: contractABI,
    address: '0xFBA3912Ca04dd458c843e2EE08967fC04f3579c2'
}

const data = await publicClient.readContract({
  contract: myContract,
  functionName: 'totalSupply'
})

Then this object contract could be saved on a different file and be imported when needed

You could still use ...myContract though 😄

import { publicClient } from './client'

const myContract = {
    abi: contractABI,
    address: '0xFBA3912Ca04dd458c843e2EE08967fC04f3579c2'
}

const data = await publicClient.readContract({
  ...myContract,
  functionName: 'totalSupply'
})

[jxom]

UPDATE: we are going to look into an abstraction for this.

The main reason why we want with this API design (originally from wagmi) is because we didn't want to design nested APIs. We ideally want to keep our APIs flat so everything is more discoverable and flexible to move around. For example, we wanted to avoid creating a client and then inserting that client into a contract instantiator, which can make it very confusing because you won't know when you are interacting with a public client (e.g. contract read via an Alchemy RPC) vs. a wallet client (e.g. contract write via injected wallet RPC) – which I think is important as contract write functions deal with end user money. And we can't use a single wallet client for both read/writes because some injected wallets do not support eth_call (think they want to keep their RPC bill low 😜) which are needed for reads.

For now, you can do @glitch-txs abstraction, ie:

import { publicClient, walletClient } from './client'

const wagmiContract = {
  address: '0x...',
  abi,
} as const

const data = await publicClient.readContract({
  ...wagmiContract,
  functionName: 'totalSupply',
})

const hash = await walletClient.writeContract({
  ...wagmiContract,
  functionName: 'mint'
})

That being said though, the most important thing is that we have the primitives to make the abstraction easy in the future. We can have a closer think about what an API could look like so you only need to define things once and not spread things through.

In the future, we will probably have a viem plugin for @wagmi/cli to auto-gen contract actions, so that will help too!

[glitch-txs]

Totally agree, I really like the more simplistic approach, so you don't have to deal with multiple things:)

[jxom]

Yep, and I am definitely open to ideas for abstraction if it sticks to our philosophy of comprehensive, flexible & pure APIs!

[jxom]

Have had a bit more time to think about this and think an abstraction around contracts would still be really nice. Going to see what an API could look like, hold tight!

[jxom]

Check out the RFC for Contract Instances! #165