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

[WordPress Trac]

#21170: JavaScript actions and filters
-----------------------------+-------------------------
 Reporter:  koopersmith      |       Owner:
     Type:  feature request  |      Status:  assigned
 Priority:  normal           |   Milestone:  4.9
Component:  General          |     Version:  3.4
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:  javascript
-----------------------------+-------------------------

Comment (by westonruter):

 Replying to [comment:179 adamsilverstein]:
 > What other advantages do you imagine object extension vs the current
 approach would offer?

 The main benefits I see of a `wp.Hooks` mixin over a `wp.hooks` global
 are:

 1. Hooks are registered and deregistered along with the component they are
 modifying, reducing the amount of hooks in a global registry and
 eliminating the need to namespace hooks at all.
 2. Extending objects with an `wp.Hooks` interface is very much in line
 with out JavaScript projects add eventing, such as as
 [https://github.com/medikoo/event-emitter#event-emitter event-emitter] and
 [http://backbonejs.org/#Events Backbone Events] and even
 `wp.customize.Events` in the Customizer for that matter. Alternatively to
 using object extending, this would work just as well with composition so
 you could do something like `component.hooks = new wp.Hooks()` and have
 `component.hooks.addFilter(…)` as opposed to `_.extend( component,
 wp.Hooks )` and `component.addFilter(…)`. Having a single global
 `wp.hooks` now feels like an anti-pattern in the age of packages and
 modules, whereas including an instance of `wp.Hooks` in each component
 feels very much in-line with standard practice in JS.
 3. There may be some performance benefits to reducing the size of the
 hook/handler hash, since there would be fewer entries to look for if the
 hooks are encapsulated in a specific object.
 4. Also, as I said before when hooks are encapsulated then there are more
 opportunities for automatic hook handler garbage collection since there
 would at least be an opportunity for an object extended with `wp.Hooks` to
 go out of scope, whereas a global `wp.hooks` would never go out of scope.
 5. Also, when registering hooks on objects instead of globally, there is
 the added benefit that when hooks are run, that the object itself could be
 supplied as `this` context for each handler. That could be handy.

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