Aggregate event subscriptions

[norswap]

Currently, we're subscribing to each event separately. This was a limitation of viem at the time I set that up, and maybe it still is.

This needs to change, even if we have to bypass Viem, because we're listening for A LOT of events and currently we're positively hammering the RPC with eth_getFilterChanges requests.

[jxom]

You can listen to multiple topics in Viem too: https://viem.sh/docs/actions/public/watchEvent.html#multiple-events

The caveat here is that you cannot scope by indexed arguments (JSON-RPC/topic design limitation).

Understand you are using watchContractEvent, maybe it could make sense to add support for multiple eventNames, but for now I guess you could just use the lower-level watchEvent.

[norswap]

Fantastic, thanks a lot for the help, I'll use that :)

[debuggingfuture]

come across this and thanks @jxom for the advice

so according to the docs even with watchFilter, we can't meaningfully use single filter to filter for both criteria (list of events, current gameId which is in args)

The caveat here is that you cannot scope by indexed arguments (JSON-RPC/topic design limitation).

I digged the implementation a bit, viem actually do apply the arg when creating the filter

at https://github.com/wevm/viem/blob/81ae35284e22164e8f8ac4d3b44f846b83f548f1/src/actions/public/watchEvent.ts#L195

which calls

https://github.com/wevm/viem/blob/81ae35284e22164e8f8ac4d3b44f846b83f548f1/src/actions/public/createEventFilter.ts#L194

but the catch is the arg in filter has to be consistent across events -- i.e. game id is the only thing we filter in all event, which is true for the current contract & use case

from what I see with this, it did end up using one eth_getFilterChanges rpc call for all events (as in the logs)

Let me know if we're good with this hack I can PR

[debuggingfuture]

@norswap btw will recommend do a simple rxjs wrapper for easier event filtering & async control, where it also integrates well with jotai from my understanding if we need that in future https://jotai.org/docs/utilities/async#atomwithobservable

[norswap]

Hey, if we could observe all events & filter on game ID upstream, that'd be swell!

If not, we can just listen to all events & filter in the frontend. Because it works via polling at the moment, this is still preferable to the current situation where we poll for every single events.

Regarding rxJS, I'd rather not introduce another dependency/framework if we can avoid it. I feel like it's not really needed here, we can just update the jotai store directly in the callback.

And yes, feel free to go for the issue!

On Fri, Feb 16, 2024, 02:48 debuggingfuture (Vincent LCY) < @.***> wrote:

@norswap https://github.com/norswap btw will recommend do a simple rxjs wrapper for easier event filtering & async control, where it also integrates well with jotai from my understanding if we need that in future https://jotai.org/docs/utilities/async#atomwithobservable

— Reply to this email directly, view it on GitHub https://github.com/0xFableOrg/0xFable/issues/91#issuecomment-1946941557, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABRLP3GBYZPCIR5RI5MDQLYTZKATAVCNFSM6AAAAABAYVX33OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBWHE2DCNJVG4 . You are receiving this because you were mentioned.Message ID: @.***>