Changes to the Interactivity API in WordPress 7.0

New watch() function

WordPress 7.0 adds a watch() function to the @wordpress/interactivity package. This brand-new function subscribes to changes in any reactive value accessed inside a callback—and reruns it anytime those values change.

Now, you can tie 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.’s data-wp-watch to a DOM element’s lifecycle and use that for reacting to state changes. But how would a process observe those changes programmatically, independently of the DOM? How could you set something up to run side effects at the store level, set up logging, or synchronize state between stores? The watch() function fills this gap.

import { store, watch } from '@wordpress/interactivity';

const { state } = store( 'myPlugin', {
    state: {
        counter: 0,
    },
} );

// Runs immediately and re-runs whenever `state.counter` changes.
watch( () => {
    console.log( 'Counter is ' + state.counter );
} );

The function returns an unwatch callback that stops the watcher:

const unwatch = watch( () => {
    console.log( 'Counter is ' + state.counter );
} );

// Later, to stop watching:
unwatch();

The callback can also return a cleanup function that runs before each re-execution and when unwatch() disposes of the watcher:

const unwatch = watch( () => {
    const handler = () => { /* ... */ };
    document.addEventListener( 'click', handler );

    return () => {
        document.removeEventListener( 'click', handler );
    };
} );

See #75563 for more details.

Props to @luisherranz for the implementation.

Deprecated state.navigation properties in core/router

The state.navigation.hasStarted and state.navigation.hasFinished properties in the core/router store were always intended as internal implementation details. Used for the loading bar animation, they were never intended to be part of the public API.

Starting in WordPress 7.0, accessing state.navigation from the core/router store is deprecated and will trigger a console warning in development mode (SCRIPT_DEBUG). Plus, in a future version of WordPress, direct access will not work at all. WordPress 7.1 will add an official mechanism for tracking navigation states.

See #70882 for more details.

Props to @yashjawale for the implementation.

state.url from core/router is now populated on the server

Previously, you initialized state.url in the core/router store on the client by setting it to window.location.href. That meant the value was undefined until the @wordpress/interactivity-router module finished loading asynchronously, and you had to guard against that initial undefined state and filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. out the subsequent initialization. Or else things would reactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org to it as an actual navigation.

Starting in WordPress 7.0, this value is populated on the server during directive processing. So its value doesn’t change until the first client-side navigation occurs.

And that means you can combine watch() and state.url to reliably track client-side navigations, for example, to send analytics on every virtual page view:

import { store, watch } from '@wordpress/interactivity';

const { state } = store( 'core/router' );

watch( () => {
    // This runs on every client-side navigation.
    sendAnalyticsPageView( state.url );
} );

See #10944 for more details.

Props to @luisherranz for the implementation.

#7-0, #dev-notes, #dev-notes-7-0, #interactivity-api