💡 [REQUEST] - Return value from Contract.reads instead of lists

[ifavo]

Summary

When reading from a contract using a Contract instance from sdk-network, the result is always returned as a list. (This appears to be due to the raw ThorNode results being passed through, which return lists because of multi-clause processing.)

From a developer experience standpoint, this consistent use of lists adds unnecessary complexity and friction during development.

To enhance the developer experience, I suggest modifying the function to return the value of [0] directly in such cases, rather than leaving it in a list.

Basic Example

const VTHO = new Contract("0x...", [...ABI_ERC20], thorClient)

// current situation
const [balance] = await VTHO.read.balanceOf(address)

// desired situation
const balance = await VTHO.read.balanceOf(address)

[fabiorigam]

@ifavo It's possible to return two values, try this one for example:

// SPDX-License-Identifier: MIT
pragma solidity 0.8.20;

contract SampleContract {
    function a() public pure returns (uint, string memory) {
        // Return values are (1, "a")
        return (1, "a");
    }

    function b() pure public {
        uint A;
        string memory B;

        // A is 1 and B is "a"
        (A, B) = a();

        // A is 1
        (A,) = a();

        // B is "a"
        (, B) = a();
    }
}

Given this, I wouldn't change the code. What do you think?

[ifavo]

@fabiorigam the list in the result matches the clauses and because a single clause request only has a single clause response, it would always be wrapped in the first element, or am I mistaken?

If you return a tuple/struct, would that not be wrapped the same way?

to use your example:

// current situation
const [ [val1, val2] ] = await contract.read.a()
// val1 = 1, val2 =a

// desired situation
const [val1, val2] = await contract.read.a()
// val1 = 1, val2 =a

[fabiorigam]

It's already like the desired situation, see: #1280

[ifavo]

It's already like the desired situation, see: #1280

I just used the latest version (beta 30) and it already works as desired, at least in beta 18 it was still the case.
This issue is indeed obsolete and no longer valid.

Thank you 🙏