eth_subscribe push subscriptions vs eth_getFilterChanges polling?

[kdembler]

I'm currently migrating an application from [email protected]/ethers@5 to [email protected]/viem. One internal difference I've noticed is how event subscriptions are handled. With ethers, if you are using a websocket connection and subscribe to events, eth_subscribe will be used with a list of topics, so that your provider can push events via WS to your application as soon as they become available. viem on the other hand, uses explicit eth_newFilter with eth_getFilterChanges polling, even on WS connection.

Both approaches have drawbacks, but I'm curious to hear if there's anything specific that pushed you to go for polling or if you foresee support for eth_subscribe in the future

[jxom]

No reason! We have been meaning to add parity for that. Looking to do it soon, but also open to contributions.

would be somewhat similar pattern to how we do it on watchBlocks: https://github.com/wagmi-dev/viem/blob/main/src/actions/public/watchBlocks.ts#L189

[kdembler]

Glad to hear, offering both as a choice is the best way forward. Out of curiosity, does your websocket transport include retries/reconnects out of the box? With ethers I had to tweak their implementation quite a bit to support those functionalities

[FreezyEx]

any update on this?

No reason! We have been meaning to add parity for that. Looking to do it soon, but also open to contributions.

would be somewhat similar pattern to how we do it on watchBlocks: https://github.com/wagmi-dev/viem/blob/main/src/actions/public/watchBlocks.ts#L189

[thebillzh]

Any update on the timeline to add websocket support for watchEvent and watchContractEvent? Appreciate it

[simoneNEMO]

Made a PR for this: #985
Probably a couple of things to polish in it but should solve this discussion.

[mihoward21]

Hey @jxom I saw you merged in a change for this back in August, but I'm still having issues getting my websocket client to use subscriptions instead of polling.

Your pr and the documentation make it look like if I'm calling watchContractEvent with a websocket public client it should be using subscriptions by default, not polling. But that's not what I'm seeing.

My code looks like:

const websocketPublicClient = useWebSocketPublicClient({ chainId: 1 })
websocketPublicClient.watchContractEvent(...)

It looks like you are checking websocketPublicClient.transport.type to determine if polling should be on or off by default. When I check that property in this case it says it's fallback, not webSocket. I definitely have a websocket public client setup in my config though for mainnet, and I can see the websocketPublicClient.transport.transports field contains a websocket transport.

Anyway, seems like there's a bug with useWebSocketPublicClient, but maybe I'm doing something wrong.

In the meantime I'm just manually creating a websocket client and that is working as expected with subscriptions by default:

const websocketPublicClient = createPublicClient({
  transport: webSocket(websocketUrl),
  chain: 1
})

[gershido]

Any update re support for subscribing to events via websocket (without polling)?