Updates to the Interactivity API in 6.6

The Interactivity APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. development for WordPress 6.6 has been focused on maintenance. Its updates include new features and directives, a better debugging experience, and improved code quality.

Table of Contents

New async directives

WordPress 6.6 includes three new directives aimed at improving performance:

  • data-wp-on-async
  • data-wp-on-async-document
  • data-wp-on-async-window

These async directives optimize event callbacks by first yielding to the main thread. That way, complex interactions won’t contribute to long tasks, improving the Interaction to Next Paint (INP). You can read more about this approach in Optimize Interaction to Next Paint.

These directives are recommended over the sync ones (data-wp-ondata-wp-on-document, and data-wp-on-window), but you can use them only when you don’t need synchronous access to the event object, specifically if you need to call event.preventDefault()event.stopPropagation(), or event.stopImmediatePropagation(). The directives in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks have been updated to use async where available.

When you must resort to using the non-async directives, the @wordpress/interactivity package now exports a splitTask function which can be used to manually split yield an action to the main thread after calling the synchronous event API. Please see the documentation on async actions for how to implement this.

GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ pull requests: #61885 and #62665

Support for derived state props inside wp_interactivity_state

Since WordPress 6.5, developers can define the initial state of interactive blocks in the server with wp_interactivity_state(). Directives referencing these state properties are evaluated to render the final HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.. However, derived state props, defined as getters in JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/., were a feature missing in PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher.

In WordPress 6.6, the wp_interactivity_state() function now accepts derived state props using Closures (anonymous functions). This feature is equivalent to the getters already used in JavaScript inside the store() function exposed from the @wordpress/interactivity package.

const { state } = store( 'myPlugin', {
	state: {
		taxRate: 0.21,
		shippingFee: 4,
		get priceWithTax() {
			const context = getContext();
			return context.basePrice * ( 1 + state.taxRate );
		},
		get totalPrice() {
			return state.priceWithTax + state.shippingFee;
		}
} );

In the same way, the Closures can access the current Interactivity API context by calling the new wp_interactivity_get_context() function―equivalent to their JavaScript version, getContext(). This function returns the current context for either the current namespace―when omitted―or the specified one. Also, wp_interactivity_state() can be used when the value depends on other parts of the state.

wp_interactivity_state( 'myPlugin', array(
	'taxRate'      => 0.21,
	'shippingFee'  => 4,
	'priceWithTax' => function() {
		$state = wp_interactivity_state();
		$context = wp_interactivity_get_context();
		return $context['basePrice'] * ( 1 + $state['taxRate'] );
	},
	'totalPrice'   => function() {
		$state = wp_interactivity_state();
		return $state['priceWithTax']() + $state['shippingFee'];
	}
) );

It’s important to note that using Closures for derived state is not always necessary. When the initial value is static, and the Closure will always return the same value because the values it depends on do not change on the server, regular values can be used instead:

$basePrice    = 100;
$taxRate      = 0,21;
$shippingFee  = 4;
$priceWithTax = $basePrice * ( 1 + $taxRate );
$totalPrice   = $priceWithTax + $shippingFee;

wp_interactivity_state( 'myPlugin', array(
	'basePrice'    => $basePrice,
	'taxRate'      => $taxRate,
	'shippingFee'  => $shippingFee,
	'priceWithTax' => $priceWithTax,
	'totalPrice'   => $totalPrice,
) );

Read more about this new feature on the TRACTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #61037 and in the GitHub Issue #6394

Integration with Preact Devtools

The Interactivity API runtime uses Preact internally to transform directives into components and manage all DOM updates. Since WordPress 6.6, developers can use Preact Devtools to inspect interactive blocks and check the component tree for all rendered directives.

To enable this feature, the SCRIPT_DEBUG constant must be enabled. This constant makes WordPress serve an extended version of the Interactivity API runtime that’s compatible with the Preact dev tools.

In the future, there are plans to improve the displayed information by including the names of the directives used in each of the elements, among other enhancements.

Read more about this new feature on the TRAC ticket #61171 and in the GitHub PR #60514

Interactivity API warnings in 6.6

In WordPress 6.6, both the server-side directives processing and the JavaScript runtime will warn developers when the directives, the namespace, or the markup cannot be evaluated.

To enable this feature, the SCRIPT_DEBUG constant must be enabled.

Warning messages will be shown for the following cases:

Unbalanced HTML tags

If the processed HTML contains any unbalanced tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.), the server processing will bail out. This causes the flash effect on page load. Now, developers will find which tag is missing within a warning message.

One example could be <span data-wp-text=”hello” />

Unsupported HTML tags

Some tags, like SVG or MathML ones, are not yet supported by the HTML API, which is used internally by the Interactivity API. Directives inside them or in their inner tags won’t be server-side processed. Now, a warning will appear if any directives are found in those positions.

Non-parseable data inside data-wp-context

The context data provided to data-wp-context directives must be a valid JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. stringified object.

Invalidinvalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid. namespace inside data-wp-interactive

The value passed to data-wp-interactive directive cannot be an empty object {}, an empty string, or a null value. Namespaces must be non-empty strings.

Props to @darerodz, @westonruter and @luisherranz for co-authoring this post
and to @fabiankaegy and @juanmaguitar for review

#6-6, #dev-note, #dev-notes, #dev-notes-6-6, #interactivity-api