Blocks: Revisit pattern for enqueuing scripts and styles

[aduth]

Related: #2751

With the proposal in #2751 to require a PHP block definition for all blocks, it becomes reasonable to revisit whether scripts and styles should be enqueued separately from the block definition itself. Notably, this could have an impact on the front-end display of a block, as currently we must enqueue all scripts and styles for all blocks, regardless of whether a block of that particular type exists on the current screen. If the script and style handles were defined with the block, it is possible to limit this to only the blocks present in the current screen. This would, however, require that the post contents be parsed prior to display to detect blocks present in the post, to then check against all registered block types and associated script and styles handles. We should measure the performance impact of this parsing in relation to the benefit associated with filtering scripts.

Before:

function myplugin_enqueue_block_editor_assets() {
	wp_enqueue_script(
		'nice-block',
		plugins_url( 'block.js', __FILE__ ),
		array( 'wp-blocks', 'wp-components', 'wp-element' )
	);
}
add_action( 'enqueue_block_editor_assets', 'myplugin_enqueue_block_editor_assets' );

After:

function myplugin_enqueue_block_editor_assets() {
	wp_register_script(
		'nice-block',
		plugins_url( 'block.js', __FILE__ ),
		array( 'wp-blocks', 'wp-components', 'wp-element' )
	);

	register_block( 'nice-block', array(
		'script_handle' => 'nice-block',

		// ...
	) );
}
add_action( 'init', 'myplugin_enqueue_block_editor_assets' );

Alternatively, these files could be "discovered" adjacent the block registering file by naming conventions (e.g. find style.css, edit.css, block.js adjacent myblock/index.php). This could encourage developers to define their blocks in a standalone folder/file structure for easier separation overview.

[BE-Webdesign]

#1420 is related to this. You could take pieces of that and add it to this idea to handle css and additional assets beyond just the block script.

[aduth]

Another consideration here raised by blocks with heavy dependencies (#665) and concerns of interoperability pulling in heft of many frameworks (#2463, #2791) is that associating a script with the registration of a block could enable on-demand loading of block scripts. That is, if all blocks are registered and assigned a script handle server-side, we only need to populate the client with the basic information of a block and its associated handle. Once it's determined that a block's browser-specific implementation is used (either in content, by insertion, or common / recent blocks) the script could then be loaded asynchronously.

This could be further optimized to determine server-side by user preferences or post content what block scripts should be loaded with the page synchronously (i.e. available at page load).