Add viewScriptModule handling to block.json metadata

[sirreal]

Add handling for viewScriptModule block.json metadata when registering blocks.

This can be tested with this demo plugin.

The block can be added in the editor. On the frontend, the module is enqueued when viewing a page with the block:

document.querySelectorAll('[type=module]')
// NodeList [script#jon-the-block-view-script-module-js-module]

Trac ticket: https://core.trac.wordpress.org/ticket/60233

This is a port from Gutenberg: WordPress/gutenberg#57959
It was implemented with viewModule in WordPress/gutenberg#57437
Gutenberg PR to switch to viewScriptModule: WordPress/gutenberg#58731

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[sirreal]

We'll want to wait until naming questions are settled:

#5869

[youknowriad]

Is the naming settled, what's blocking here?

[gziolo]

Is the naming settled, what's blocking here?

It needs a rebase after #5869 lands. The name of the helper functions for modules will follow the following pattern: wp_(register|enqueue)_script_module, so that probably should get reflected in block.json and other places, viewScriptModule? It's a bit unfortunate that we can't extend viewScript in a backward-compatible way to support both ES Modules and legacy scripts.

[sirreal]

#5869 landed recently so I'll finish this and get it ready for review.

[sirreal]

The Modules API ended up with names like "script_module." To better align, this has been updated to use viewScriptModule instead of viewModule.

[sirreal]

@luisherranz @gziolo @youknowriad This is ready for review.

[sirreal]

There was 1 test failure on a single PHP version that seems to be a flakey test.

[sirreal]

Adding support to the @wordpress/scripts for building blocks with viewScriptModule: WordPress/gutenberg#58203

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core SVN

Core Committers: Use this line as a base for the props when committing in SVN:

Props jonsurrell, gziolo, cbravobernal, luisherranz, youknowriad.

GitHub Merge commits

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: sirreal <jonsurrell@git.wordpress.org>
Co-authored-by: gziolo <gziolo@git.wordpress.org>
Co-authored-by: c4rl0sbr4v0 <cbravobernal@git.wordpress.org>
Co-authored-by: luisherranz <luisherranz@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[sirreal]

Tests were failing because the number of REST fields returned in the response has changed again. They should be fixed now.

[sirreal]

The asset file can be optional: #5799

[gziolo]

I was wondering whether it would fit better after all filters get applied like render_block. This way, plugin authors still would have the opportunity to change the list of module IDs on the block.

[sirreal]

Do you mean that authors could change the block or module dependencies in the render_block filter function?

I don't have strong feelings on whether or not it should be moved after the render filters. I do know that changing the module graph is error prone and not something that should be done in most cases.

[gziolo]

Extenders can add/remove/replace what is inside $this->block_type->view_script_module_ids with filters like render_block, so maybe it's worth accounting for it. Anyway, the same issue exists today with view scripts, so maybe we need to live with it for conistency.

[sirreal]

I'm happy to defer to your judgment. My instinct was to align with how scripts work but we do not strictly need to do if we can improve things.

[cbravobernal]

Maybe we can check if differs after filters and do a _doing_it_wrong() with the message of Changing the module graph is error prone

[luisherranz]

I don't have a strong opinion about this but from my experience trying to change supports.interactivity dynamically, I don't think mutating the Block Type at render time should be encouraged. The way I see it now is that the Block Type is meant to represent the properties of all the blocks of that type, not just the one being rendered. Changing it on the fly to accommodate the block that is being rendered is confusing and leads to complexity. So, I think that the differences between the rendered blocks of the same type should be reflected by other means.

[gziolo]

Do you anticipate introducing any conditional loading for view script modules depending on the HTML rendered for the block? Let's say enqueueing only these registered modules for the block that has corresponding directives in the final HTML. That would be a more compelling reason to move the logic after block render filters.

[sirreal]

I've finished rebasing (it was a bit tricky) and tweaking some documentation, I think this is ready now.

[gziolo]

Committed with https://core.trac.wordpress.org/changeset/57565.