{"id":121600,"date":"2026-02-23T21:43:54","date_gmt":"2026-02-23T21:43:54","guid":{"rendered":"https:\/\/make.wordpress.org\/core\/?p=121600"},"modified":"2026-03-11T17:22:22","modified_gmt":"2026-03-11T17:22:22","slug":"changes-to-the-interactivity-api-in-wordpress-7-0","status":"publish","type":"post","link":"https:\/\/make.wordpress.org\/core\/2026\/02\/23\/changes-to-the-interactivity-api-in-wordpress-7-0\/","title":{"rendered":"Changes to the Interactivity API in WordPress 7.0"},"content":{"rendered":"

New watch()<\/code> function<\/h3>\n\n\n\n

WordPress 7.0 adds a watch()<\/code> function to the @wordpress\/interactivity<\/code> package. This brand-new function subscribes to changes in any reactive value accessed inside a callback\u2014and reruns it anytime those values change.<\/p>\n\n\n\n

Now, you can tie the Interactivity APIAPI<\/span> 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.<\/span><\/span><\/span>\u2019s data-wp-watch<\/code> to a DOM element\u2019s 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()<\/code> function fills this gap.<\/p>\n\n\n

\nimport { store, watch } from '@wordpress\/interactivity';\n\nconst { state } = store( 'myPlugin', {\n    state: {\n        counter: 0,\n    },\n} );\n\n\/\/ Runs immediately and re-runs whenever `state.counter` changes.\nwatch( () => {\n    console.log( 'Counter is ' + state.counter );\n} );\n<\/pre><\/div>\n\n\n
The function returns an unwatch<\/code> callback that stops the watcher:<\/p>\n\n\n
\nconst unwatch = watch( () => {\n    console.log( 'Counter is ' + state.counter );\n} );\n\n\/\/ Later, to stop watching:\nunwatch();\n<\/pre><\/div>\n\n\n
The callback can also return a cleanup function that runs before each re-execution and when unwatch()<\/code> disposes of the watcher:<\/p>\n\n\n
\nconst unwatch = watch( () => {\n    const handler = () => { \/* ... *\/ };\n    document.addEventListener( 'click', handler );\n\n    return () => {\n        document.removeEventListener( 'click', handler );\n    };\n} );\n<\/pre><\/div>\n\n\n
See #75563<\/a> for more details.<\/p>\n\n\n\n
Props to @<\/span>luisherranz<\/a> for the implementation.<\/p>\n\n\n\n
Deprecated state.navigation<\/code> properties in core\/router<\/code><\/h3>\n\n\n\n
The state.navigation.hasStarted<\/code> and state.navigation.hasFinished<\/code> properties in the core\/router<\/code> 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.<\/p>\n\n\n\n
Starting in WordPress 7.0, accessing state.navigation<\/code> from the core\/router<\/code> store is deprecated<\/em><\/strong> and will trigger a console warning in development mode (SCRIPT_DEBUG<\/code>). 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.<\/p>\n\n\n\n
See #70882<\/a> for more details.<\/p>\n\n\n\n
Props to @<\/span>yashjawale<\/a> for the implementation.<\/p>\n\n\n\n
state.url<\/code> from core\/router<\/code> is now populated on the server<\/h3>\n\n\n\n
Previously, you initialized state.url<\/code> in the core\/router<\/code> store on the client by setting it to window.location.href<\/code>. That meant the value was undefined<\/code> until the @wordpress\/interactivity-router<\/code> module finished loading asynchronously, and you had to guard against that initial undefined<\/code> state and filterFilter<\/span> Filters are one of the two types of Hooks https:\/\/codex.wordpress.org\/Plugin_API\/Hooks<\/a>. 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.<\/span><\/span><\/span> out the subsequent initialization. Or else things would reactReact<\/span> React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces.\rhttps:\/\/reactjs.org<\/a><\/span><\/span><\/span> to it as an actual navigation.<\/p>\n\n\n\n
Starting in WordPress 7.0, this value is populated on the server during directive processing. So its value doesn\u2019t change until the first client-side navigation occurs.<\/p>\n\n\n\n
And that means you can combine watch()<\/code> and state.url<\/code> to reliably track client-side navigations, for example, to send analytics on every virtual page view:<\/p>\n\n\n
\nimport { store, watch } from '@wordpress\/interactivity';\n\nconst { state } = store( 'core\/router' );\n\nwatch( () => {\n    \/\/ This runs on every client-side navigation.\n    sendAnalyticsPageView( state.url );\n} );\n<\/pre><\/div>\n\n\n
See #10944<\/a> for more details.<\/p>\n\n\n\n
Props to @<\/span>luisherranz<\/a> for the implementation.<\/p>\n
#<\/span>7-0<\/a>, #<\/span>dev-notes<\/a>, #<\/span>dev-notes-7-0<\/a>, #<\/span>interactivity-api<\/a><\/p>