Subscribing to less common socket events in v6 (i.e. newHeads)

[Stanback]

Suggestion

It would be helpful to have more clarity/examples in the documentation regarding event subscriptions for the lesser used web socket events, for example newHeads and newPendingTransactions.

In v5, I would do it like so:

const provider = new WebSocketProvider(...)
provider._subscribe('newHeads', ['newHeads'], (result) => {
  const block = provider.formatter.block(result)
  console.log(block)
}

In v6 (currently 6.2.3), I'm able to get it working via the following:

const provider = new WebSocketProvider(...)
const sub = new SocketBlockSubscriber(provider)
sub._handleMessage = (result) => {
  const block = provider._wrapBlock({ ...result, transactions: [] }, provider._network)
  console.log(block)
}
provider._register('newHeads', sub)
sub.start()

Am I doing it right?

I'm not sure what the implications are, but seems like it would be convenient if we could pass custom subscriptions directly into provider.on('event', () => ...)

[ricmoo]

This is a good point. I should also expose the UnmanagedSubscription object, so people can easily handle these, without the need to sub-class a Provider.

I'll look into this. :)

[itsmnthn]

I'm also looking to use WebSocketProvider's connection for other subscriptions other than "eth_subscription" What if some custom node exposes custom subscriptions like "node_health" and has few methods that can be subscribed?

Using v5.7.2, it logs the warning this should not happen instead of this log, I feel it should expose some method that will be called on as you call it UnmanagedSubscription.

Is there any way I can do this with v5?

[ptdatta]

@Stanback Is this issue still open to work on it??

[Stanback]

@Stanback Is this issue still open to work on it??

I would ask @ricmoo, I'm sure you could take a stab at it and open up a PR

@Stanback I think you should remove provider._register('newHeads', sub) line as they don't work right now.