Add function to pass variables to scripts

Since WordPress 5.7 using wp_localize_scripts to pass variables to registered scripts throws a _doing_it_wrong notice.

I don't see a general _doing_it_wrong notice. I do see a notice if the value is not an array.

I don't believe there's any general warning about using wp_localize_script(). If you provide a reproducible example of how the warning is generated, I'm happy to take a look.

I agree with much of your feedback about how data is passed to scripts. However, with these with these systems established, in place, and generally working well, it's hard to advocate to add another different system without really compelling justification.

One note, Script Modules, use a different system that's simpler. ​You can read about it here.

@jonsurrell There is a downside to using wp_localize_script() in that it casts all top-level array items to strings, because this function is intended for i18n data. See #25280. Really, the better way to pass arbitrary data from PHP to a classic script is to use wp_add_inline_script(), although the DX is slightly less ergonomic.

<?php
wp_localize_script( $handle, 'foo', $data );

vs

<?php
wp_add_inline_script(
    $handle, 
    sprintf( 'var foo = %s;', wp_json_encode( $data, JSON_HEX_TAG | JSON_UNESCAPED_SLASHES ) ),
    'before'
);

Thanks @westonruter, I didn't know that!

For what it's worth, I much prefer the ​"pull" style of passing data that's used by script modules with the script_module_data_{$module_id} filter. Some advantages:

• The browser does not evaluate the script contents at all because it's not a JavaScript script tag.
• The data is parsed and used on demand when necessary by the script that requires it.
• No use of a shared global JavaScript namespace.

There's potential for improvement for classic scripts, but I'd be very wary of adding a third pattern for passing data to classic scripts. If anything, we could consider porting the script modules form to scripts to avoid a new pattern, but share an existing pattern.

I'll reopen for a second opinion.

@jonsurrell What if we take your approach for script modules and make it available to classic scripts as well?

Before printing any inline before/localize/translations scripts in WP_Scripts, we apply script_data_{$handle} filters to obtain any data intended to be exported from PHP to JS, and then construct a JSON script to print first? This will then be available for classic scripts to parse out of the textContent on demand.

I think that's a good idea since there are benefits over the existing options wp_add_inline_script() or wp_localize_script(). I'm concerned about introducing a third pattern that may not actually get much usage. Do you have ideas about how we could measure interest and impact?

It may be interesting to introduce the filter in Gutenberg and migrate some important scripts to use it. That could provide information about whether there's any impact and it's worth continuing.

@jonsurrell I've used the emoji loader as a case study for this in #63842. By eliminating the blocking inline script, I see a >5% improvement on LCP when emulating a low-tier mobile device.

Thanks for that exploration, it's very promising!

​This is on the dev chat agenda to discuss today. If there are no objections raised, this should be ready to move ahead with development.

This is ready for deveopment. The Script Modules implementation is here and can serve as inspiration:

https://core.trac.wordpress.org/browser/tags/6.8.2/src/wp-includes/class-wp-script-modules.php#L443

The implementation should be similar to the Script Modules implementation. I'd say the script tag containing the data should be printed before extra scripts (those added by wp_localize_script().

In 60899: