Add viewScriptModule handling to block.json metadata by sirreal · Pull Request #5860 · WordPress/wordpress-develop

sirreal · 2024-01-11T15:11:40Z

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 · 2024-01-11T15:32:37Z

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 · 2024-01-15T16:00:32Z

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

#5869

youknowriad · 2024-01-23T08:42:07Z

Is the naming settled, what's blocking here?

gziolo · 2024-01-23T09:08:11Z

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 · 2024-01-23T11:46:04Z

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

sirreal · 2024-01-24T14:53:31Z

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

sirreal · 2024-01-24T15:06:24Z

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

sirreal · 2024-01-24T15:34:19Z

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

sirreal · 2024-01-24T15:55:01Z

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

github-actions · 2024-02-05T12:04:14Z

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 · 2024-02-05T12:26:19Z

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

sirreal · 2024-02-06T15:10:23Z

The asset file can be optional: #5799

gziolo · 2024-02-07T08:10:59Z

 			}
 		}

+		if ( ! empty( $this->block_type->view_script_module_ids ) ) {


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.

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.

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.

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.

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

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.

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.

See WordPress#5799 / https://core.trac.wordpress.org/ticket/60460

Co-authored-by: Greg Ziółkowski <grzegorz@gziolo.pl>

sirreal · 2024-02-08T10:03:28Z

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

gziolo · 2024-02-08T10:40:35Z

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

westonruter · 2025-10-17T19:23:25Z

+	/**
+	 * @ticket 60233
+	 */
+	public function test_missing_asset_file_register_block_script_module_id() {
+		$metadata = array(
+			'file'             => __FILE__,
+			'name'             => 'unit-tests/test-block',
+			'viewScriptModule' => 'file:./blocks/notice/missing-asset.js',
+		);
+		$result   = register_block_script_module_id( $metadata, 'viewScriptModule' );
+
+		$this->assertSame( 'unit-tests-test-block-view-script-module', $result );
+	}


@sirreal Why was this test needed? Why is register_block_script_module_id() not returning false here? I was attempting to harden the types for WP_Script_Modules by ensuring the src is always a non-empty-string but in this case what attempts to get registered is a src of false which results in an empty string.

See 4203864

This is not fresh in my mind, forgive me.

I don't follow the question, what I see here appears to be a missing asset file, which is allowed. The src should be derived from file:./blocks/notice/missing-asset.js. There's no corresponding ./blocks/notice/missing-asset.asset.php file, which does not affect the ID produced by registering the module.

That's my interpretation of the test, but I have little recollection of this.

sirreal mentioned this pull request Jan 11, 2024

POC: Support *module fields in block.json metadata registration sirreal/wordpress-develop#2

Closed

sirreal force-pushed the add-view-module-handling branch from e1e7a44 to 440b5eb Compare January 11, 2024 15:32

sirreal mentioned this pull request Jan 18, 2024

Plugin: Synchronize PHP changes for WordPress 6.5 release WordPress/gutenberg#57959

Closed

sirreal force-pushed the add-view-module-handling branch from 440b5eb to c047353 Compare January 23, 2024 14:00

sirreal mentioned this pull request Jan 23, 2024

Proposal: Support module metadata in block.json for Blocks + Modules API WordPress/gutenberg#57492

Closed

sirreal changed the title ~~Add viewModule handling to block.json metadata~~ Add viewScriptModule handling to block.json metadata Jan 23, 2024

sirreal force-pushed the add-view-module-handling branch from 5d829fa to 4a8a7f3 Compare January 24, 2024 12:58

sirreal marked this pull request as ready for review January 24, 2024 15:00

sirreal commented Jan 24, 2024

View reviewed changes

Comment thread src/wp-includes/blocks.php Outdated

sirreal mentioned this pull request Jan 24, 2024

Scripts: Add viewScriptModule block.json support WordPress/gutenberg#58203

Merged

sirreal mentioned this pull request Jan 25, 2024

Prevent usage of gutenberg_url in block-library WordPress/gutenberg#58242

Merged

sirreal force-pushed the add-view-module-handling branch 3 times, most recently from 8362060 to e035dd5 Compare February 5, 2024 12:03

sirreal mentioned this pull request Feb 6, 2024

Blocks: Add handling for block.json viewScriptModule WordPress/gutenberg#58731

Merged

gziolo reviewed Feb 7, 2024

View reviewed changes

Comment thread src/wp-includes/blocks.php

gziolo reviewed Feb 7, 2024

View reviewed changes

Comment thread tests/phpunit/tests/blocks/register.php

sirreal and others added 21 commits February 8, 2024 10:59

Fix some "script" references

0f7283d

Clean up some dead code and lints

8e4f1a7

Rename to viewScriptModule

3e51c6f

Add to view_script_module_ids to block type REST API

fb36f1f

Add tests

8df5bc0

Test fixes

da148ad

lints

84d8498

Add more tests

9705feb

REST tests

876a507

Fix typo in REST

3712584

Fix tests

b9af0e9

Core viewScriptModule should be suffixed with -script-module

29edd40

Split and expand core block handle module tests

9ea7f4e

Fix since docblock description

a960f65

Add since docblock to REST response

1a1f4e3

Update REST property count in tests (again)

00fbf39

Fix alignment

9da386d

Make module asset file optional

2d3a37f

See WordPress#5799 / https://core.trac.wordpress.org/ticket/60460

Fix typo in test

2112074

Update test for no-asset-file case

fc338e6

Require module asset file only if it exists

a225da1

Co-authored-by: Greg Ziółkowski <grzegorz@gziolo.pl>

sirreal force-pushed the add-view-module-handling branch from d12e711 to a225da1 Compare February 8, 2024 10:00

Update documentation for module registration

d2a5c71

sirreal mentioned this pull request Feb 8, 2024

Docs: Fix mistake in viewScriptModule documentation WordPress/gutenberg#58815

Merged

gziolo closed this Feb 8, 2024

sirreal deleted the add-view-module-handling branch February 8, 2024 11:55

sirreal mentioned this pull request Feb 8, 2024

ViewScriptModule: 6.5 compatibility changes WordPress/gutenberg#58832

Merged

westonruter reviewed Oct 17, 2025

View reviewed changes

Conversation

sirreal commented Jan 11, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Jan 11, 2024

Test using WordPress Playground

Some things to be aware of

Uh oh!

sirreal commented Jan 15, 2024

Uh oh!

youknowriad commented Jan 23, 2024

Uh oh!

gziolo commented Jan 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sirreal commented Jan 23, 2024

Uh oh!

sirreal commented Jan 24, 2024

Uh oh!

sirreal commented Jan 24, 2024

Uh oh!

Uh oh!

sirreal commented Jan 24, 2024

Uh oh!

sirreal commented Jan 24, 2024

Uh oh!

github-actions Bot commented Feb 5, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Core SVN

GitHub Merge commits

Uh oh!

sirreal commented Feb 5, 2024

Uh oh!

sirreal commented Feb 6, 2024

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

sirreal commented Feb 8, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gziolo commented Feb 8, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

sirreal commented Jan 11, 2024 •

edited

Loading

gziolo commented Jan 23, 2024 •

edited

Loading

github-actions Bot commented Feb 5, 2024 •

edited

Loading

sirreal commented Feb 8, 2024 •

edited

Loading