[WIP] Update/build individual blocks

[kanishkdudeja]

This is continuation of work started by @aduth in #4841

Most of the work is complete. Some things which are left are:

• Remove tuples from Webpack configuration
• Fix some other issues in Webpack configuration
• Fix existing unit tests
• Fix existing end-to-end tests
• More manual testing to make sure that nothing has broken

[gziolo]

Is it possible to automate the PHP files part to avoid so much boilerplate code? Given that all files are generated by Webpack and we know all the patterns how JS and CSS files are named based on the folder name, can we autodetect those files and register them behind the scenes?

I provide an example for Audio block.

Before

function register_core_audio_block() {
	wp_register_script( 'core-audio-block', gutenberg_url( '/build/blocks/library/audio.js' ) );
	wp_register_style(
		'core-audio-block',
		gutenberg_url( '/build/blocks/library/audio.css' ),
		array(),
		filemtime( gutenberg_dir_path() . 'build/blocks/library/audio.css' )
	);
	
	wp_style_add_data( 'core-audio-block', 'rtl', 'replace' );
	wp_register_style(
		'core-audio-block-editor',
		gutenberg_url( '/build/blocks/library/audio_editor.css' ),
		array(),
		filemtime( gutenberg_dir_path() . 'build/blocks/library/audio_editor.css' )
	);
	
	wp_style_add_data( 'core-audio-block-editor', 'rtl', 'replace' );
	register_block_type( 'core/audio', array(
		'style' => 'core-audio-block',
		'editor_style' => 'core-audio-block-editor',
		'editor_script' => 'core-audio-block',
	) );
}
add_action( 'init', 'register_core_audio_block' );

After

function register_core_audio_block() {
	register_block_type( 'core/audio', array(
		'style' => 'core-audio-block',
		'editor_style' => 'core-audio-block-editor',
		'editor_script' => 'core-audio-block',
		'detect_files' => true, // Not sure if we need it all, but leaveing a note to better explain the idea.
	) );
}
add_action( 'init', 'register_core_audio_block' );

[kanishkdudeja]

Yes I agree @gziolo. This thought came to my mind as well.

@aduth What are your thoughts on this?

[aduth]

My only concern is that if it's boilerplate for us, it's boilerplate for any plugin developer, and we ought not give ourselves too many shortcuts if there's a solution which could benefit everyone.

And since these are meant to be proper script and style handles, when would they be registered? Could plugins still manipulate them? What is the naming convention which associates a script handle with the detected file?

[aduth]

Will we risk any regression on #4514 where registration was moved to registerCoreBlocks? I think I originally thought it would be no issue, since the root problem was that registration and the core library of blocks were contained within the same module, which is no longer the case here. But we should be certain.

[gziolo]

My only concern is that if it's boilerplate for us, it's boilerplate for any plugin developer, and we ought not give ourselves too many shortcuts if there's a solution which could benefit everyone.

I thought about it as a general opt-in solution, rather than tailored to needs of Gutenberg (core). We should still provide an option which gives very granular control over registered assets as it is coded in this PR. I would like us to explore if there is a nice way to simplify it for recurring patterns we can observe for core blocks. Looking at Webpack config I can see that we are expecting to have index.js, styles.scss and editor.scss files.

And since these are meant to be proper script and style handles, when would they be registered? Could plugins still manipulate them? What is the naming convention which associates a script handle with the detected file?

First, I missed one thing - dependencies of the styles and scripts. They weren’t included initially which tricked me a bit but it’s being fixed (02812b4). This becomes a weak point of my proposal, but in general, it is something that should be fixed in WordPress core sooner than later. It slowly becomes a pain point as we introduce new modules.

To your point, I don’t think it would change the existing flow a lot. My expectation was to execute the logic which registers those assets at the beginning of the register_block_type method, which doesn’t differ much from what we have at the moment. Again, I’m thinking about it as the opt-in solution for those who want to follow certain patterns in how block’s folder is structured. It could work for both ES5 and Webpack controlled blocks if we would agree on common file location. In my proposal shared earlier, I provided only the name of the handle, but we could also convert it to the array to support dependencies and custom file names. We can also assume default paths for those handles based on their types. This is how it works in WP core as observed earlier.

[kanishkdudeja]

@aduth @nb @gziolo @mcsf

One blocker with shipping this functionality is that it will enqueue stylesheets and scripts for each block type separately. This will lead to multiple HTTP requests.

We can use WordPress's inbuilt load-styles.php and load-scripts.php mechanism for bundling styles and scripts together (which will lead to not needing multiple HTTP requests).

We can think of enqueueing one bundle for all block types belonging to a particular namespace. Meaning, all styles / scripts for core block types will be served in 1 bundle. For another plugin, all scripts / styles for block types defined by that plugin will be served in another bundle.

This approach however has an issue. load-styles.php and load-scripts.php use the current WordPress version as the value of the Etag header. So if a plugin/theme developer modifies some CSS / JS for their block type, the browser will not attempt to fetch the latest content since the value of the Etag header will remain the same (since the WordPress version will remain the same).

We can add some functionality in load-styles.php and load-scripts.php to support this:

Specify the value of the Etag header as a hash of the script/style handles and their corresponding versions.

So, if we get a request to load styles for paragraph and image block like this:

/load-styles.php?load=core-paragraph-block&core-image-block

We can generate the Etag like this:

etag = hash_function( 'core-paragraph-block-v1.1-core-image-block-v8.3')

and supply this value in the Etag header in the response to the browser.

This will make sure that the next time the plugin/theme developer changes the CSS / JS for a block type (meaning changes the version for the CSS / JS of a block type), the hash function will automatically generate a new value for the Etag header and the browser will therefore fetch the latest style / script bundle.

We can add this functionality in load-styles.php and load-scripts.php as an add-on to the current functionality (to preserve backward compatibility).

Maybe, this new functionality can be triggered if a specific URL parameter is included in the request to load-styles.php / load-scripts.php. Maybe, something like: /load-styles.php?etag=content_hash.

What do you guys think of this approach? Do you think we can go ahead with this?

[gziolo]

@kanishkdudeja - this is exactly what we discussed on Slack. It sounds reasonable. This is exactly what I would explore first as a simple solution. Personally, I would also try to use plugin version instead of generating the hash. Unless the plugin version is unreliable.

[kanishkdudeja]

Thanks for your comment @gziolo

This is exactly what we discussed on Slack.

Yes, I just wanted to keep @aduth @mcsf and @nb in loop here as well.

It sounds reasonable. This is exactly what I would explore first as a simple solution.

Thanks. I'm starting on this now :)

Personally, I would also try to use plugin version instead of generating the hash. Unless the plugin version is unreliable.

I'm not sure if we should use plugin version as a means of bursting cache for style / script bundles.

Ideally, load-styles.php or load-styles.php shouldn't be concerned about where styles / scripts are coming from (plugins/core). They should just be supplied an array of style / script handles and they should just generate the Etag based on the requested handles and their corresponding versions. This will also help let the implementation remain generic.

[aduth]

Ideally, load-styles.php or load-styles.php shouldn't be concerned about where styles / scripts are coming from (plugins/core). They should just be supplied an array of style / script handles and they should just generate the Etag based on the requested handles and their corresponding versions.

I agree with this. I think your idea is valid and worth exploring. I'm not sure whether there is a backwards-compatibility worry to be concerned about here either. At worst, it would "bust" existing caches for those who have them? Proposing as a ticket on the Core Trac may also invite more feedback from those who might have reason to think that assigning the current WordPress version was a necessary decision.

[kanishkdudeja]

@nb @aduth @gziolo

I've opened a ticket for this on the Core WordPress Trac: https://core.trac.wordpress.org/ticket/43825

Have proposed this patch for the enhancement: https://core.trac.wordpress.org/attachment/ticket/43825/43825.patch

[kanishkdudeja]

Some related work (by @youknowriad) is close to being merged in #6351.

Some of the work is common (importing dependencies from @wordpress/blocks rather than importing them internally).

Once #6351 gets merged, I'll fix the conflicts and rebase the changes in this branch from the updated master branch.

[kanishkdudeja]

Pushed a commit which resolves conflicts as a result of merging changes from master (After #6351 got merged).

This has led to some regressions in tests for this branch. Will fix those as well and post an update here once it's done.

[kanishkdudeja]

@gziolo @youknowriad

I had a discussion about this PR with @aduth today and we felt that it might be better to pause work on this for now since there is a major blocker with this PR going live and since this functionality doesn't seem to be a priority as of now.

This PR will enqueue separate stylesheets and scripts for each block type in the editor and front-end contexts. This will lead to multiple HTTP requests and will hurt performance. To get around this, I thought we could use WordPress's inbuilt style and script concatenation mechanism (load-styles.php and load-scripts.php) and proposed this patch (#43825) to WordPress Core to address an issue described here.

But it looks like we'll have another problem. Both these scripts don't initialize plugins. So they don't have a list of style/script handles of registered block types.

So, either we could

• Initialize plugins in these scripts for them to be able to have style/script handles for block types (Will need to check if that could cause problems)
• Or write a custom bundling/concatenation mechanism for this (One possible approach described here).

What are your thoughts?

[gziolo]

Yes, this one is complex. Let's wait until we have a better mechanism for server-side registration of blocks and support for batching plugin related files in core.

[aduth]

This pull request appears to have languished and will not be easily reconciled with master. Please feel free to reopen and rebase against the current master, or open a new pull request.