Changes between Initial Version and Version 1 of Ticket #59462, comment 15
- Timestamp:
- 09/13/2024 12:08:20 PM (10 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #59462, comment 15
initial v1 3 3 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. 4 4 5 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.5 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 transitioning to script modules, so there might be similar need for view script modules. 6 6 7 7 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: … … 10 10 - `$p->set_attribute( 'data-wp-interactive', 'core/image' );` 11 11 - `$p->set_attribute( 'data-wp-on--click', 'core/query::actions.navigate' );` - this one is more complex as it requires a store from another block 12 - everything custom located in `viewScriptModule` filesthat runs outside of the store probably needs different handling12 - everything custom, located in `viewScriptModule` files, that runs outside of the store probably needs different handling 13 13 14 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.14 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.