[wp-trac] [WordPress Trac] #21170: JavaScript actions and filters

[WordPress Trac]

#21170: JavaScript actions and filters
-----------------------------+-----------------------------
 Reporter:  koopersmith      |       Owner:  koopersmith
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Future Release
Component:  General          |     Version:  3.4
 Severity:  normal           |  Resolution:
 Keywords:  2nd-opinion      |
-----------------------------+-----------------------------

Comment (by gcorne):

 I am just now trying to get caught up with all the thinking that has gone
 into this. And, I still need to spend some time looking at and playing
 around with the fine work that Carl has done (Yay, for unit tests!). Here
 are few initial thoughts:

 * In the javascript land, we should probably consider garbage collection.
 In cases where we are dealing with short-lived “view” code that has
 references to DOM nodes,  it would be nice if subscribers could easily
 clean up references to the event bus. This is the reason that Backbone
 added the {{{listenTo}}} and {{{stopListening}}} methods to
 {{{Backbone.Events}}} which is mixed in to all the other Backbone
 constructors.
 * I think we would want to support a context parameter so that when
 binding a callback the subscriber code can control what {{{this}}} refers
 to in the callback. We also need to consider how to best handle context on
 the publisher side. Do we want to support an arbitrary set of parameters
 that are then passed to the subscriber callback like the PHP plugin API
 supports?
 * I am not super up on benchmarks for the jQuery event system vs. others,
 but one thing that I don’t like about jQuery is that it is hard to inspect
 the catalog of registered subscribers to events. I think that it should be
 pretty easy to look at the data structure holding all the event bindings.
 * If we are going to create a dependency, I think it might be best for the
 dependency to be on underscore.js, which is only 4.7k compressed and
 includes lots of useful stuff for building a robust event/filter system.
 * Building on the idea of using underscore, we should build the core
 library so that it can be used under a separate namespace, so a core
 feature or a plugin could do something like:

 {{{
 wp.plugins.myAwesomePlugin.hooks = _.extend( {}, wp.Events );
 }}}

 * In terms of style, I am not 100% sure how close it needs to match the
 PHP API, especially as the role of “front-end engineer” and the role’s
 heavy javascript skill set becomes more commonplace.
 * Has anyone looked through core for places that are good candidates for
 adding some hooks? It might be worth considering some specific use cases.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/21170#comment:84>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform