4 ms·
Great, let's write one EventEmitter and make everyone else use that. What? The problem is different - there is no single package manager in the browser world t
by majke 14y ago
Great, let's write one EventEmitter and make everyone else use that. What?
The problem is different - there is no single package manager in the browser world that has taken off.
BTW. In the browser the native and well documented way of dealing with callbacks is by using the EventTarget API:
http://www.w3.org/TR/DOM-Level-2-Events/events#Events-EventTarget http://www.w3.org/TR/DOM-Level-2-Events/events#Events-EventT...
- MatthewPhillips 14y agoUnfortunately they decided not to expose EventTarget as an object, hence where we are today.
- deno 14y ago> BTW. In the browser the native and well documented way of dealing with callbacks is by using the EventTarget API Closure Library uses EventTarget for their event handling system[1], thus making it work exactly the same for browser events and custom events. YUI 3 takes similar approach, but instead they use their own API, however also based on DOM events model. [1] https://closure-library.googlecode.com/svn/docs/class_goog_events_EventTarget.html https://closure-library.googlecode.com/svn/docs/class_goog_e...
- ricardobeat 14y agoYou mean they implement their own event emitter following the EventTarget spec :)
- deno 14y agoI meant to write EventTarget API. Yep. However, the implication is that it’s based on the DOM event model. So, for example, you have three stage processing: 1) capture phase, 2) target phase, and 3) bubble phase. YUI 3 has its own API, but they still follow that model. This is a bit stronger contract than just your generic ‘EventEmitter,’ which only implies a simple observer model.