-
Notifications
You must be signed in to change notification settings - Fork 365
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
Comments
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;
}; |
Hey @Nekonaughey, can you try using ethers v5? The new target is currently on beta (#250) |
I’ve tried the new |
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. |
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? |
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 |
The second one is definitely useful in most cases, but I remember that I preferred The ethers 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); |
Is there any progress on this issue? Would like to know how I could potentially contribute. Event typing is pretty important. |
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) |
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
Output Result
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 }]
The text was updated successfully, but these errors were encountered: