|Reported by:||koopersmith||Owned by:||koopersmith|
|Component:||General||Keywords:||2nd-opinion has-patch dev-feedback|
I think that a good events API should satisfy these parameters:
- Support jQuery-style dot namespacing to allow functions to be easily removed.
- Should (likely) support priorities. While seemingly random numbers aren't fun to use, it allows plugins to cooperate without having to know of each other's existence. We can't expect plugin authors to rearrange the array of callbacks.
- Should be structured as a mixin. The global event loop should be an instance of the core Events object. Using a mixin will allow developers to easily create event loops for their own plugins (to prevent polluting the global namespace — think about large plugins, like bbPress). An events mixin will also enable developers to create more powerful abstractions, such as observable values, collections, and pretty much any structural JS object you can dream up.
- Should allow the looping process to be overwritten. This will result in less code and added flexibility. The only difference between actions and filters is how they handle the callbacks object. There are other types of looping processes that could be beneficial in JS. One example would be returning false if any callback returns false, which could be used to stop a process, much like the native event.stopPropagation method.
Why not use custom jQuery events?
Custom jQuery events are great when we need to trigger actions on a DOM element. Triggering plain events on the body element (or any other hidden element) is not performant — every jQuery event normalizes an DOM Event object, which we then completely ignore.
Should we require jQuery to use the API?
I'm not sure. jQuery.Callbacks may be a helpful solution here, provided we can properly integrate priorities and namespacing. jQuery.Callbacks also only requires jQuery.each and jQuery.extend, so writing a shim that doesn't use the rest of jQuery would not be exceptionally difficult. Either way, switching between one and the other as we develop should not be exceptionally difficult.
Change History (99)
comment:30 in reply to: ↑ 29 ; follow-up: ↓ 31 @carldanley — 3 years ago
comment:32 in reply to: ↑ 31 ; follow-up: ↓ 33 @carldanley — 3 years ago
comment:37 follow-up: ↓ 42 @CaptainN — 3 years ago
comment:44 @nacin — 3 years ago
- Milestone changed from 3.5 to Future Release
- Type changed from task (blessed) to feature request