Make WordPress Core

Opened 8 months ago

Last modified 8 days ago

#59462 assigned enhancement

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

Reported by: gziolo's profile gziolo Owned by:
Milestone: 6.6 Priority: normal
Severity: normal Version: 6.4
Component: Editor Keywords:
Focuses: Cc:

Description

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.

Change History (8)

#1 @luisherranz
8 months ago

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.

This ticket was mentioned in Slack in #core by chaion07. View the logs.


4 months ago

#3 @chaion07
4 months ago

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

#4 @luisherranz
4 months ago

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:

Last edited 4 months ago by luisherranz (previous) (diff)

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


3 months ago

#6 @audrasjb
3 months ago

  • Milestone changed from 6.5 to 6.6

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.

#7 @oglekler
9 days ago

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!

#8 @luisherranz
8 days ago

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

Note: See TracTickets for help on using tickets.