Returning Array instead of an Object when calling automatic getter for a mapping to struct?

[LuisHPorras]

Intro

Hi! I'm new here and to ethers.js too.

I've being writing some basic contracts and I've observed the behavior described later on. I was wondering if @ricmoo or anyone else could explain (or redirect haven't found anything out there), why would we prefer an Array with both named an unnamed parameters instead of an Object when a struct is returned form a contracts function.

Description

• Public mapping from uint to struct inside a smart contract e.g. mapping(uint16 => BadgeInfo) public badgesById
• When using the automatically generated getter the result of calling the method is an Array with duplicated info instead of an Object

Code

Smart contract

Link to file

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.0;

import "hardhat/console.sol";

contract Badge {

  address public owner = msg.sender;
  uint16 currentId = 0;
  struct BadgeInfo{
    uint16 id;
    address issuer;
    string issuerName;
    address recipient;
    string recipientName;
  }
  mapping(uint16 => BadgeInfo) public badgesById;
  event BadgeIssued(uint16 id, string issuerName, string recipientName);

  function issue(string memory _issuerName, address _recipient, string memory _recipientName) public {
    badgesById[currentId] = BadgeInfo({
      id: currentId,
      issuer: msg.sender,
      issuerName: _issuerName,
      recipient: _recipient,
      recipientName: _recipientName
    });

    emit BadgeIssued(badgesById[currentId].id, badgesById[currentId].issuerName, badgesById[currentId].recipientName);

    currentId++;
  }
}

Test

Link to file

const { expect } = require("chai");

describe("Badge contract", function () {

  let owner;
  let issuer;
  let recipient;
  let badgeInfo;

  let Badge;
  let badge;

  before( async function () {

    // Save account addresses once to use in each test 
    const accounts = await ethers.getSigners();
    owner = accounts[0];
    issuer = accounts[1];
    recipient = accounts[2];

    // Badge info to use
    badgeInfo = {
      id: 0,
      issuer: issuer.address,
      issuerName: "Ivan Illich",
      recipient: recipient.address,
      recipientName: "Gustavo Esteva"
    };

  });

  beforeEach( async function () {
    
    // Deploy fresh contract before each test
    Badge = await ethers.getContractFactory("Badge");
    badge = await Badge.deploy();
    await badge.deployed();

  });

  // (...)

  it("Should return a badge", async function () {

      await badge.issue(badgeInfo.issuerName, badgeInfo.recipient, badgeInfo.recipientName);

      const badgeResult = await badge.badgesById(badgeInfo.id);
      console.log(badgeResult);

      expect(badgeResult).to.deep.equal(badgeInfo);

    });
  });
});

Output

$ npx hardhat test


  Badge contract
    Deployment
      ✓ Should set the right owner
    Issuing
      ✓ Should emit a badge issued event (46ms)
[
  0,
  '0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266',
  'Ivan Illich',
  '0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC',
  'Gustavo Esteva',
  id: 0,
  issuer: '0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266',
  issuerName: 'Ivan Illich',
  recipient: '0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC',
  recipientName: 'Gustavo Esteva'
]
      1) Should return a badge


  2 passing (666ms)
  1 failing

  1) Badge contract
       Issuing
         Should return a badge:
     AssertionError: expected [ Array(5) ] to deeply equal { Object (id, issuer, ...) }
      at Context.<anonymous> (test/badge-test.js:67:35)
      at processTicksAndRejections (internal/process/task_queues.js:95:5)
      at runNextTicks (internal/process/task_queues.js:64:3)
      at listOnTimeout (internal/timers.js:526:9)
      at processTimers (internal/timers.js:500:7)

Steps to reproduce

1.- Clone the repo & switch to smart-contracts branch

git clone https://github.com/luishporras/web3-server
git checkout smart-contracts

2.- Install deps and run tests

npm install
npx hardhat test

Gratitude

Thanks in advance and excuse me if this is not the proper channel.

[ricmoo]

This is the perfect channel to discuss this. :)

This way the method returns the same type of object whether you use function bar() returns (uint256, bool) and function bar() returns (uint256 a, bool b). The same goes for nesting structures, arrays and anything else.

Otherwise code which accepts a contract as a parameter would have to inspect what type of ABI was used for a given method to determine how to decouple it (since it could be an object in some case, and Array.isArray and typeof Would be of little use, since the result could legitimately be an array).

So it makes code that programmatically extends a Contract and Result much easier, since it can always just use positional arguments. And developers can also interact directly with any named parameters.

It also gracefully handles the case where you have function foo() returns (uint a, bool). In this case you won’t be able to return an object because the bool has no name. So an array would have to be returned, and then you have no way to access the names a. Keep in mind structs can also have unnamed properties, which would cause unwanted behaviour in the object case.

Basically, ABI encoded data guarantees everything is accessible positionally. But names are just nice-to-have. So arrays are perfect; the guarantee positional access and allow keywords optionally.

For your test case you could either use a custom matcher (I might write one at some point for some of these objects) or maybe compare the Array, converting badgeInfo using something like Object.keys(badgeInfo).map(n => badgeInfo[n]).

I’m considering adding some extra functionality to the Result object in v6, like an _equals() and support for a new EIP in the works. ;)

Does that make sense?

[LuisHPorras]

It does make a lot of sense! Thank you very much for your reply.

The points you mentioned are very good so I'd like to point out a couple of things:

My main concern is that, maybe it is just my lack of experience with the library but, I was expecting to receive an Object as a result and instead I received an Array. I think this may lead to unexpected behaviors in bigger apps if you don't notice it (e.g. the code checking for Object type to perform a task).

In case there are multiple unnamed parameters in a function then the developer is aware of it and might be expecting an Array as a result since no Object could be received or else the parameters might have standardized names which she would have to check in the docs. My point is, what is the main use case? Named or unnamed parameters? In case it is the named parameters I'd go for the intuitive solution (e.g. only use the Array structure if no named parameters are present and use Object otherwise). In fact, either way, returning an Object when possible seems to me like something you'd expect to happen. I understand the uniformity that this data structure gives to the operation but I see it from this point: if the function returns a number you expect the type of result to be an int or BigNumber, if string you expect a string, if a struct an object, if its mixed then the Array with both positional and named values suits perfectly.

The other concern I have is: since no object is returned we loose some JS functionalities like decomposition which is very useful when working with component oriented frameworks. Is there a way of having this functionalities with the Array structure you propose?

I've observed you use the word object sometimes when referring to this use of Array, is there a specific reason for that? In fact in the docs of meta-class you refer to Result as an "object", I'd suggest using the word Array to raise awareness.

Again, thanks a lot for you time. Hope this makes sense as well!