Truffle: Suggestion: make @truffle/contract more strict when interacting with its methods

[paulrberg]

Scenario

Let's say we have a contract instance myContractInstance and methods myPureMethod and myStateMethod.

Using truffle 5.0.0.beta.2, I can do the following in my test files:

await myContractInstance.myPureMethod(...params);
await myContractInstance.contract.methods.myPureMethod(...params).call();

And also:

await myContractInstance.myStateMethod(...params);
await myContractInstance.contract.methods.myStateMethod(...params).send();

What is the recommended way to interact with the contract? According to the docs, the latter seems to be the newest api of web3 1.0.0. If that's so, why can we still do the former? Backwards compatibility?

It's confusing because there are many examples on StackExchange and on many other websites showing a ton of different ways to achieve the same thing. More often than not, standardisation is a good thing.

Related Issues

• https://github.com/trufflesuite/truffle/issues/1230
• https://github.com/zeppelinos/zos/issues/424

Environment

• Operating System: macOS 10.14
• Ethereum client: ganache 1.2.2
• Truffle version: 5.0.0.beta.2
• node version: 10.12.0
• npm version: 6.4.1

[paulrberg]

Update

After doing more investigation, I now understand that truffle-contract was developed in the first place to have a promise-based version of the old callback-based Contract class found in the 0.20.6 version of the web3 library.

As web3 ^1.0.0 implemented Promises and PromiEvents, wouldn't it make sense to nuke out truffle-contract? At least for me, the process of upgrading to truffle ^5.0.0 has been highly problematic specifically because of this inconsistency.

Practically speaking, I posit that there would be much less confusion if Truffle injects web3.eth.Contract instances when running js tests.

[adrianmcli]

This makes a lot of sense, I'll try to bring this up with the team.

[stale[bot]]

Thank you for raising this issue! It has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. If you would like to keep this issue open, please respond with information about the current state of this problem.

[gnidan]

not stale

[stale[bot]]

Thanks for your response! This issue is no longer considered stale and someone from the Truffle team will try to respond as soon as they can.

[gnidan]

(I'm calling this a documentation issue only. The docs should be more clear on .myMethod vs. .methods.myMethod)

[haltman-at]

Extracting the web3.eth.Contract instance and using that is definitely not recommended.

We don't have an official recommentation on this at the moment, but I'd like to note that if you want the extra consistency, you can use .sendTransaction() or .call() just as well with Truffle Contract. And if you really want the extra consistency, you can use .methods. Again, all these things are still possible with Truffle Contract, e.g.:

await myContractInstance.methods.myPureMethod(...params).call();
await myContractInstance.methods.myStateMethod(...params).sendTransaction();

I would avoid using the web3.eth.Contract instance that the Truffle contract contains.

[eggplantzzz]

Hey @PaulRBerg, we're doing issue maintenance and wanted to see if there was anything left to be done here. Or can we close this? Let us know your thoughts on this!

[paulrberg]

Nah, @haltman-at brought the issue home.

[gnidan]

Guess we can close then :)

Thanks @PaulRBerg!