feat: support nested event methods - #5
Conversation
bbaldino
left a comment
There was a problem hiding this comment.
couple minor comments. can you add a section to the README about this as well?
| { | ||
| eventOne: TypedEvent<(value: number) => void>; | ||
| eventTwo: TypedEvent<(value: boolean) => void>; | ||
| } |
There was a problem hiding this comment.
nit: for consistency, can you extract these out into an interface like the test above does? with them matching it makes it easier to see that what's different here is the path argument.
There was a problem hiding this comment.
Sure thing. Done.
| // Even though we bypass type safety in the call (casting this as any), we've enforced it in the | ||
| // method signature above, so it's still safe. |
There was a problem hiding this comment.
This comment looks like it isn't really relevant here anymore...maybe better as a note on getEvent?
There was a problem hiding this comment.
Good catch. Done.
|
@bbaldino Thanks for the feedback. I fixed the tests to be more consistent, moved the stale comment into the comment |
This PR adds an optional path parameter to the
AddEventsutility, enabling the specification of nested event locations within objects. The addition of thegetEventclosure function allows for retrieving events based on this optional path, and an error is thrown if the event is not found.A successful example:
An error example: