How about API? Let’s Check this example.
$id = 'plugin-id';
$syffix = ( ( defined( 'SCRIPT_DEBUG' ) && SCRIPT_DEBUG ) ? '' : '.min' );
$script_url = plugins_url( 'js/' .$id . $suffix . '.js', __FILE__ );
$dependencies = array( 'jquery', 'underscore' );
wp_register_script( $id, $script_url, $dependencies, $version, true );
wp_localize_script( $id, 'pluginJSL10nData', array(
'home' => trailingslashit( get_home_url() ),
'matches' => __( 'Hello World!', 'plugin-id' ),
) );
wp_enqueue_script( $id );
-
$id
is ID for our script, we can unregister it later (after we declare it, but didn’t use) if we change our mind. -
$script_url
can point to different scripts -
$dependencies
easy to include or exclude dependencies. -
$version
we can change the version on script update, and in this case client will be forced to load the new version. -
true
orfalse
(footer or header), where to include your script.. on your choice. -
wp_localize_script
you also van provide additional js variables for your script work, in case if you depend on some specific data. (natively it suppose to be used only for providing localization for your script, but you limited only by your imagination.) -
wp_enqueue_script
or not. it depends on you to use the script you register or not.
in other words wp_register_script
, wp_enqueue_script
and wp_register_script
provide you api to flexibly use your scripts.