Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding event type for ethers #249

Closed
Nekonaughey opened this issue Jun 15, 2020 · 9 comments · Fixed by #321
Closed

Adding event type for ethers #249

Nekonaughey opened this issue Jun 15, 2020 · 9 comments · Fixed by #321

Comments

@Nekonaughey
Copy link

Hello!

Thanks for the great project!

It seems that typechain does not output the event type when it is generated by specifying ethers-v4 as the target.
This is inconvenient because I don't know the type when implementing the event handler.

Sample Code

pragma solidity ^0.6.4;
pragma experimental ABIEncoderV2;
contract Test {
  event TestEvent(address sender, string message);
  function test() public {
    emit TestEvent(msg.sender, 'test Message!');
  }
}

Output Result

interface TestInterface extends Interface {
  events: {
    TestEvent: TypedEventDescription<{
      encodeTopics([sender, message]: [null, null]): string[];  **// type is null**
    }>;
  };
}

export class Test extends Contract {
  filters: {
    TestEvent(sender: null, message: null): EventFilter;  **// type is null**
  };
}

Expected Behavior
It would be helpful if you could output something like the following
export type TestEvent = [string, string]

If struct type is used...
export type TestEvent = [string, { id: string, name: string }]

@Nekonaughey
Copy link
Author

Nekonaughey commented Jun 15, 2020

If I specify the target as web3, event types seems to be output.

export type TestEvent = ContractEventLog<{ // type exported
  sender: string;
  message: string;
  0: string;
  1: string;
}>;

export interface Test extends BaseContract {
  events: {
    TestEvent(cb?: Callback<TestEvent>): EventEmitter;  // type is specified
    TestEvent(options?: EventOptions, cb?: Callback<TestEvent>): EventEmitter;

    allEvents(options?: EventOptions, cb?: Callback<EventLog>): EventEmitter;
  };

@zemse
Copy link
Contributor

zemse commented Jun 28, 2020

Hey @Nekonaughey, can you try using ethers v5? The new target is currently on beta (#250)

@geigerzaehler
Copy link

I’ve tried the new ethers-v5 target and no event types are generated. It would be great if the target would support it.

@zemse
Copy link
Contributor

zemse commented Aug 10, 2020

ATM the events in ethers v5 go like this:

const filter = contractInstance.filters.Transfer('0x000000000', null, null); // current target supports inputs to this
const logs = await contractInstance.queryFilter(filter);
const parsedLogs = logs.map((log) => contractInstance.interface.parseLog(log)); // this is where we need typings

// then
const events = parsedLogs as {args: {from: string, to: string, value: BigNumber}}[]

I would be very much helpful, since currently I have to manually do this :(

@krzkaczor Can you suggest any way in which this is acheivable? I'd love to get this supported in automated mode instead of my manual additions of typings to events.

@krzkaczor
Copy link
Member

krzkaczor commented Aug 16, 2020

@Nekonaughey

If I specify the target as web3, event types seems to be output.

yeah, web3 target was written with this in mind. I guess this wasn't migrated to ethers target.

@zemse I think the question is: should we simply extra current types to a named type like:

export type TestEvent = [string, string]

or we should create interfaces as you suggested ie:

interface SomeEvent {
from: string, 
to: string, 
value: BigNumber
}

I think latter will be more useful but I am not sure which case is more common... Can you chip in folks?

@geigerzaehler
Copy link

I’d prefer the latter approach with named event parameters. Since events are only consumed by users of the bindings it will be a lot less error-prone to do event.from compared to event[0].

@zemse
Copy link
Contributor

zemse commented Aug 17, 2020

The second one is definitely useful in most cases, but I remember that I preferred event[0] in one situation (I don't remember exactly) but maybe the order was more obvious to me than random parameter naming of event args by some dev, since that is not standardised. For example value, amount, tokens used as param name for event[2] of ERC20 Transfer event in various ABIs.

The ethers args object in parsedLog contains both event[0] as well as event.from.

interface SomeEvent {
  from: string, 
  to: string, 
  value: BigNumber,
  0: string,
  1: string,
  2: BigNumber
}

Though it doesn't look compact, it should make devs in both situations happy.

Also as a matter of fact, events can be without param names.

event A(address, uint256);

@adrianmcli
Copy link

adrianmcli commented Jan 11, 2021

Is there any progress on this issue? Would like to know how I could potentially contribute. Event typing is pretty important.

@zemse
Copy link
Contributor

zemse commented Jan 11, 2021

I haven't got to make any progress on this. I can do this next week or else if you'd like to do then you can have a look at this #303 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants