[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
-----------------------------+------------------------------

Comment (by adamsilverstein):

 @pento I respectfully disagree with your conclusion here. As a note, I
 committed this code after careful discussion and several public comments
 affirming the commit by ''WordPress Lead developer @azaozz'' as well as
 feedback and contributions from some of core's most experienced JavaScript
 contributors.

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

 //Your blocker seems contrived//: we can't add a library to core until it
 is already used?  Just last week, our project leader @matt was telling us
 to [https://wordpress.slack.com/archives/C02RQBWTW/p1504729788000192 'more
 iteration happening in trunk']. Having this in trunk means we can build
 off it, using it in core itself and we have plans to do just that.

 > 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.

 What? We can't add usage in core until hooks is in core. And indeed, now
 that it is in core, the plan is to move forward by adding extensibility to
 core JavaScript via `wp.hooks`. For example, one common need extending the
 media modal and `wp.hooks` would be perfect to add
 [https://core.trac.wordpress.org/ticket/40427#comment:5 these
 capabilities] we are discussing on #40427.

 For example, I recently worked to help introduce the image widget to core.
 [https://github.com/xwp/wp-core-media-widgets/pull/46/files In this PR],
 you can see the (huge amount of) code  needed to the get the 'Insert
 Media' button working (all we wanted was to remove the add
 gallery/playlist options). '''Having filters in place in wp.media would
 //greatly// simplify these types of customizations.'''

 > it's not necessarily the way forward, and making it the "WordPress way"
 limits our options.

 I disagree. Sure, it may not be the way forward with Gutenberg for
 example, why does that limit our options? We have needed a way to provide
 more JS extensibility for 5+ years, and `wp.hooks` addresses that need. I
 haven't heard a final extensibility approach articulated by Gutenberg (or
 Calypso for that matter), and whatever they choose may not be applicable
 to our 35k lines of legacy JavaScript and Backbone code.

 It seems like //you are afraid to include hooks because it may lock us
 into something outdated//. Please consider that this is a proven, well
 tested library that will let us make our existing JS more extensible. Sure
 - it may not work for our future needs - that shouldn't stop it from
 solving our current needs with a proven approach. Also, it is a tiny
 library that hasn't changed much in years, so the maintenance burden will
 be small.

 > 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.

 This is fanciful. We don't know what these practices will be or whether
 they will even work with our legacy JavaScript.  Why are we discarding a
 proven approach we know we can use now for some imaginary approach that
 may arrive at some time in the future? Many smart people worked very hard
 on this library and getting in core for good reason - they want to use it
 in their development work. It seems like you are saying we should not add
 it to core because its not yet used or because some new approach may work
 better. This hinders our progress in core JavaScript instead of forwarding
 it.

 > 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.

 I agree. We are planning to include this from npm directly once its
 published, as part of our build process once we switch to webpack from
 browserify we will have what we need (#40894). This can still happen in
 4.9.

 I would be interested to hear more feedback from @azaozz or other lead
 developers, as well as from members of the Gutenberg team such as @aduth
 or @jnylen0. Does `wp.hooks` seem like something that would be genuinely
 useful for WordPress core and plugin/theme developers or in your project?
 Are you working on a new approach to extensibility that will be applicable
 to core that we should be waiting for? Also, @westonruter have you looked
 at wp.hooks, is it something you think would be useful in making the
 //Customizer more extensible?//

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