wp.hooks - enable the 'all' hook #12038

adamsilverstein · 2018-11-18T16:27:23Z

Description

Fixes #8602

How has this been tested?

First pass: needs testing.

Types of changes

Checklist:

My code is tested.
My code follows the WordPress code style.
My code follows the accessibility standards.
My code has proper inline documentation.

gziolo · 2019-02-05T14:33:32Z

What's the status of this one. Is it still something that it expected to be included in the library?

adamsilverstein · 2019-02-05T16:50:22Z

What's the status of this one. Is it still something that it expected to be included in the library?

Yes, this seems genuinely useful (maybe essential) for debugging hooks.

I'll work on adding some tests and exploring the monkey patching approach forward. To introduce this feature, we need to insure it has minimal or no impact on performance.

One other option I might explore instead of monkey patching is a debug version of the build that would include the 'all' hook support and would be loaded when SCRIPT_DEBUG is true. that would likely be a cleaner approach and would result in zero impact on production performance. Since this feature is intended for debugging only, this might make the most sense anyway.

What do you think?

gziolo · 2019-02-06T10:18:55Z

One other option I might explore instead of monkey patching is a debug version of the build that would include the 'all' hook support and would be loaded when SCRIPT_DEBUG is true. that would likely be a cleaner approach and would result in zero impact on production performance. Since this feature is intended for debugging only, this might make the most sense anyway.

Sounds great to be disabled by default but enabled in debug mode. I'm wondering how it could be distributed to npm to take advantage of it and ensure that dead code is never bundled for production.

adamsilverstein · 2019-02-06T17:52:32Z

Sounds great to be disabled by default but enabled in debug mode. I'm wondering how it could be distributed to npm to take advantage of it and ensure that dead code is never bundled for production.

How about using the dev/prod build flag so we build the minified production bundle without the 'all' support, while building the unminified version with the 'all' hook support?

I'll try to work on this.

adamsilverstein · 2019-02-06T18:42:02Z

This small change may be all that is required. I am going to write some tests against this functionality to see if it works as expected. The performance penalty should be very small in practice, when no all hooks have been registered a single check is added (admittedly to every apply hooks call). The code is wrapped in comment blocks formatted with an eye towards webpack-strip-block - thinking we can strip this off when we create the minified production version of hooks for core.

aduth · 2019-02-06T20:39:40Z

packages/hooks/src/createRunHook.js

+		/* develblock:start */
+		// Handle any 'all' hooks registered.
+		if ( hooks.all ) {
+			handlers.push( hooks.all.handlers );


You're pushing an array into the array, rather than the members of that array.

i.e.

handlers = [ 1 ]; hooks.all.handlers = [ 2 ]; handlers.push( hooks.all.handlers ); console.log( handlers ); // [ 1, [ 2 ] ]

You'd want one of either:

handlers = handlers.concat( hooks.all.handlers ); handlers.push( ...hooks.all.handlers );

eagle eyes! i wouldn't have caught that error until i wrote the tests. will fix

this is fixed.

aduth · 2019-02-06T20:42:38Z

packages/hooks/src/createRunHook.js

@@ -30,6 +30,14 @@ function createRunHook( hooks, returnFirstArg ) {

 		const handlers = hooks[ hookName ].handlers;

+		// The following code can be stripped from production builds.
+		/* develblock:start */


Is this meant to be processed by a Webpack plugin we're not using?

https://www.npmjs.com/package/webpack-strip-block

We may consider instead a combination of Webpack's (built-in) DefinePlugin and dead-code elimination from its (built-in) minification:

https://webpack.js.org/plugins/define-plugin/

Prior art:

gutenberg/packages/blocks/src/api/validation.js

Lines 257 to 263 in 31b6b17

// In test environments, pre-process the sprintf message to improve

// readability of error messages. We'd prefer to avoid pulling in this

// dependency in runtime environments, and it can be dropped by a combo

// of Webpack env substitution + UglifyJS dead code elimination.

if ( process.env.NODE_ENV === 'test' ) {

return ( ...args ) => logger( require( 'sprintf-js' ).sprintf( ...args ) );

}

Add feature flags for Phase 2 #13324

very interesting.

i was actually imagining that the all hook handling would remain in the package by default and that we would strip it in the WordPress core build for the minified file.

In core we already build two versions of each script: one for SCRIPT_DEBUG and one for production. We can use these tags and the webpack-strip-block plugin to remove them in core's production build. This would completely eliminate the code for produciton and not introduce the overhead of checking the constant.

What do you think?

The treatment of the environment variable is a bit of a facade, really. It actually achieves the same effect as what you're describing. The way the DefinePlugin works is to literally swap the identifier with some substitute. Thus, if you introduced a condition like this, the body of the condition would be kept for development, and removed for production.

Before (source):

/* a */ if ( process.env.NODE_ENV !== 'production' ) { /* b */ } /* c */

After (built with Webpack, unminified):

/* a */ if ( 'production' !== 'production' ) { /* b */ } /* c */

After (built with Webpack, minified, comments kept for demonstration only):

/* a *//* c */

Ok, cool - so we don't need the or the tagging, just a conditional, got it. thanks for clarifying.

So in terms of what we ship in the package, we only ship source right? Do we ship debug scripts with the GB plugin or in core?

my ultimate goal is to have this depend of a wp-config constant, ideally SCRIPT_DEBUG.

So in terms of what we ship in the package, we only ship source right? Do we ship debug scripts with the GB plugin or in core?

My expectation would have been that process.env.NODE_ENV would be effectively "development" for the non-minified scripts we ship with core, and thus if SCRIPT_DEBUG would cause the unminified form to load, it would take effect as you expect. However, considering an example where we console.error a message, I see no reference to said message in the full unminified source for wp.components. I'm not too sure if this is intended or not.

I think that process.env.NODE_ENV would work the way it's expected. WordPress core would have to generate two versions of the files: development and production. SCRIPT_DEBUG would pick the proper version then. If this isn't the case in core, we should fix it.

adamsilverstein · 2019-02-06T23:55:00Z

Added some tests demonstrating the 'all' hook in 92920ff

adamsilverstein · 2019-02-06T23:57:29Z

cc: @johnbillion this might be useful for query monitor

gziolo · 2019-04-24T12:43:50Z

@adamsilverstein, do you plan to use guard based on process.env.NODE_ENV? I think this is the last thing missing to land this PR.

gziolo

This PR needs also rebase to trigger new Travis services.

adamsilverstein · 2019-05-01T00:12:33Z

@adamsilverstein, do you plan to use guard based on process.env.NODE_ENV? I think this is the last thing missing to land this PR.

Yes, thanks for the reminder about this ticket. I will work on it.

…r for every hook.

adamsilverstein · 2019-05-01T00:28:35Z

@gziolo I rebased and added the switch based on process.env.NODE_ENV - does that look right?

adamsilverstein · 2019-05-01T14:49:21Z

looks like tests are failing here on the new 'all' hook tests. My guess is this is because the tests run against the production code which does not include the all hook support.

Can we get these tests to run against the development build instead? otherwise I'm not sure how we can test this code?

aduth · 2019-05-01T19:07:48Z

If I recall correctly, the tests are run in NODE_ENV of test 'test'. Would it be enough to change the logic from === 'development' to !== 'production' ?

gziolo · 2019-05-02T07:36:48Z

If I recall correctly, the tests are run in NODE_ENV of test 'test'. Would it be enough to change the logic from === 'development' to !== 'production' ?

100% correct.

I don’t want to block this one

adamsilverstein · 2019-05-02T15:58:14Z

Great, thanks for the tip - I'll change that.

adamsilverstein · 2019-05-02T17:41:57Z

@aduth thanks, that fixed it. This is ready for review.

gziolo

This all looks good now. Should we include docs for all hook and add an entry to CHANGELOG file? It might be worth emphasizing that it works in non-production environments only.

adamsilverstein · 2019-05-06T13:57:42Z

Should we include docs for all hook and add an entry to CHANGELOG file? It might be worth emphasizing that it works in non-production environments only.

Yes, I will work on adding that, thanks!

adamsilverstein · 2019-05-16T04:47:45Z

@gziolo

updated the changelog in a804f49
updated the readme in 1a625ec

Can you please review to see if those look good?

gziolo · 2019-05-16T08:47:32Z

packages/hooks/CHANGELOG.md

@@ -1,3 +1,6 @@
+## 2.1.0 (2019-05-16)


Suggested change

## 2.1.0 (2019-05-16)

## Master

gziolo · 2019-05-16T08:50:39Z

packages/hooks/CHANGELOG.md

@@ -1,3 +1,9 @@
+## Master


I updated CHANGELOG myself. We are still not set on the proper recommendation here, but there is new emerging pattern to list new changes as coming from master. Probably something good to document. /cc @aduth

gziolo · 2019-05-16T08:51:43Z

@adamsilverstein - I slightly modified CHANGELOG (see my comment #12038 (comment)). Great work, thanks for wrangling this enhancement 👍

adamsilverstein mentioned this pull request Nov 19, 2018

wp.hooks: support the special all hook #8602

Closed

gziolo requested a review from aduth February 5, 2019 14:31

gziolo added the [Status] In Progress Tracking issues with work in progress label Feb 6, 2019

adamsilverstein requested review from gziolo and youknowriad as code owners February 6, 2019 18:35

adamsilverstein added Needs Tests [Type] WP Core Ticket Requires an upstream change from WordPress. Core Trac ticket should be linked. labels Feb 6, 2019

aduth reviewed Feb 6, 2019

View reviewed changes

gziolo previously requested changes Apr 24, 2019

View reviewed changes

Adam Silverstein added 4 commits April 30, 2019 18:13

All action: Shim doAction and applyFilters to trigger the all listene…

2b81cb4

…r for every hook.

add all hook handling wrapped in comment blocks for production removal

d153423

Add some unit tests for the ‘all’ hook

adda6d7

Avoid hook recursion when adding all hook

42659b9

adamsilverstein force-pushed the feature/enable-all-hook branch from 5210e14 to 42659b9 Compare May 1, 2019 00:13

Conditionally add all hook support based on process.env.NODE_ENV

8926b3d

adamsilverstein force-pushed the feature/enable-all-hook branch from fe603de to 8926b3d Compare May 1, 2019 00:27

adamsilverstein requested a review from gziolo May 1, 2019 00:28

adamsilverstein changed the title ~~WIP: wp.hooks - enable the 'all' hook~~ wp.hooks - enable the 'all' hook May 2, 2019

use negative production check

3edc876

adamsilverstein requested a review from aduth May 2, 2019 17:42

gziolo approved these changes May 6, 2019

View reviewed changes

gziolo removed [Type] WP Core Ticket Requires an upstream change from WordPress. Core Trac ticket should be linked. Needs Tests [Status] In Progress Tracking issues with work in progress labels May 6, 2019

Adam Silverstein added 2 commits May 15, 2019 22:37

Add a changelog entry describing the all hook

a804f49

Document the all hook

1a625ec

Update CHANGELOG.md

5b00e59

gziolo approved these changes May 16, 2019

View reviewed changes

gziolo added this to the 5.8 (Gutenberg) milestone May 16, 2019

gziolo merged commit f07e756 into master May 16, 2019

gziolo deleted the feature/enable-all-hook branch May 16, 2019 09:11

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

wp.hooks - enable the 'all' hook #12038

wp.hooks - enable the 'all' hook #12038

adamsilverstein commented Nov 18, 2018 •

edited

Loading

gziolo commented Feb 5, 2019

adamsilverstein commented Feb 5, 2019

gziolo commented Feb 6, 2019

adamsilverstein commented Feb 6, 2019

adamsilverstein commented Feb 6, 2019 •

edited

Loading

aduth Feb 6, 2019 •

edited

Loading

adamsilverstein Feb 6, 2019

adamsilverstein Feb 12, 2019

aduth Feb 6, 2019 •

edited

Loading

adamsilverstein Feb 6, 2019

aduth Feb 6, 2019

adamsilverstein Feb 6, 2019 •

edited

Loading

aduth Feb 18, 2019

gziolo Apr 24, 2019

adamsilverstein commented Feb 6, 2019

adamsilverstein commented Feb 6, 2019

gziolo commented Apr 24, 2019

gziolo left a comment

adamsilverstein commented May 1, 2019

adamsilverstein commented May 1, 2019

adamsilverstein commented May 1, 2019

aduth commented May 1, 2019

gziolo commented May 2, 2019

adamsilverstein commented May 2, 2019

adamsilverstein commented May 2, 2019

gziolo left a comment •

edited

Loading

adamsilverstein commented May 6, 2019

adamsilverstein commented May 16, 2019

gziolo May 16, 2019

gziolo May 16, 2019

gziolo commented May 16, 2019

	// In test environments, pre-process the sprintf message to improve
	// readability of error messages. We'd prefer to avoid pulling in this
	// dependency in runtime environments, and it can be dropped by a combo
	// of Webpack env substitution + UglifyJS dead code elimination.
	if ( process.env.NODE_ENV === 'test' ) {
	return ( ...args ) => logger( require( 'sprintf-js' ).sprintf( ...args ) );
	}

wp.hooks - enable the 'all' hook #12038

wp.hooks - enable the 'all' hook #12038

Conversation

adamsilverstein commented Nov 18, 2018 • edited Loading

Description

How has this been tested?

Types of changes

Checklist:

gziolo commented Feb 5, 2019

adamsilverstein commented Feb 5, 2019

gziolo commented Feb 6, 2019

adamsilverstein commented Feb 6, 2019

adamsilverstein commented Feb 6, 2019 • edited Loading

aduth Feb 6, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aduth Feb 6, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adamsilverstein Feb 6, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adamsilverstein commented Feb 6, 2019

adamsilverstein commented Feb 6, 2019

gziolo commented Apr 24, 2019

gziolo left a comment

Choose a reason for hiding this comment

adamsilverstein commented May 1, 2019

adamsilverstein commented May 1, 2019

adamsilverstein commented May 1, 2019

aduth commented May 1, 2019

gziolo commented May 2, 2019

adamsilverstein commented May 2, 2019

adamsilverstein commented May 2, 2019

gziolo left a comment • edited Loading

Choose a reason for hiding this comment

adamsilverstein commented May 6, 2019

adamsilverstein commented May 16, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gziolo commented May 16, 2019

adamsilverstein commented Nov 18, 2018 •

edited

Loading

adamsilverstein commented Feb 6, 2019 •

edited

Loading

aduth Feb 6, 2019 •

edited

Loading

aduth Feb 6, 2019 •

edited

Loading

adamsilverstein Feb 6, 2019 •

edited

Loading

gziolo left a comment •

edited

Loading