Events support

[austinabell]

Would be useful as a developer to be able to filter out events that happened in the logs of the transaction's receipt execution.

This API could have a similar API to the ones around retrieving logs, except that instead of returning a Vec<&str>, it would return a Vec<Event> which would be some subset of the logs.

The event type can be something generally usable, but we could also consider having this typed to be more strict about what events are expected or even filtered.

Also somewhat opinionated if this should be included at all, so we can use this issue for discussion.

standard: https://github.com/near/NEPs/blob/master/neps/nep-0297.md
related SDK PR: near/near-sdk-rs#934
Also could look into how indexers are picking up the events currently, as that is the main use case (but they might handle FT/NFT events specifically)

[ghost]

@frol I'd like to take a stab at this. Are we still looking to implementing this?

[ghost]

@austinabell I looked into how near-lake-framework picks up the events from the rpc responses fields and parses them.
https://github.com/near/near-lake-framework-rs/blob/049b0e31018797b6a143767d3848e31fec7e262e/lake-primitives/src/types/events.rs#L60-L68

The event type can be something generally usable, but we could also consider having this typed to be more strict about what events are expected or even filtered.

Also somewhat opinionated if this should be included at all, so we can use this issue for discussion.

AFAICT, the RawEvent/Event type would better serve in some place like near-primitives to reduce copies that might be in the wild like in near-lake-framework.

[frol]

AFAICT, the RawEvent/Event type would better serve in some place like near-primitives to reduce copies that might be in the wild like in near-lake-framework.

@shariffdev I agree that we should make those reusable, but I think those structs should not be part of near-primitives since those are nearcore primitives (the protocol level primitives), and here we have a convention / recommendation. near-sdk-rs emits those events and near-sdk-rs does not need to parse events, but other apps needs to parse the events. I feel it should be part of a bigger revamp of near-contract-standards, which in my opinion needs to be split into small independent components/crates, and as such events helpers could be just a small crate instead of naming multiple implementations of various bits allover the places (https://github.com/near/near-sdk-rs/blob/master/near-contract-standards/src/event.rs)