Improving of the EventLog interface

[nivida]

Improving of the EventLog interface

Currently the indexed and the non-indexed decoded returned input parameters are returned within the returnValues property of the EventLog object. This property does contain an object which contains the returned topics and data properties encoded and added by the input name and input index.

The returnValues property does exist in a returned transaction receipt of a Contract method call or when you subscribe to a Contract event.

decodeLog(inputs: Array, data: string, topics: Array)

Feel free to write a comment with your opinion about it.

Expected behavior

{
  outputs: {
    namedParameter: 'value',
    nonIndexedNamedParameter: 'value'
  }
}

Actual behavior

{
  returnValues: {
    namedParameter: 'value',
    0: 'value',
    nonIndexedNamedParameter: 'value',
    1: 'value'
  }
}

Steps to reproduce the behavior

1. Subscribe to a contract event

Versions

Web3.js latest version

[frozeman]

The reason its called like returnValues is because its part fo the event which has many more properties.
inputs is a bad name as its unintuitive, it is the output of the event, but called inputs in the ABI. Depends fro what direction youre looking at it. When writing the smart contract its the inputs of the Event, but when reading the log its the output :)

Thats why i called it returnValues, to be clear and separate from that confusion.. The return value object is a class called ReturnValues i think (?, long time ago). It has also the numbered index in there. This is so to have more than one option to access named and non named parameters.

Its also important that this is the same output for all functions that return events or decoded function call outputs. They should all look the same.

[nivida]

@frozeman renamed it to outputs which I think is the most intuitive way.

Its also important that this is the same output for all functions that return events or decoded function call outputs. They should all look the same.

Yes, the decodeLog method will still exist.

[frozeman]

The returnValues are in returned events, and when looking at the transactionReceipt and a few more places i think.

I think having the indexes as well there is important to be able to iterate and access unnamed parameters.
It basically behaves the same as decoded output from function calls.

[nivida]

Yes, the contract transaction receipts do have encoded logs. I'm decoding them with these two objects: https://github.com/ethereum/web3.js/tree/1.0/packages/web3-eth-contract/src/decoders

I think having them combined in one property is confusing. Having of named return values in an outputs property and adding an outputsByKey property with an array is probably also confusing.
This is why I think combining the decoded event input parameters in an Object with numbered properties isn't the most intuitive solution also when it's defined with two separate properties.

Another solution would be just to return an Array of inputs but I think this isn't intuitive.

[nivida]

Because the contained items in the returnValues are just properties of the event could we also call the property properties:

{
  properties: {from: "0x0000000000000000000000000000000000000000", to: "0x9CC9a2c777605Af16872E0997b3Aeb91d96D5D8c", tokens: "100000000000000000000000000"}
}

Edit:
The interface of the event log object should be written down in a similar way as a TS interface and added to the documentation.

[github-actions]

This issue 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. Thank you for your contributions