Blocks: Add handling for block.json viewModule

[sirreal]

What?

Add viewModule support for registering blocks from metadata.

Part of #57492

To do:

• Add viewModule field to REST API

Why?

As we introduce module support and the Interactivity API (only available as a module at this time), we should provide at least a similar experience to what we currently have with scripts.

How?

This follows a similar pattern to how WordPress Core manages block scripts. Different script handles are attached to the WP_Block_Type instance. Then those are enqueued when the block is rendered.

We use some filters to achieve the same result. I'd expect this functionality to move to Core when Modules support lands (WordPress/wordpress-develop#5818). See sirreal/wordpress-develop#2 for an example of what that might look like.

Testing Instructions

Add a block using block.json with a viewModule 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,
  }))[0]
// { "name": "jon/the-block", "view_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/modules/class-gutenberg-modules.php

[github-actions]

Flaky tests detected in 3fd6278.
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/7415313014
📝 Reported issues:

• [Flaky Test] should display the correct preview when switching between published and draft statuses #37976 in /test/e2e/specs/editor/various/preview.spec.js

[sirreal]

I reverted the identifier change, we're back to ID 😄

[sirreal]

@luisherranz Any preference for how we handle the dev note? Are there other announcements around modules and Interactivity that go together?

[luisherranz]

I've never done a dev note so I have no idea 😄

But the Interactivity API and Modules API should be announced separately. It happens that the Interactivity API will use the Modules API, but they are conceptually separate things.