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

[WordPress Trac]

#21170: JavaScript actions and filters
-----------------------------+------------------------------
 Reporter:  koopersmith      |       Owner:  adamsilverstein
     Type:  feature request  |      Status:  reopened
 Priority:  normal           |   Milestone:  4.9
Component:  General          |     Version:  3.4
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:  javascript
-----------------------------+------------------------------
Changes (by pento):

 * keywords:  has-patch has-unit-tests commit =>
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Unfortunately, this was committed with a blocker not being addressed.

 I only had a brief chance to bring this up in
 [https://github.com/WordPress/packages/pull/13#issuecomment-327041088 the
 PR], but there are several problems with this going into Core now.

 Primarily, it's mostly unused in real situations (ACF being the notable
 exception), and entirely unused (to my knowledge) in a JS project using
 modern practices. While `wp.hooks` would potentially help with our legacy
 JS, new APIs need to be thinking about the future of WordPress' JS
 development. We're in a huge amount of flux at the moment, so focussing on
 new JS practices, then working on making those APIs available to legacy
 JS, gives us much more flexibility for the next 10 years of WordPress
 development. Locking ourselves into a thing built with WordPress' JS
 development of 5 years ago in mind is best case limiting our potential,
 worst case causing significant backwards compatibility issues that we'll
 need to deal with in 6-12 months.

 Even not considering modern practices, `wp.hooks` has no usage in Core,
 some parts of Core's legacy JS should be making use of it when it's
 committed.

 While the pub/sub model has worked really well for WordPress' PHP
 pluggable interfaces, and has been historically used with JavaScript's
 event model, it's not necessarily the way forward, and making it the
 "WordPress way" limits our options.

 So, here's what I suggest:

 - Revert [41375] for now, with the explicit aim of committing `wp.hooks`
 in the future.
 - Publish `wp.hooks` on NPM as 1.0.0.
 - Try using the `wp.hooks` module in Gutenberg. What works? What doesn't?
 - Iterate.
 - If needed, release `wp.hooks` 2.0, 3.0, however many API-breaking
 releases we need.
 - Once the modern practices are settled, backport to work with legacy JS.
 Add it into some of Core's legacy JS, so we get practical usage there,
 too.
 - If we haven't already, have a better way of importing modules into Core.
 Committing the webpack-ed version of the module to the SVN repo is
 unsustainable.
 - Commit `wp.hooks` to Core.

 This gives `wp.hooks` some usage based on modern practices, it gives the
 upheaval in WordPress' JS development practices some time to settle, and
 it gives us a chance to build something that will work in the modern JS
 world, and in the legacy world. Maybe that thing will look quite similar
 to what `wp.hooks` currently looks like, maybe it won't. But now is a
 particularly bad time to be making that bet.

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