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.
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
Broadcasting of requested resolution #8
Broadcasting of requested resolution #8
Changes from 4 commits
855d61a
ef5d5aa
a34aa8a
ef95d1b
b1da3ed
4a06271
9abeb51
7b9bf35
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 making this change, but this now brings up another issue for me...
By calling
onError
in the way you are now, you are making it a blocking call - as in the app'sonError
implementation must finish executing (return) before this "method" can return.My expectation would be that a less surprising result for app developers would be for you to delay the call to
onError
until after this method has returned. I believe that can be accomplished using setTimeout.Are there any other locations within this codebase where we have methods that accept callback functions and end up calling them synchronously, as I would imagine those should change too (assuming you agree with me).
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.
Sounds reasonable to me - I've fixed this and other instances where we call user provided callbacks in b1da3ed.
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.
What does ably-js do? (cc @SimonWoolf )
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.
ably-js does appear to call callbacks synchronously in some error cases. I agree it wouldn't be a bad idea to chuck in a setImmediate for those. But no-one's complained yet so probably not a huge deal in practice
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.
@SimonWoolf My question was more in relation to the other issue, which is what do we think is the appropriate best practice for
setTimeout/setImmediate/nextTick
, and how to make it portable?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.
ably-js has Utils.nextTick which does
setTimeout(f, 0)
on browsers (which is what owen's done here) andprocess.nextTick
in node.AIUI node's
setImmediate
is basically just an alias forsetTimeout(f, 0)
, ie adds it as a timer action in the next eventloop. Vsprocess.nextTick
which despite the name requeues the action in the current event loop at the end of the queue. For delaying a callback, 'end of current event' loop is arguably semantically neater, but there's no way to do that in browsers afaik, and for that purpose isn't going to make a difference.(for batch methods that want to move things to the next event loop the difference starts to matter - nextTick is not sufficient, as we've discovered - but that's not relevant to this)
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.
Take a brief look around the place in terms of TypeScript
enum
definitions, some places seem to prefer CamelCase. Equally I would have expected this to be picked up by the linter and/or prettier if it's non-standard and that doesn't seem to be the case. Is there a convention we're aligning with here?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 am aware that camelCase is often used for enums but I'm aligning with the TypeScript documentation which to me feels more like the right thing to do.
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.
Were you going to address this comment in the scope of this PR? It felt like you said you might elsewhere.
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.
Sorry, forgot to do that - done now in 9abeb51.