tag:blogger.com,1999:blog-34454975.post150497766504525989..comments2023-06-28T16:58:41.189+02:00Comments on Web Reflection: On EventEmitter In node.jsAndrea Giammarchihttp://www.blogger.com/profile/16277820774810688474noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-34454975.post-18127790716213907222012-01-27T02:48:30.108+01:002012-01-27T02:48:30.108+01:00I agree that it is inconsistent with the browser, ...I agree that it is inconsistent with the browser, but that was never the intent in Node. EventEmitters vs EventTarget is a big gap in philosophy. One of them packs everything on a single object, one uses multiple arguments. One is used in situations where events may not be known before hand (a lot of the EventEmitter2 wildcard stuff comes to mind). Changing an EventEmitter to an EventTarget would be catastrophic for Node's idea of a single callback with error first argument, and you would go back to the nightmare of onsuccess/onfailure and manually checking if it met failure conditions in both. While both are used for event delegation, EventTarget also has the concept of bubbling/capturing/preventingDefault/etc., which event emitters do not. I would not try to reconcile this large gaps by forcing one of the two to act as the other.Bradleyhttps://www.blogger.com/profile/03062713177364563086noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-48926772079511764512012-01-18T09:21:40.662+01:002012-01-18T09:21:40.662+01:00I agree, the source code of EventEmitter is really...I agree, the source code of EventEmitter is really not top quality and other JS native modules too.<br /><br />I am thinking to rewrite the EventEmitter and leave the API as it is but at least make it better, quality speaking, smaller and hopefully faster.<br /><br />Still, this post was not about EventEmitter itself, rather about its API which is inconsistent in few places and not aligned with good old JS behaviorsAndrea Giammarchihttps://www.blogger.com/profile/16277820774810688474noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-8475763636956577142012-01-18T08:56:18.206+01:002012-01-18T08:56:18.206+01:00On github direct, I comented (few months) ago abou...On github direct, I comented (few months) ago about my surprise with node.js. Code inside is definitely *not* up to the standards of let's say jQuery.<br /><br />That was not received very well, to say at least. I tried to point out what's wrong, but those guys seem a bit touchy on the subject of the lack of quality javascript code inside node.js<br /><br />Which is unfortunate. Concept is good and product is good. But node.js, indeed looks like *not* top quality js code.DBJDBJhttps://www.blogger.com/profile/10255157102936852683noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-27214074366067824382012-01-16T20:06:23.698+01:002012-01-16T20:06:23.698+01:00a module that exports an EventEmitter could be use...a module that exports an EventEmitter could be used by other two modules that depends on another shared module too ... in this case <br /><br />require("stuff").event.addListener("connect", require("my net").debugConnection);<br /><br />could be already a case where you may have side effects if another module included in the script does the same.<br /><br />I program in a way that if I remove a listener I wanna be sure 100% that has been removed, not because I am the owner of the EventEmitter, because that's how it should be.<br /><br />Nobody does this to remove a listener in node.js, isn't it?<br /><br />em.listeners("type").filter(function (listener){<br /> return listener === nmsp.callback;<br />}).forEach(function (listener) {<br /> em.removeListener("type", listener);<br />});<br /><br />... I mean, what the hell is that? why is even possible to add sam listener to the same event type?<br /><br />It's not a case that in DOM world this has never been possible plus has never been needed, you know what I mean?Andrea Giammarchihttps://www.blogger.com/profile/16277820774810688474noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-86232513059071706392012-01-16T19:52:09.436+01:002012-01-16T19:52:09.436+01:00Can't say I agree the duplicate check is neede...Can't say I agree the duplicate check is needed. What kind of code do you write, that adds multiple event handlers by mistake? The code should be structured in a way that makes rreverting side effects just as easy, as commiting them.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-34454975.post-60260389600916036202012-01-16T18:30:11.863+01:002012-01-16T18:30:11.863+01:00thanks Chris, I'll have a look.
once() is the...thanks Chris, I'll have a look.<br /><br /><b>once()</b> is there already and it's the only thing, together with <i>on()</i> that I liked ... everything else should be more aligned with what we have since ever in client JS world ... I just don't like the non-DRY approach current EventEmitter tookAndrea Giammarchihttps://www.blogger.com/profile/16277820774810688474noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-28242522526456756832012-01-16T18:22:45.784+01:002012-01-16T18:22:45.784+01:00Take a look at EventEmitter2 (https://github.com/h...Take a look at EventEmitter2 (https://github.com/hij1nx/EventEmitter2). This project is abstracting a more feature-laden EventEmitter. Also, .once will allow an EventEmitter to be set and once it is executed, that particular event will be unregistered.Chris Harris (cnharris@gmail.com)noreply@blogger.com