Expose raw events / make filter blocks adjustable

[sakulstra]

Hello, i'm trying to migrate a codebase to viem and having some issues.

With typechain you can use contract.filters.Transfer() and similar to get a generic filter which you can then pass to e.g. queryFilter as contract.queryFilter(event, fromBlock, toBlock).
This is quite useful as often rpcs(even paid ones) have block range restrictions, so to get all the events you can write some generic iteration like e.g.

export async function getPastLogs(
  fromBlock: number,
  toBlock: number,
  event: EventFilter,
  contract: Contract
): Promise<Event[]> {
  if (fromBlock <= toBlock) {
    try {
      return await contract.queryFilter(event, fromBlock, toBlock)
    } catch (error) {
      const midBlock = (fromBlock + toBlock) >> 1
      const arr1 = await getPastLogs(fromBlock, midBlock, event, contract)
      const arr2 = await getPastLogs(midBlock + 1, toBlock, event, contract)
      return [...arr1, ...arr2]
    }
  }
  return []
}

In viem as I understand the docs there are two ways to query the events log:

using getFilterLogs

const filter = await contract.createEventFilter.Transfer(
    {},
    { fromBlock: x, toBlock: y }
)
await publicClient.getFilterLogs({ filter })

createEventFilter mangles the from/to block into the id, and doesn't expose a getter or setter for the blockRange so it's not well suited for generic iteration. I don't understand why the blocks are passed to id creation - probably sth caching related. Anyhow imo would go good to make the blocks manipulatable.

Generally design wise seems quite unintentional to me, that the block configuration is on the createEventFilter, not the getFilterLogs

using getLogs

const logs = await publicClient.getLogs({  
  address: '0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266',
  event: parseAbiItem('event Transfer(address indexed, address indexed, uint256)'),
  args: {
    from: '0xd8da6bf26964af9d7eed9e03e53415d37aa96045',
    to: '0xa5cc3c03994db5b0d9a5eedd10cabab0813678ac'
  },
  fromBlock: 16330000n,
  toBlock: 16330050n
})

using getLogs kinda works but you're losing the typing & autocomplete on the event. It's weird that i have to manually generate the signature as the information is already available in contract.createEventFilter.Transfer.

Therefore I'm wondering if it would make sense to expose an contract.events.<Transfer> which can be used in combination with getLogs.

related: #260

[kdembler]

getLogs should work fine with typescript information. You also don't need to provide the signature again, you can extract it from your ABI:

publicClient.getLogs({
  address: CONTRACT_ADDRESS,
  event: getAbiItem({
    abi: CONTRACT_ABI,
    name: 'MyEvent',
  }),
  args: {
    typedArg: 'something',
  },
  fromBlock: 0n,
}),

[sakulstra]

That doesn't really solve my problem though.
With ethers i have the capability to pass down a filter to a generic function to solve pagination/error handling etc in a concise way (like with getPastLogs).

With viem i don't.
Ofc i can by passing event and args but it would feel much more natural to pass the filter and only alter the block.

[jxom]

You can do the same pattern with createContractEventFilter & getFilterLogs in getPastLogs, no?

createEventFilter mangles the from/to block into the id

That's correct, because you can also specify an optional block range to vanilla eth_newFilter RPC calls, so I wouldn't say it's "mangled". Internally, ethers implicitly also does this in the queryFilter fn. FWIW, ethers.js' EventFilter type isn't really aligned with traditional execution client filters, it just defers its args to the eth_getLogs RPC call (within queryFilter).

[sakulstra]

That's essentially what i'm doing right now.

Thx for clarifying the internals, i was not actually aware. I assume that is why ethers contract.filters.Transfer() is synchronous as it's delaying id creation to the filter execution, while on viem it's done immediately. That kinda makes sense 👍

My point for raising this feature request though is that they feel like workarounds compared to ethers.
The implicit deferring at least in my eyes is an ux improvement.

Would it be an option to support both paths in viem?
E.g. as an a separate createDeferredEventFilter(args) => ({ fromBlock: x, toBlock: y }) => createEventFilter(args) ... actually thinking about this, i can do this in userland as well.

Alternatively a non deferred but mutable option could be to alter the CreateEventFilterReturnType to return:

return {
    abi: event ? [event] : undefined,
    args,
    eventName: event ? (event as AbiEvent).name : undefined,
    id,
    request: getRequest(id),
    type: 'event',
+   setOptions(newOptions) => createEventFilter(args, {...oldOptions, ...newOptions}),
  } as unknown as CreateEventFilterReturnType<
    TAbiEvent,
    _Abi,
    _EventName,
    _Args
  >

[jxom]

It'll probably be better to maybe add a getLogs to the contract instance instead so you can just do:

await contract.getLogs.Approval({
  fromBlock,
  toBlock
})

instead of using filters.

I can take a look at adding it in when I find some time.

[sakulstra]

That would be great

[sakulstra]

using viem a bit more, two other things that could be handy is contract exposing contract.address and contract.abi.

[tmm]

Would accept a PR for this! (Someone brought up contract.address before).