Reading Ledger from etherscan API vs Emitting Events

Question

Consider the following function from a solidity Contract:

function createProduct(uint _price, string memory _desc) public payable{ 
   emit UserLedgerUpdated(_desc, -1*int(msg.value));
}

I want my Dapp to show a simple ledger like the following:

Created Shoes priced at 100 Wei for a Total Cost of 2345 Wei

I have two choices here:

1. Catch the UserLedgerUpdated Event in the Dapp

2. Use the etherscan API to obtain the txn details

My questions are:

a) If I go for choice 2 (ie, reading txn details), then I can avoid emitting events. Since Events get logged and occupy space, they'd cost gas, and hence will be more expensive than reading txn details for free. Is my understanding correct?

b) While reading the ethscan API, I get the input to the function as hex. I can use web3.toAscii to convert it to string, but notice that the first argument to the function is actually a number. Hence, when I convert Input Data in Sample Transaction, I get {@Shoes instead of 123Shoes. Is there a way to properly cast the hex data we are getting from ethrscan API?

Answer 1

1. Yes, you're definitely saving gas by not emitting events. The cost however is that you're then relying on Etherscan for you dapp to function. If Etherscan is down, your dapp is down. You also lose all the users that are using multisigs since their calls to this contract will never show on Etherscan's transactions (although Etherscan does serve internal transactions as well so you might be able to get around that). It also definitely loses an aspect of it's "dappness" since it's now relying on a centralized service for data reading. If you stick with events, then users just need access to a synced node. This could be from Infura, some other node provider, or a local node.
2. This is because the 123 (7b) is the price variable, which is a number, not a string and 0x7B happens to be { in ascii. What you can do is pass the function's abi and the tx data into the web3.eth.abi.decodeParameters function after stripping away the function signature (the first 4 bytes after 0x). This will return the decoded data.