Ability to call non-constant function

[hayesgm]

ethjs-contract

Issue Type

• Bug (https://github.com/ethjs/ethjs-contract/blob/master/.github/CONTRIBUTING.md#bug-reports)
• Feature (https://github.com/ethjs/ethjs-contract/blob/master/.github/CONTRIBUTING.md#feature-requests)

Description

The current implementation decides whether to make a gas-free call or execute a transaction based on the whether the ABI specifies the function is constant or not. Here is the relevant code line. While this decision makes sense in the general case, it doesn't allow us to use this library to make a call to a non-constant function (e.g. to check to see if it's likely to succeed), or to execute a transaction to a constant function (well, less of a use-case for that one). In either case, it would be nice to allow the caller of this library to specify call versus sendTransaction from either a flag to the current functions or by defining a separate set of functions.

A current work-around is to redefine the ABI to mark a non-constant function constant and pass that ABI to this library.

This is a feature request to allow a caller of this library to make a gas-free call to a non-constant function without redefining the ABI. Any proper implementation will suffice, and I am happy to help define what this might look like if there's interest in this request.

[SilentCicero]

Totally possible, we could just do a slight rework to make this possible. Would you like to suggest a notation and or a PR? For now, you can checkout ethjs-extras 'ethCall' there you can setup a simple call however you want. Best, Nick

…

Sent from my iPhone

On Mar 31, 2018, at 12:25 AM, Geoff Hayes ***@***.***> wrote: ethjs-contract Issue Type Bug (https://github.com/ethjs/ethjs-contract/blob/master/.github/CONTRIBUTING.md#bug-reports) Feature (https://github.com/ethjs/ethjs-contract/blob/master/.github/CONTRIBUTING.md#feature-requests) Description The current implementation decides whether to make a gas-free call or execute a transaction based on the whether the ABI specifies the function is constant or not. Here is the relevant code line. While this decision makes sense in the general case, it doesn't allow us to use this library to make a call to a non-constant function (e.g. to check to see if it's likely to succeed), or to execute a transaction to a constant function (well, less of a use-case for that one). In either case, it would be nice to allow the caller of this library to specify call versus sendTransaction from either a flag to the current functions or by defining a separate set of functions. A current work-around is to redefine the ABI to mark a non-constant function constant and pass that ABI to this library. This is a feature request to allow a caller of this library to make a gas-free call to a non-constant function without redefining the ABI. Any proper implementation will suffice, and I am happy to help define what this might look like if there's interest in this request. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[hayesgm]

Nick,

Sure thing. This will take me a few days since I'm traveling, but I'll follow-up with a suggestion and then an implementation shortly. I am currently working around the feature by marking the ABI (incorrectly) as constant, which solves the proximate issue for my project.

Thanks, -Geoff

[SilentCicero]

Yeah, this should definitely be addressed. Thanks!

…

On Mon, Apr 2, 2018 at 8:45 PM, Geoff Hayes ***@***.***> wrote: Nick, Sure thing. This will take me a few days since I'm traveling, but I'll follow-up with a suggestion and then an implementation shortly. I am currently working around the feature by marking the ABI (incorrectly) as constant, which solves the proximate issue for my project. Thanks, -Geoff — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#16 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJWhXn_skH6v61MrGTbDCS2iieNRim1Vks5tkn_agaJpZM4TCMs6> .

[hayesgm]

Nick, my first thought (that would be the easiest) would be to add a simple field to the "transaction object" called execute. execute would take one of three states:

• {execute: true} implies that we should always execute this call as a transaction
• {execute: false} implies that we should never execute this call as a transaction (instead, querying)
• {execute: undefined} queries when the ABI specifies a constant function, and executes when non-constant (current behavior)

This change would be very easy to implement and be fully backwards compatible.

[SilentCicero]

Will review tomorrow, couldn't get to this today.

…

Sent from my iPhone

On Apr 9, 2018, at 7:32 PM, Geoff Hayes ***@***.***> wrote: Nick, my first thought (that would be the easiest) would be to add a simple field to the "transaction object" called execute. execute would take one of three states: {execute: true} implies that we should always execute this call as a transaction {execute: false} implies that we should never execute this call as a transaction (instead, querying) {execute: undefined} queries when the ABI specifies a constant function, and executes when non-constant (current behavior) This change would be very easy to implement and be fully backwards compatible. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.