[wp-trac] [WordPress Trac] #59462: Blocks: Introduce a way to enqueue view scripts only when needed for interactivity

[WordPress Trac]

#59462: Blocks: Introduce a way to enqueue view scripts only when needed for
interactivity
-----------------------------+-----------------------
 Reporter:  gziolo           |       Owner:  (none)
     Type:  enhancement      |      Status:  assigned
 Priority:  normal           |   Milestone:  6.7
Component:  Editor           |     Version:  6.4
 Severity:  normal           |  Resolution:
 Keywords:  gutenberg-merge  |     Focuses:
-----------------------------+-----------------------

Comment (by gziolo):

 > 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.

 Yes, that sounds reasonable to look at it holistically, including all the
 ideas discussed in
 https://github.com/WordPress/gutenberg/discussions/52723. Overall,
 @westonruter you shared some good talking points that need to be taken
 into account.

 Related to that, there is
 [https://github.com/WordPress/gutenberg/issues/48382 another GitHub issue]
 where the topic of improved developer experience touches on the utils for
 enqueueing scripts and view scripts for blocks. We are now transition to
 script modules, so there might be similar need for view script modules.

 One aspect that I was thinking about recently is how much we should
 inverse the control to offer an improved strategy, at least for
 Interactive API stores. There are now a few indicators in place that we
 could consider when optimizing how and when script modules get enqueued.
 To give some examples:
 - when there is no `data-wp-interactivity` attribute printed on the page
 then there is no need to load Interactivity API runtime
 - it's possible to detect which stores are necessary based on the
 directives used, example code:
   - `$p->set_attribute( 'data-wp-interactive', 'core/image' );`
   - `$p->set_attribute( 'data-wp-on--click',
 'core/query::actions.navigate' );` - this one is more complex as it
 requires a store from another block
 - everything custom located in `viewScriptModule` files that runs outside
 of the store probably needs different handling

 So, an interesting path for exploration would be having a wholly revised
 strategy when the Interactivity API runtime loads automatically when there
 is any interactive region on the page. It would be responsible for
 deciding when to load individual stores that interactive islands need to
 operate as intended. To follow the example of the lightbox in the Image
 block, if the decision is to load that store when the block is in the
 viewport, then the runtime would handle everything deferring loading the
 script module with `core/image` store. The only missing ingredient would
 be some sort of config that would allow to map the store name to the
 specific file on the disk so it can be dynamically imported and consumed
 by the runtime.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59462#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform