-
Notifications
You must be signed in to change notification settings - Fork 508
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
Add a CONNECT event to informer. #614
Merged
Merged
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm. This makes it a breaking change? It also has the error at the end, which may be unintuitive to folks used to Node's error-first callbacks... But moving the error first would be even more breaking...
Not sure what's the best approach here... Not saying this shouldn't got ahead, it's easy enough to adapt as a user of the library, but still.
Would be a travesty in TypeScript world to allow
on()
to have overloads to accept different parameter types? i.e. allowon(verb: string, fn: ObjectCallback<T>): void;
as well ason(verb: string, fn: ErrorCallback): void;
? While it wouldn't enforce the correct callback type based on theverb
, it would at least be non-breaking? Not sure if there's a better way to express this in TS...There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did also try it that way:
on(verb: string, fn: ObjectCallback<T> | ErrorCallback | ConnectCallback)
But I felt like that was even messier, because suddenly the user can accidentally pass a
ConnectCallback
to aon('add', ...)
Maybe we could do:
wdyt? That has the benefit of not being a breaking change, and also adding in the more node-style callbacks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although, I'm not actually sure that TS can handle that since those two callback types may be indistinguishable...I made the types more concrete so I think TS can handle it based on the # of parameters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would TS handle that at runtime or just compile time?
Did TS ever get enums? If the first param for
on()
was enum, rather than astring
, then it could have multiple signatures based on enum type... Which would probably still be a breaking change from TS perspective, but possibly the oldstring
signature could still be there, just withany
callback so that people can upgrade their code eventually, even if they would lose out a little bit in terms of potentially accidentally passing the wrong callback?Also I wonder if passing the wrong callback is even a problem for people using TS, because surely someone must have noticed by now that the callback for the
error
event is not right? i.e. this could mean that making changes here is not that disruptive, even if the changes are breaking when looking at it strictly?This is a common pattern (
on()
with different callbacks for different event types) - surely someone must have solved this by now? This is used in node itself (in streams and elsewhere): https://github.com/DefinitelyTyped/DefinitelyTyped/blob/1d52dcdeea0c4006bb63c28ff60b919f3f5fc3a6/types/node/stream.d.ts#L84-L91 🤔There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
was there a follow-up on this @brendandburns ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the pointer! I fixed this using type overloading.