id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc,focuses
21170,JavaScript actions and filters,koopersmith,adamsilverstein,"The concept of adding JavaScript actions and filters has been tossed around for some time. We've experimented with various configurations of actions in both the fullscreen and customizer APIs, and they've proven their utility enough to graduate them to a core feature in their own right.
----
I think that a good events API should satisfy these parameters:
1. '''Support jQuery-style dot namespacing''' to allow functions to be easily removed.
2. '''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.
3. '''Should ''not'' force functions to have unique IDs.''' Anonymous functions are extremely common in JavaScript — forcing them to be named is contrary to the nature of the language.
4. '''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.
5. '''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.",feature request,assigned,normal,5.0,General,3.4,normal,,,,javascript