Different outputs on event log subscription

Question

These are the two ways I found to track events on the Ethereum blockchain. One of them doesn't contain the data I need. Why not?

Way 1 does NOT contain the data I need Result:

subscription = web3wss.eth.subscribe('logs', {
    address: contractAddress,
    fromBlock: 0 }, 
    function(error, result) {
        if (!error)
            console.log(result);
    }
);

Output 1:

{ address: '0xCa2B2e652c365286184F594...',
  blockHash: '0x7195ed2114efca7563be43ab1aae043b6e830d27bca7073...',
  blockNumber: 8312120,
  data: '0x0000000000000000000000000000000000000000000000....',
  logIndex: 0,
  topics: 
   [ '0x95b743913ef0bd0b7e63223fdcb0589f405eb9b2a853fa328...',
     '0x32303138616263310000000000000000000000000000000...',
     '0x3230313878797a310000000000000000000000000000000000...' ],
  transactionHash: '0x7009093b3c4d6e30628818834f448fd446f4fda027...',
  transactionIndex: 1,
  transactionLogIndex: '0x0',
  type: 'mined',
  id: 'log_bbd6...' }

Way 2 contains everything I need, but also way too much data in general:

myContractwss.events.logName({
    filter: {'orderId': web3.utils.toHex('2018...')}, 
    fromBlock: 0
    })
    .on('data', data => { console.log(data); });

Output 2:

{ address: '0xCa2B2e652c365286184F5945BE...',
  blockHash: '0x0d03a61b4c372008308b5275ff8f39599...',
  blockNumber: 8312159,
  logIndex: 0,
  transactionHash: '0xe545a4b7e7c5b668905860bde6074...',
  transactionIndex: 0,
  transactionLogIndex: '0x0',
  type: 'mined',
  id: 'log_7f6...',
  returnValues: 
   Result {
     '0': '0x323031386162633100000000000000000...',
     '1': '0x3230313878797a310000000000000000...',
     '2': '900',
     '3': '123',
     orderId: '0x32303138616263310000000000000000000000000...',
     responseId: '0x3230313878797a310000000000000000000...',
     orderAmount: '900',
     deliveryDate: '123' },
  event: 'LogOrderResponse',
  signature: '0x95b743913ef0bd0b7e63223fdcb0589f405eb9b2a...',
  raw: 
   { data: '0x000000000000000000000000000000000000000000...',
     topics: 
      [ '0x95b743913ef0bd0b7e63223fdcb0589f40...',
        '0x32303138616263310000000000000000...',
        '0x3230313878797a31000000000000000000...' ] } }

Answer 1

I think that the difference is simply specificity. The first example is a parser for all the logs on the chain, without specifying contract address or filter, it would technically return all the logs that are being updated, using a websocket, so subscribe provides a more general interface, which can also be used for pendingTransactions, newBlockHeaders, and syncing.

The second option is the specific way to listen for event changes related to a contract, this option includes a parser for the data that is returned in the logs which is defined by the event in the contracts ABI, hence why you have to instantiate a contract to use this listener. The data source ends up exactly the same, however, in this instance it's naming the different parameters for you to make it easier for you to ascertain what data is relevant. The results object that you want it simply the result of parsing the raw data field of the first example, which is also included in the second example. You could generate the same thing on your own by cutting the raw data into a bytes32[] and parsing and decoding the values of the individual indexes but why do that when this does it for you. Hopes this helps :)