Update strategy for adding script[type="text/partytown"] to worker scripts
#1497
Conversation
thelovekesh
added
[Type] Enhancement
thelovekesh
added
the
no milestone
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
| wp_scripts()->registered[ $dep->handle ]->deps[] = 'web-worker-offloading'; | ||
|
|
There was a problem hiding this comment.
I don't think we technically have to do this because when a script is made into a text/partytown script, it won't by definition do anything until the Partytown script has been loaded on the page. So the Partytown script could be located anywhere (and ideally it should always be in the footer!) But I suppose the benefit of doing this way is it would get added automatically. Still I think there could be a wp_print_footer_scripts action that checks if any of the enqueued scripts require WWO, and if so, it could then ultimately print the Partytown script in the footer.
| wp_scripts()->registered[ $dep->handle ]->deps[] = 'web-worker-offloading'; |
There was a problem hiding this comment.
I've refactored this in 0c2d7b2 to use the print_scripts_array filter to inject the web-worker-offloading script on demand. This has slight performance benefits as it doesn't require looping over all registered scripts and can instead just look at the scripts that have been enqueued for printing.
| if ( false === wp_scripts()->get_data( $dep->handle, 'strategy' ) ) { | ||
| wp_script_add_data( $dep->handle, 'strategy', 'async' ); // The 'defer' strategy would work as well. | ||
| wp_script_add_data( $dep->handle, 'wwo_strategy_added', true ); | ||
| } |
There was a problem hiding this comment.
We may need to end up removing this logic if we are going to rely on inline after scripts also being made Partytown scripts as mentioned in #1455. But that can be done in another PR.
There was a problem hiding this comment.
I'll address this in another PR.
… update/wwo-script-strategy
| } | ||
| add_action( 'wp_enqueue_scripts', 'wwo_init' ); | ||
| add_action( 'wp_default_scripts', 'wwo_register_default_scripts' ); |
| * | ||
| * @since 0.1.0 | ||
| * | ||
| * @param string[]|mixed $script_handles Array of script handles. | ||
| * @return string[] Array of script handles. | ||
| * @param string[]|mixed $to_do An array of enqueued script dependency handles. |
There was a problem hiding this comment.
why is $script_handles changed to $to_do?
There was a problem hiding this comment.
Ah, because this is the name of the param passed to print_scripts_array. But I can change it back.
|
Thanks @westonruter for taking this to finish line ❤️ |
Summary
Fixes #1468
Relevant technical choices
wp_script_add_data( $handle, 'worker', true )to identify worker offloading scripts instead of identifying them byweb-worker-offloadingscript dependency.web-worker-offloadingscript duringwp_default_scriptsinstead ofwp_enqueue_scriptsso that it can be used in the admin and to more closely align with how scripts are registered in core.print_scripts_arrayfilter to prepend theweb-worker-offloadingscript to the list of scripts being printed if one is offloaded to a worker. This is more performant than adding a script dependency at theprint_scripts_arrayaction since it only needs to iterate over the queued script handles as opposed to iterating over all registered scripts.