-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove Interactivity API experimental flag #50941
Remove Interactivity API experimental flag #50941
Conversation
Size Change: -3.57 kB (0%) Total Size: 1.39 MB
ℹ️ View Unchanged
|
Right now, to do the conditional loading of scripts, I'm reusing the same logic for the Navigation, the File, and the Image block. Would it make sense to create a function that can be reused by all the blocks? If so, which is the best place to do so? cc: @gziolo I'm thinking of something like: function load_view_js_file ( $block, $view_js_file, $should_load_view_script ) {
if ( ! wp_script_is( $view_js_file ) ) {
$script_handles = $block->block_type->view_script_handles;
// If the script is not needed, and it is still in the `view_script_handles`, remove it.
if ( ! $should_load_view_script && in_array( $view_js_file, $script_handles ) ) {
$block->block_type->view_script_handles = array_diff( $script_handles, array( $view_js_file ) );
}
// If the script is needed, but it was previously removed, add it again.
if ( $should_load_view_script && ! in_array( $view_js_file, $script_handles ) ) {
$block->block_type->view_script_handles = array_merge( $script_handles, array( $view_js_file ) );
}
}
} |
To me, this feels rushed, the image light box was merged less than 24 hours ago? |
Flaky tests detected in a97c9c7. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5113067268
|
Oh, my intent wasn't to release it whenever this pull request is ready. I just thought it would be good to have everything ready for the moment we decide not to use the Experimental flag anymore. I'll clarify that in the opening post.
I wasn't aware of it. Thanks for sharing 🙂 Yes, the goal is the same. I'll coordinate with him to see how to approach it. |
I've closed #50915 and will follow this one better 😄 |
This reverts commit a38a289.
Thank you for opening this PR. It's great to see what needs to be done to switch to Interactivity API as the default way for developing core blocks.
We discussed some aspects of it in the private discussion, but let me summarize some talking points for transparency. The default behavior for view scripts changed in WordPress 6.1 release. That's when the conditional loading for the File block and the Navigation blocks regressed, and the scripts are always loading when the block is rendered. The changes proposed fix that logic, and it's a great win. The approach is quite good, and it should work in most of the cases. I hope it will work with all sites that extend those blocks, but we will see later if we miss something at the moment. The helper function sounds like a good idea only if we want to offer that solution as a general way for block developers to control enqueueing view scripts. We need to keep in mind that once this function lands in WordPress core plugins might start using it so we will have to maintain it for a long time. I'm not entirely sure if that's the intent here, as we can explore different ways that would allow achieve the same goal of changing how WordPress core works today. |
Oh, you're right. The way I understood it, this function was a workaround until we research a better way to do it. So maybe it doesn't make sense to create a function at this point. |
The body of the function works perfectly fine. It's probably an acceptable trade-off to have it duplicated in 3 blocks for now as it improves the performance for site visitors. |
This reverts commit 72e343f.
What?
I'm opening this pull request to be ready to remove the experimental flag for the Interactivity API and make the Navigation, File, and Image blocks use the Interactivity API by default. The idea is to ensure everything is ready for the moment we decide to remove the Experimental flag.
Why?
At this moment, users can only test the Interactivity API and its functionalities if they activate the Experimental flag in the Gutenberg Experiments page.
How?
These are the steps I took so far:
load.php
file.viewScript
field of theblock.json
of the Navigation, File, and Image blocks to read theinteractivity.js
file.view.js
files.index.php
of the Image and File blocks. At this moment they are still using the Tag Processor, but I want to explore which is the best approach.Testing Instructions