Add load_on_client_navigation option to wp_register_script_module

[samueljseay]

In ​https://github.com/WordPress/gutenberg/issues/70873 we find the need to selectively pre-load script modules for client side navigation with interactivity API's router to ensure that we don't load modules that are not needed.

To that end, we should add a load_on_client_navigation option in the $args of wp_register_script_module that can be selectively enabled for interactivity API blocks as suggested in the solution presented here: ​https://github.com/WordPress/gutenberg/issues/70873#issuecomment-3377500106

https://core.trac.wordpress.org/ticket/64097

[westonruter]

I'm not sure this should be part of core yet. Isn't the client navigation navigation still just an experiment in Gutenberg? I think we should rather use filters in Gutenberg to add the desired data attribute to the SCRIPT tag. This can be done via the wp_script_attributes filter.

I'm not sure this should be part of core yet. Isn't the client navigation navigation still just an experiment in Gutenberg? I think we should rather use filters in Gutenberg to add the desired data attribute to the SCRIPT tag. This can be done via the wp_script_attributes filter.

This crossed my mind as well, thanks for raising that. @luisherranz what are your thoughts about that approach?

Region-based client-side navigation has been in WordPress Core since WordPress 6.5 and has been used successfully in blocks like the Query block or WooCommerce's Product Collection. Full-page client-side navigation is what is experimental in Gutenberg.

​WordPress 6.9 will include a new algorithm for region-based client-side navigation that replaces not only the HTML but also the CSS, and loads any JavaScript required by blocks appearing on the new page.

For now, to be safe, we'd like to load only the script modules that we know belong to interactive blocks, so we need a way to identify them in the HTML.

@luisherranz I think the filter can still be used for that purpose?

Namely, we know the script module IDs which are going to be used for interactive blocks, so then a wp_script_attributes filter can look at the id attribute to see if it is among the relevant script modules, and then add the new data attribute. This seems like a better way to start than to expose this new load_on_client_navigation arg on the public interface for all users to be made aware of, which won't be relevant to any user except this one use case internally for core, as I understand. Since this seems like a very internal use case, it seems like it would be better to keep it internal at least for now.

Sounds good to me. We can try that 🙂

I'll go ahead and close this for now in favor of trying a filter approach instead.

[westonruter]

Per ​https://github.com/WordPress/wordpress-develop/pull/10236#issuecomment-3409553102