-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
doc: update removeListener behaviour #5201
Conversation
This commit updates events doc to describe removeListener behaviour when it is called within a listener. An example is added to make it more evident. A test is also incuded to make this behaviour consistent in future releases. fixes nodejs#4759
not affect the current listener array. Subsequent events will behave as expected. | ||
|
||
```js | ||
const myEmitter = new MyEmitter(); |
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.
There is a PR in place that validates code blocks in the docs per eslint rules.
Could you please add
const EventEmitter = require('events');
class MyEmitter extends EventEmitter {}
const myEmitter = new MyEmitter();
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.
const EventEmitter = require('events');
class MyEmitter extends EventEmitter {}
This initialization has been done in the first example of events doc and from there on each example simply uses myEmitter . I was trying to be consistent with the existing doc.
As for the linting of code blocks in docs, I'll do that at once.
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.
Don't worry about the linting of other code blocks, only of the one you are adding in this PR.
Each code block is a separate file in linting world, so yes it was declared above, but to satisfy linting, it needs to be declared in this block as well.
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.
So,
const EventEmitter = require('events');
class MyEmitter extends EventEmitter {}
should be added only for the sake of linting that block and then removed before the commit. Or should that piece of code be pushed assuming linted docs would be adopted in the future.
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.
The latter, but hold up. @targos just made a comment about reducing the strictness of the linter.
I'd say ignore what I'm saying right now, if I get these changes landed I will fix this later.
@@ -83,3 +83,29 @@ e5.once('removeListener', common.mustCall(function(name, cb) { | |||
})); | |||
e5.removeListener('hello', listener1); | |||
assert.deepEqual([], e5.listeners('hello')); | |||
|
|||
var e6 = new events.EventEmitter(); |
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.
Please use const
here.
Add spaces before beginning of comments.
Improve code by replacing count variable to assert number of function calls with mustCall method from common module. Also use ES6 arrow function decalaration for anonymous functions.
@cjihrig Any more corrections ? |
Note that once an event has been emitted, all listeners attached to it at the | ||
time of emitting will be called in order. This implies that any `removeListener` | ||
call *after* emitting and *before* the last listener finishes execution will | ||
not affect the current listener array. Subsequent events will behave as expected. |
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.
Perhaps "will not affect the current listener array" is a bit misleading. To me it sounds like it's saying that listeners won't be removed at all, when in fact they actually are removed but it just doesn't affect the list of listeners used by emit()
. Maybe it could instead read something like:
Note that once an event has been emitted, all listeners attached to it at the
time of emitting will be called in order. Any calls to `removeListener()` or
`removeAllListeners()` for this event will not affect the `emit()` in progress.
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.
@mscdex I agree the statement is misleading because the internal array is cloned at the time of emit and listeners are executed from this cloned array. Meanwhile removeListener removes from the internal array. Was not quiet able to put that in words suitable for a doc. Your's definitely looks better.
Correct print order for removeListener test.
|
||
const e6 = new events.EventEmitter(); | ||
|
||
var listener3 = common.mustCall(() => { |
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.
These var
s can now be const
s.
Previous commit was misleading by saying that internal array is not modified by removeListener or removeAllListeners call. Now worded appropriately.
LGTM |
1 similar comment
LGTM |
This commit updates events doc to describe removeListener behaviour when it is called within a listener. An example is added to make it more evident. A test is also incuded to make this behaviour consistent in future releases. Fixes: #4759 PR-URL: #5201 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
CI passed. Landed in f2bd9cd Thanks for the contribution @vaibhav93 :) - I took the liberty of editing your commit message a bit - note the structure of the commit message and the fact the commits were squished into a single commit for future contributions. |
This commit updates events doc to describe removeListener behaviour when it is called within a listener. An example is added to make it more evident. A test is also incuded to make this behaviour consistent in future releases. Fixes: #4759 PR-URL: #5201 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
This commit updates events doc to describe removeListener behaviour when it is called within a listener. An example is added to make it more evident. A test is also incuded to make this behaviour consistent in future releases. Fixes: #4759 PR-URL: #5201 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
This commit updates events doc to describe removeListener behaviour when it is called within a listener. An example is added to make it more evident. A test is also incuded to make this behaviour consistent in future releases. Fixes: #4759 PR-URL: #5201 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
This commit updates events doc to describe removeListener behaviour when it is called within a listener. An example is added to make it more evident. A test is also incuded to make this behaviour consistent in future releases. Fixes: #4759 PR-URL: #5201 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Guys, but how to remove listeners during notifying subscribers? |
it would be nice to understand this design |
This commit updates events doc to describe removeListener behaviour
when it is called within a listener. An example is added to make it
more evident.
A test is also incuded to make this behaviour consistent in future
releases.
ref #4764
fixes #4759
@cjihrig @jasnell