Feature: fetch events by block

[dkent600]

There is a request to get/watch for Arc-related events as each block is generated, returning the found set of events in the order in which they were fired in each block.

Should look similar to the current EventFetcher or EntityFetcher interfaces.

[dkent600]

@tibetsprague Can you please comment on more specific details of this request? For example:

• ability to specify an event filter
• would there be a default set of events?
• exactly which events would be desired? What about events that aren't technically fired by Arc contracts, like token events that come from zeppelin?
• anything else?

[dkent600]

New event subscription system in arc.js

[tibetsprague]

Let’s have a bigger discussion about this next week. Tuesday?

[orenyodfat]

👍🏽

…

On Sat, 28 Jul 2018 at 15:25 Doug Kent ***@***.***> wrote: @tibetsprague <https://github.com/tibetsprague> This could perhaps be used to handle in a single fetcher the GP and CR events that are triggered by the Redeemer contract. @orenyodfat <https://github.com/orenyodfat> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <daostack/arc.js#298 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFt3noCSK4rRKgA6g4-kOJGlTSGPIViyks5uLFgegaJpZM4Vj912> .

[orenyodfat]

fetch events by block can be done by web3 .
are you referring to a more sophisticate wrapper which could aggregate multiple event sources to one output?

[dkent600]

@orenyodfat

fetch events by block can be done by web3 .

That functionality does not allow one to go back in time, only to watch going forward

are you referring to a more sophisticate wrapper which could aggregate multiple event sources to one output?

yes

[dkent600]

@orenyodfat @tibetsprague @dev-matan-tsuberi

I want to put together an API that, to the extent feasible, looks like the existing EventFetcher system in Arc.js, which itself looks a lot like truffle's and web3's event filtering API. All-around consistency lowers the learning curve for both Arc.js and application developers, decreases the likelihood of bugs and increases the chances for code reuse.

Refer here to information about the Arc.js event API: https://daostack.github.io/arc.js/Events/

So the code might look something like as follows.

First get the EventFetcherFactory, specifying the contract events we want to aggregate, and that we want to filter the GenesisProtocol.Redeem event by _proposalId:

const aggregateEventService = new AggregateEventService();

const fetcherFactory = aggregateEventService.createEventAggregatorFetcher(
[
  {
    contract: WrapperService.wrappers.GenesisProtocol,
    eventName: "Redeem",
    eventArgsFilter: { _proposalId: "0x..."  }
  },
  {
    contract: WrapperService.wrappers.ContributionReward,
    eventName: "Redeem"
  }
]);

Now get an EventFetcher, specifying blocks between someBlockNum and latest, filtering all events by _avatar.

const fetcher = fetcherFactory({ _avatar: "0x..."}, { fromBlock: someBlockNum });

Now get the events that fall within the filter we specified, the easy way that doesn't
require that we supply a callback, though we could if we wanted:

const events = await fetcher.get();

/**
  * `aggregatedEvent` contains the transaction receipt and a Map of event log 
  * entries keyed by what you passed to
  * `aggregateEventService.createEventAggregatorFetcher` above
  */
events.forEach((aggregatedEvent) => { 

  // enumerate keys and values together for demo purposes
  aggregatedEvent.events.entries.forEach((keyValuePair) {

    const eventInfo = keyValuePair[0]; 
    /**
      * eventInfo is what you passed into `aggregateEventService.createEventAggregatorFetcher`
      */
    console.log(`Contract: ${eventInfo.contract.name}, event: ${eventInfo.eventName}`); 
    // output: "Contract: GenesisProtocol, event: Redeem"

    /**
      * get the event args for GenesisProtocol.Redeem, just like they would look from web3
      */
    const args = keyValuePair[1]; 
    console.log(`event args: ${args}`); 
  }
});

See this code in Redeemer for why the Map can be useful: https://github.com/daostack/arc.js/blob/b050e67650d53a87d4778e04d7766099446f8d3a/lib/wrappers/redeemer.ts#L104

Events on different contracts may have the same names.

Start up a watch using the same EventFetcher as in the get example above, this time
passing a calback and a value of 8 for the optional block depth:

fetcher.watch((aggregatedEvent, 8) => {
  ... same code as in the loop above
});

and later:

fetcher.stopWatching();

Subscribe to a PubSub event. This will setup a watch, again using the same EventFetcher as above:

const subscription = await fetcher.subscribe(
  "anyEventNameYouWant",
  (topic: string, aggregatedEvent) => {
  ... same code as in the loops above
});

and later:

subscription.unsubscribe();

[orenyodfat]

@dkent600 re "That functionality does not allow one to go back in time, only to watch going forward" you can get past events also using web3

[orenyodfat]

re the api :
How about make it simpler api ?
something like :
arc.js.subscribesToEvents(contractsAddressesList,EventsNameList,fromBlock,toBlock,callback)
The callback will be called back once there is an event in the blocks range return the the event with all its info.
If there are more than one events from any of the contractsAddressesList and EventsNameList in the same block the callback will be called back with the lists of the events.

[dkent600]

you can get past events also using web3

Yes, that is what the current implementation is doing

[dkent600]

@orenyodfat

How about make it simpler api ?

Because of what I described above:

All-around consistency lowers the learning curve for both Arc.js and application developers, decreases the likelihood of bugs and increases the chances for code reuse.

I'll add a further reason: At any point we may want to add dependency injection to Arc.js. Dependency injection vastly improves the story of module dependency management (which is already presenting challenges in terms of circular dependencies), and with writing clean, well-structured automated test code. Dependency injection works best with code that is well modularized, which includes the use of interfaces, factory classes and services.

In general I have endeavored to structure the code in Arc.js in such as way as to readily lend itself to adopting the dependency injection pattern, including the pattern for handling events that is represented in the proposal given in this ticket.

The proposed API is not so complicated, and is identical to other APIs in Arc.js and so will be familiar to developers, with little learning curve.

[orenyodfat]

Thanks @dkent600 .
which function the client need to call to get these events ? It suppose to be simple