Blocks: Introduce a way to enqueue view scripts only when needed for interactivity

[gziolo]

It's based on the discussion started by @felixarntz in ​https://github.com/WordPress/wordpress-develop/pull/5262#discussion_r1336258326 when reviewing the current handling for interactive blocks back ported from the Gutenberg plugin for WordPress 6.4 Beta 1.

As of today, the view scripts get enqueued during block rendering in WP_Block::render:

​https://github.com/WordPress/wordpress-develop/blob/6a61084beca680a78ed581d035d76d592d4ef117/src/wp-includes/class-wp-block.php#L271-L274

The custom code used with all core blocks applies the optimization by ensuring that these view scripts are only listed for enqueuing when the block instance of a given type is going to need them. For example, in the Image block, the view script is only useful when the Lightbox feature is activated for the block. There can be multiple block instances of the same type, so the view script gets removed from the list when the functionality isn't used. However, as soon as any block instance needs it, it must be added and never removed.

The reason why we didn't go with wp_enqueue_script() and wp_dequeue_script() is that the script handle would still need to get removed from view_script_handles for the block type as it gets automatically registered through block.json and later enqueued in the code path shared in the snippet above. It would still have to be manually enqueued when it is needed.

In the long run, I hope we can develop some sort of automatic detection based on Interactivity API directives that would inform whether a view script is necessary for the block. It could even allow us to introduce new strategies that allow loading scripts based on some triggers like: when a user hovers over a UI element or when the UI element is visible on the screen.

[luisherranz]

It could even allow us to introduce new strategies that allow loading scripts based on some triggers like: when a user hovers over a UI element or when the UI element is visible on the screen.

I started a discussion about lazy loading support a few months ago here:

​https://github.com/WordPress/gutenberg/discussions/52723

I plan to work on all this after WP 6.4 is released.

[chaion07]

Thanks @gziolo for reporting this. We reviewed this ticket during a recent bug-scrub session. Although this ticket needs a patch and seeing no progress in recent time, we would request @luisherranz to look into this if possible. Cheers!

Props to @mukesh27 & @luisherranz

[luisherranz]

I haven't started exploring how to describe the assets required for an interactive block yet.

In my opinion, this is not a 1:1 relation (one block, one set of assets) like what we have now in block.json, but more of a 1:many relation where one block could have multiple interactive behaviors on the frontend, and the user should be able to choose and configure them in the UI. Third-party plugins should also be able to add new behaviors to existing blocks.

Related to this, @westonruter has started exploring how to lazy load interactive blocks:

• ​https://github.com/WordPress/gutenberg/pull/58284

[audrasjb]

As per today's bug scrub. Since this ticket is still waiting for a patch proposal, moving it to the next milestone to give it more time.

[oglekler]

Hi @luisherranz could you please provide an update on the status of this ticket? We have about 2 weeks until Beta 1, even though Gutenberg is usually merged later, it's better to know if this feature will be in the release or not. Thank you!

[luisherranz]

As far as I know, no, but @gziolo might have more details.

[nhrrob]

We have reviewed in today's bug scrub.
Feedback from @hellofromTonya :
I'd suggest: Add the gutenberg-merge keyword, punt, and comment for the reason of punting, i.e. the patch is still in draft mode and hasn't yet been merged into or tested in Gutenberg. Also comment: if done in time, okay to put back into the milestone.

I am not seeing the gutenberg-merge keyword!

Punting to 6.7.

[flixos90]

@luisherranz @westonruter Not having much familiarity with the idea of lazy hydration myself, do you think ​https://github.com/WordPress/gutenberg/pull/58284 could be a solution to this ticket?

Are there blockers on that PR or is it just a matter of getting back to it?

[luisherranz]

do you think ​https://github.com/WordPress/gutenberg/pull/58284 could be a solution to this ticket?

I don't think so. Solving this ticket would require us to come up with a way to determine when a block has an interactive behavior and which assets (CSS, JavaScript) are associated with that behavior to enqueue them.

Are there blockers on that PR or is it just a matter of getting back to it?

That PR doesn't have any blockers, as far as I know.

[westonruter]

Should the scope here include not just the initial enqueueing of the dependent assets (scripts and styles) but also deferring the loading of them until they are needed? For example, the view script for the lightboxed Image block doesn't need to be loaded until the Image block is scrolled into the viewport.

This is where there is an intersection with lazy-hydration since the interactive island doesn't need to be initialized either until the block enters the viewport, the same as the scripts aren't needed until the block is in the viewport. As I understand, the process would be that once a block enters the viewport (1) download the scripts required by the block, and then (2) perform hydration.

This is also related to client-side navigation, as navigating to a page with an interactive block would also require its assets to be downloaded (but ideally not downloaded immediately but rather delayed until the block is in the viewport, especially for view script modules).