-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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, test: Symbols as event names #4151
Conversation
const foo = Symbol('foo'); | ||
let didRun = false; | ||
|
||
function listener() { |
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.
You can wrap this in common.mustCall()
, then you don't need didRun
.
LGTM with a few comments. |
Tests aren't happy:
@bengl could you please be sure to run |
@@ -0,0 +1,27 @@ | |||
'use strict'; | |||
|
|||
require('common'); |
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 think this needs to be '../common'
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.
This should be require('../common');
638e599
to
f0f0484
Compare
Fixed the |
@@ -10,7 +10,8 @@ is opened. All objects which emit events are instances of `events.EventEmitter`. | |||
You can access this module by doing: `require("events");` | |||
|
|||
Typically, event names are represented by a camel-cased string, however, | |||
there aren't any strict restrictions on that, as any string will be accepted. | |||
there aren't any strict restrictions on that, as any string or symbol will be | |||
accepted. |
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.
Hmm.. is this actually something we want to promote? I know it works but should it. /cc @nodejs/ctc
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.
It's not documented, but you can emit on objects as well.
const EE = require('events');
const e = new EE();
const b = { foo: 42 };
e.on(b, function() { console.log('hi'); });
e.emit(b);
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.
@trevnorris Sort of. Because b
coerces to [object Object]
, emitting on any object will fire the same event as b
.
const EE = require('events');
const e = new EE();
e.on({ foo: 42 }, function() { console.log('hi'); });
e.emit({ bar: 43 }); // hi
e.emit({ baz: 44 }); // hi
Symbols don't get coerced for property identifiers though, so they're distinct here I think.
const EE = require('events');
const e = new EE();
const a = Symbol('foo');
e.on(a, function() { console.log('hi'); });
e.emit(Symbol('foo')); // no hi
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.
hah. nice. never bothered to test that thoroughly.
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 "any valid property key" is the most correct thing to put here? That encompasses everything that's actually supported and doesn't encourage or discourage the use of Symbols.
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.
That may be better. I'm wondering too if we shouldn't simply throw if it's anything other than a "valid property key". Passing in an object simply doesn't make sense. Either way tho, this LGTM. Thanks!
👍 I like the idea of promoting symbol keys because it allows for private events on emitters. |
@Qard Not really "private". Can still be just as easily accessed via |
Yeah, private-ish. There's always some escape hatch, isn't there? 😉 |
Alright I replaced "any string or symbol" with "any valid property key". |
LGTM |
@cjihrig .. does this still LGTY? |
Yes, but I'd still like to see the additional assertion that I originally requested. |
Yes, thank you! LGTM |
* Document that Symbol can used as event names. * Add test for using Symbol as event names PR-URL: #4151 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
Landed in 7a51878 |
* Document that Symbol can used as event names. * Add test for using Symbol as event names PR-URL: #4151 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
* Document that Symbol can used as event names. * Add test for using Symbol as event names PR-URL: #4151 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
* Document that Symbol can used as event names. * Add test for using Symbol as event names PR-URL: #4151 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
* Document that Symbol can used as event names. * Add test for using Symbol as event names PR-URL: nodejs#4151 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
As a result of the new support for Symbols in V8, along with the implementation of EventEmitter in Node, it turns out that Symbols are usable as event names. This adds the possibility of Symbol event names to the docs, and adds an EventEmitter test specific to Symbols so as to ensure that this doesn't break due to any potential future alternative implementations.