Editor: Shim meta attribute source on registered edit component

[aduth]

Previously: #17153

This pull request seeks to revise the implementation of custom meta source compatibility by filtering on the block registration to enhance the registered edit component if and only if the block includes an meta-sourced attribute.

The advantage here is to optimize for the majority of blocks that do not register any meta-sourced attributes. Previously, the logic to determine whether a block needs a shim would run for each block in the page (at initial load, and on every change of isTyping flag), regardless of whether any blocks in content used meta attributes, or even if there were no registered block types which source from meta attributes.

Implementation Notes:

It was necessary to change the test plugin to enqueue at 'enqueue_block_assets' instead of 'init' for this to work correctly, as otherwise the hook was added too late to enhance the block registration. However, I'd argue this is an error in the implementation of the test plugin, and not symptomatic of a larger concern.

• Per wp_enqueue_script documentation, it is not expected to call the function for any script during init, but rather in general use via either the wp_enqueue_scripts or admin_enqueue_scripts actions.
• It is (and always has been the case) that the documented recommendation for enqueueing block scripts is do so either during the enqueue_block_assets hook, or by providing an editor_script property to register_block_type (which performs the enqueue during enqueue_block_assets on behalf of the developer).
• There are already many existing hooks on blocks.registerBlockType which would otherwise be subject to the same assumptions of correct script enqueue timing:

  • gutenberg/packages/block-editor/src/hooks/align.js

    Line 208 in 5e68cdc

    addFilter( 'blocks.registerBlockType', 'core/align/addAttribute', addAttribute );

  • gutenberg/packages/block-editor/src/hooks/anchor.js

    Line 119 in 5e68cdc

    addFilter( 'blocks.registerBlockType', 'core/anchor/attribute', addAttribute );

  • gutenberg/packages/block-editor/src/hooks/custom-class-name.js

    Line 155 in 5e68cdc

    addFilter( 'blocks.registerBlockType', 'core/custom-class-name/attribute', addAttribute );

Performance Results:

I've been struggling to get the performance test suite to perform stably today. However, I expect that the results as provided by this suite may be misleading, since as noted above, the issue is not as concerning when in an unbroken sequence of typing; a more real-world scenario of start/stop typing would be prove to demonstrate a bigger difference.

Ultimately, I still don't expect it to have a drastic improvement on performance. My attention was originally drawn to it in an Performance recording bottom-up entry accounting for a few milliseconds of self-time, so I think it would be fair to assess we could save upwards of a few milliseconds at initial render or keypresses which result in a change in the isTyping flag.

Testing Instructions:

Verify there is no regression in the behavior of meta-sourced attributes. This is easiest if you are using the local development environment, by activating the "Gutenberg Test Meta Attribute Block" plugin. You should be able to insert the block "Test Meta Attribute Block", update its value, and see the value persist between page loads.

[epiqueras]

I wonder, can we have an empty string/falsy meta key?

[aduth]

I wonder, can we have an empty string/falsy meta key?

If you mean specifically the key (and not the value), then I don't think this is support, no.

$meta_key
(string) (Required) Meta key to register.

https://developer.wordpress.org/reference/functions/register_meta/

[epiqueras]

Yeah, technically an empty string is still a string right?

[aduth]

Yeah, technically an empty string is still a string right?

Technically, yes. Interesting edge case to consider 🙂 It doesn't seem that register_meta validates it, but it would be impossible to set a value for it given that in add_metadata, the empty string would evaluate as falsey here:

https://github.com/WordPress/wordpress-develop/blob/8ed3551/src/wp-includes/meta.php#L33

[epiqueras]

Interesting. I mentioned it because this PR wouldn't work with it.