Blocks: Add handling for block.json viewScriptModule

[sirreal]

What?

Support viewScriptModule block.json field for registering blocks from metadata.

Why?

#57437 added viewModule support, but the Modules API changed in core to refer to "script modules." We expect this field to land in core as viewScriptModule (WordPress/wordpress-develop#5860).

How?

viewModule remains supported (but deprecated).
viewScriptModule support is added.
If both fields are added, viewScriptModule will be used.

We now have two REST API fields for block types with the same information. view_module_ids (deprecated) and view_script_module_ids.

Testing Instructions

Largely the same as #57437. Try these steps with viewModule, viewScriptModule and both.

Add a block using block.json with a (viewModule, viewScriptModule, both) field pointing to its view module. I've compiled a block (with #57461) that's available at this gist. It can be unzipped as a plugin and used for testing.

We should be able to add our block in the editor. If we use the REST API to query block types and search for view_module_ids we should find our block:

(await wp.apiFetch( { path: '/wp/v2/block-types' }))
  .filter( ({ view_module_ids }) => view_module_ids.length )
  .map(blockType => ({
    name: blockType.name,
    view_module_ids: blockType.view_module_ids,
    view_script_module_ids: blockType.view_script_module_ids,
  }))[0]
// { "name": "jon/the-block", "view_module_ids": [ "jon-the-block-view-module" ], "view_script_module_ids": [ "jon-the-block-view-module" ] }

If the block is added to a post and we visit it on the frontend, we should see it working as expected (a counter in our example).

We should also see the expected modules added to the importmap and module preloads on our post with the block. I used an older theme to ensure nothing else was enqueuing the interactivity module:

document.querySelector('[type=importmap]');
// <script type=​"importmap">​{"imports":{"@wordpress\/interactivity":"…"}}</script>​
document.querySelector('#\\@wordpress\\/interactivity[rel=modulepreload]');
// <link rel="modulepreload" href="…" id="@wordpress/interactivity">

[github-actions]

This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress.

If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged.

If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack.

Thank you! ❤️

View changed files

❔ lib/experimental/script-modules.php

[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, luisherranz, gziolo, cbravobernal.

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: luisherranz <luisherranz@git.wordpress.org>
Co-authored-by: gziolo <gziolo@git.wordpress.org>
Co-authored-by: c4rl0sbr4v0 <cbravobernal@git.wordpress.org>

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

[gziolo]

I was looking at the current state of the feature in preparation for syncing changes with WordPress core. There are two more PRs to land in Gutenberg:

• Scripts: Add viewScriptModule block.json support #58203
• Interactive Template: Use viewScriptModule #58211

Is there a documentation in place similar to https://github.com/WordPress/gutenberg/blob/trunk/docs/reference-guides/block-api/block-metadata.md#view-script?

The following section doesn’t play well with ES Modules, so some edits will be required:
https://github.com/WordPress/gutenberg/blob/trunk/docs/reference-guides/block-api/block-metadata.md#wpdefinedasset

In general, documenting when and how to transition to viewScriptModule is something that is going to be key here.

[sirreal]

Good spot, I'll add and update documentation in this PR.

[sirreal]

When this lands in core, the block.json schema will also need an update, but that file is served from GitHub so there's no realease deadline for that change.

[sirreal]

I've pushed some updates to the documentation mentioned.

[github-actions]

Flaky tests detected in 49b0d0a.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7813292843
📝 Reported issues:

• [Flaky Test] aria-disabled is correctly hydrated for different values #54370 in /test/e2e/specs/interactivity/directive-bind.spec.ts

[cbravobernal]

When this lands in core, the block.json schema will also need an update, but that file is served from GitHub so there's no realease deadline for that change.

I think you need to edit this file, can be done in Gutenberg:
https://github.com/WordPress/gutenberg/blob/trunk/schemas/json/block.json

[luisherranz]

Tested and working as expected, both the enqueueing of the script module in the frontend and the new endpoint in the REST API 🙂

[desrosj]

👋 Hi @sirreal! Just a friendly reminder to manually review, update as needed, and include the Co-authored-by trailers in the merge commit message. In case it was missed, here's the announcement post and the accompanying handbook page with the specific details.

If it was on accident, no big deal! But just trying to make sure everyone is aware as we retrain our brains. 😄