Contract methods unexpectedly returning outputs in an array

[zemse]

Hi @ricmoo, I've been getting an unusual output from contract methods.

I have a simple smart contract (storage declarations are omitted)

contract ERC20 {
	constructor() public {
		totalSupply = 9100000000 ether;
		balances[msg.sender] = totalSupply;
	}

	function balanceOf(address tokenOwner) public view returns (uint256) {
		return balances[tokenOwner];
	}
}

And expected doing the following:

await erc20Instance.functions.balanceOf(/* deployer address */)

produces:

[
  BigNumber { _hex: '0x1d6757f47b1c8ef70c000000', _isBigNumber: true }
]

But I expected it to give following instead of an array value:

BigNumber { _hex: '0x1d6757f47b1c8ef70c000000', _isBigNumber: true }

I've attached a git archive containing the reproducible script for you to quickly test it.
git-archive-testp.zip. Please let me know if it's working for you.

Also, would like to highlight that, the simple storage contract's getValue method (also in #862) returns a straight string value as expected (due to which the test project tests pass successfully). At this point I'm not able to differentiate exactly what makes it give expected/unexpected outcome.

Can you please try to reproduce this? I believe this might be related to the recent contract refactor.

[ricmoo]

This is intentional and part of v5. The .functions bucket returns a version of a function that is designed to better support frameworks and more importantly recoverable errors.

If a method returns a single item, the contract.foo() will return that value, as it did in v4, while the contract.functions.foo will return a Result object (which extends Array).

I’ll be adding a section to the docs soon on how to use error recovery.

Make sense? You can just use the non-.functions version. :)

[ricmoo]

(prior to this, the logic frameworks required to re-normalize a call involved fragment inspection)

[zemse]

Okay, I got this.