Changelog - Tracking Breaking Changes in the Interactivity API

[luisherranz]

The Interactivity API is an ongoing initiative that aims to standardize the creation of interactive blocks. You can read the detailed proposal here. It's important to note that this API is currently in an experimental phase, which implies that we are in the process of rapid iteration and occasional introduction of breaking changes.

Testing & Feedback

We would be thrilled if you decide to test out this innovative API. We highly value all forms of feedback on the API as it directly contributes to our progress. However, due to the possibility of breaking changes, it is crucial to stay informed before updating Gutenberg.

Subscribe to this discussion

In order to facilitate this, we will update this discussion on every new version release of Gutenberg. This will primarily focus on detailing the changes in the Interactivity API, especially the breaking ones, and providing necessary guidance for migrating your code to the new versions.

If you are testing the Interactivity API, we strongly recommend subscribing to this discussion. Remember, do not update Gutenberg until you have confirmed whether there are any breaking changes in the latest release. If such changes exist, make sure to adjust your code according to the migration guidance provided below prior to updating Gutenberg.

---

Template for updates

Gutenberg: X.X.X (Release Date)

@wordpress/interactivity version: X.X.X (changelog)

Breaking Changes

• Change 1: From previous behavior -> To new behavior (Migration steps)
• Change 2: From previous behavior -> To new behavior (Migration steps)

Non-Breaking Changes

• New feature or bug-fix 1
• New feature or bug-fix 2

[luisherranz]

Gutenberg: 16.2.1 (Jul 13, 2023)

@wordpress/interactivity version: 1.1.0 (changelog)

Initial version.

[luisherranz]

Gutenberg: 16.3.0 (Jul 26, 2023)

@wordpress/interactivity version: 1.2.0 (changelog)

Non-Breaking Changes

• Runtime support for the data-wp-style directive. (#52645)

---

It's safe to upgrade to the 16.3.0 version.

[luisherranz]

Gutenberg: 16.4 (Aug 9, 2023)

@wordpress/interactivity version: 2.0.0 (changelog)

Breaking Changes

• Remove the wp-show directive until we figure out its final implementation. (#53240)

---

Migration instructions

You can replace wp-show with data-wp-bind--hidden.

Before:

<div data-wp-show="context.isOpen">
  This is only shown when `context.isOpen` is `true`.
</div>

After:

<div data-wp-bind--hidden="!context.isOpen">
  This is only shown when `context.isOpen` is `true`.
</div>

Notice that the value of hidden is reserved and it's hidden on false and unhidden on true. For that reason, using ! is required to reverse the boolean (!context.isOpen).

The hidden attribute doesn't work if the element has a display CSS property. In that case, you can use data-wp-style--display to set an inline display that overrides the other one.

The value of display is not true and false, but none and inherit. So you might need to create a selector as well:

Before:

<div data-wp-show="context.isOpen">
  This is only shown when `context.isOpen` is `true`.
</div>

After:

<div data-wp-style--display="selector.isOpen">
  This is only shown when `context.isOpen` is `true`.
</div>

store({
  selectors: {
    isOpen: ({ context }) => (context.isOpen ? "inherit" : "none"),
  },
});

We'll add wp-show back once the implementation is stable. The discussion is happening here.

[luisherranz]

Gutenberg: 16.5.0 (Aug 23, 2023)

@wordpress/interactivity version: 2.1.0 (changelog)

Non-Breaking Changes

• Allow passing optional afterLoad callbacks to store calls. (#53363)

---

It's safe to upgrade to the 16.5.0 version.

[luisherranz]

Gutenberg: 16.6.0 (Sep 6, 2023)

@wordpress/interactivity version: 2.2.0 (changelog)

Non-Breaking Changes

• Support region-based client-side navigation. (#53733)
• Support keys using data-wp-key. (#53844)
• Merge new server-side rendered context on client-side navigation. (#53853)
• Improve data-wp-bind hydration to match Preact's logic. (#54003)
• Add new directives that implement the Slot and Fill pattern: data-wp-slot-provider, data-wp-slot and data-wp-fill. (#53958)

⚠️ The slot/fill directives are very experimental and most likely subject to change. Please, use with care!

---

It's safe to upgrade to the 16.6.0 version.

[luisherranz]

Gutenberg: 16.7.0 (Sep 27, 2023)

@wordpress/interactivity version: 2.3.0 (changelog)

Non-Breaking Changes

• Improve navigate() to render only the result of the last call when multiple happen simultaneously. (#54201)
• Remove role attribute when set to null in data-wp-bind. (#54608)
• Add timeout option to navigate(), with a default value of 10000 milliseconds. (#54474)

---

It's safe to upgrade to the 16.7.0 version.

[luisherranz]

Gutenberg: 16.8.0 (Oct 11, 2023)

@wordpress/interactivity version: 2.4.0 (changelog)

---

No updates. It's safe to upgrade to the 16.8.0 version.

[luisherranz]

Gutenberg: 16.9.0 (Oct 25, 2023)

@wordpress/interactivity version: 2.5.0 (changelog)

---

No updates. It's safe to upgrade to the 16.9.0 version.

[luisherranz]

Gutenberg: 17.0.0 (Nov 9, 2023)

@wordpress/interactivity version: 2.6.0 (changelog)

Non-Breaking Changes

• Update the title when using enhanced pagination. (#55446)

---

It's safe to upgrade to the 17.0.0 version.

[luisherranz]

Gutenberg: 17.1.0 (Nov 22, 2023)

@wordpress/interactivity version: 2.7.0 (changelog)

---

No updates. It's safe to upgrade to the 17.1.0 version.

[luisherranz]

Gutenberg: 17.2 (Dec 6, 2023)

@wordpress/interactivity version: 3.0.0 (changelog)

Breaking Changes

• New store() API:
  • Proposal.
  • PR.
• Rename data-wp-effect to data-wp-watch:
  • Proposal
  • PR
• Modules and Import Maps:
  • Proposal
  • Tracking Issue
  • PR

---

Migration instructions

1. New store() API

1. Namespaces are now defined in the data-wp-interactive directive

   Instructions: Move your namespace to the data-wp-interactive directive, and remove it from the rest of the directives and their references.

   Before:

   <div data-wp-interactive>
     <div data-wp-context='{ "myPlugin": { "isOpen": false } }'>
       <span data-wp-bind--hidden="context.myPlugin.isOpen">Hi there 👋</span>
     </div>
   </div>

   After:

   <div data-wp-interactive='{ "namespace": "myPlugin" }'>
     <div data-wp-context='{ "isOpen": false }'>
       <span data-wp-bind--hidden="context.isOpen">Hi there 👋</span>
     </div>
   </div>

2. Namespaces are now defined once for the whole store

   Instructions: Move your namespace to the first parameter of the store() call and remove it from the properties.

   Before:

   store({
     state: {
       myPlugin: {
         someValue: "...",
       },
     },
     actions: {
       myPlugin: {
         someAction() {
           // ...
         },
       },
     },
   });

   After:

   store("myPlugin", {
     state: {
       someValue: "...",
     },
     actions: {
       someAction() {
         // ...
       },
     },
   });

3. Callbacks don't get the store as a parameter anymore

   The store() call now returns the store object for that namespace.

   Instructions: To access the properties of the store, destructure one of the calls to store().

   Before:

   store({
     state: {
       myPlugin: {
         someValue: "...",
       },
     },
     actions: {
       myPlugin: {
         someAction({ state }) {
           state.myPlugin.someValue; // "..."
         },
       },
     },
   });

   After:

   const { state } = store("myPlugin", {
     state: {
       someValue: "...",
     },
     actions: {
       someAction() {
         state.someValue; // "..."
       },
     },
   });

4. Callbacks don't get the context as a parameter anymore

   Instructions: To access the context, use the new getContext() function.

   Before:

   store({
     actions: {
       myPlugin: {
         someAction({ context }) {
           context.myPlugin.someValue; // "..."
         },
       },
     },
   });

   After:

   store("myPlugin", {
     actions: {
       someAction() {
         const context = getContext();
         context.someValue; // "..."
       },
     },
   });

5. Callbacks don't get the DOM element as a parameter anymore

   Instructions: To access the DOM element, use the new getElement() function, which returns it in a property called ref.

   Before:

   store({
     actions: {
       myPlugin: {
         someAction({ ref }) {
           ref.focus();
         },
       },
     },
   });

   After:

   store("myPlugin", {
     actions: {
       someAction() {
         const { ref } = getElement();
         ref.focus();
       },
     },
   });

6. Derived state now is created using getters

   Instructions: Move the selectors to state and use getters instead of regular functions.

   Before:

   store({
     state: {
       myPlugin: {
         counter: 1,
       },
     },
     selectors: {
       myPlugin: {
         double({ state }) {
           return state.counter * 2;
         },
       },
     },
   });

   After:

   const { state } = store("myPlugin", {
     state: {
       counter: 1,
       get double() {
         return state.counter * 2;
       },
     },
   });

   Getters can also use getContext or getElement.

   Before:

   store({
     selectors: {
       myPlugin: {
         someText({ context }) {
           return context.isOpen ? "close" : "open";
         },
       },
     },
   });

   After:

   const { state } = store("myPlugin", {
     state: {
       get someText() {
         const { isOpen } = getContext();
         return isOpen ? "close" : "open";
       },
     },
   });

   When getters are used in other callbacks, there is no need to pass the store anymore.

   Before:

   store({
     state: {
       myPlugin: {
         counter: 1,
       },
     },
     selectors: {
       myPlugin: {
         double({ state }) {
           return state.counter * 2;
         },
       },
     },
     actions: {
       myPlugin: {
         someAction(store) {
           const { selectors } = store;
           console.log(selectors.myPlugin.double(store));
         },
       },
     },
   });

   After:

   const { state } = store("myPlugin", {
     state: {
       counter: 1,
       get double() {
         return state.counter * 2;
       },
     },
     actions: {
       someAction() {
         console.log(state.double);
       },
     },
   });

7. Remove state from wp_store (temporary change)

   We are still working on the migration from wp_store to wp_initial_state. Once that work is finished, the new API will be like this.

   Before:

   wp_store( array(
     'state' => array(
       'myPlugin' => array(
         'someValue'  => 'some value',
         'someNumber' => 123,
       ),
     ),
     'selectors' => array(
       'myPlugin' => array(
         'someDerivedValue' => 'some derived value',
       ),
     ),
   ) );

   After:

   wp_initial_state( 'myPlugin', array(
     'someValue'        => 'some value',
     'someNumber'       => 123,
     'someDerivedValue' => 'some derived value',
   ) );

   Instructions: We will try to ship the new wp_initial_state function in GB 17.3, but in the meantime, you can keep using wp_store without the state property.

   Before:

   wp_store( array(
     'state' => array(
       'myPlugin' => array(
         'someValue'  => 'some value',
         'someNumber' => 123,
       ),
     ),
     'selectors' => array(
       'myPlugin' => array(
         'someDerivedValue' => 'some derived value',
       ),
     ),
   ) );

   After:

   wp_store( array(
     'myPlugin' => array(
       'someValue'  => 'some value',
       'someNumber' => 123,
       'someDerivedValue' => 'some derived value',
     ),
   ) );

8. Accessing other namespaces

   Instructions: To reference other namespaces in the directives, you can use the new :: syntax.

   <div data-wp-interactive='{ "namespace": "myPlugin" }'>
     <span data-wp-bind--hidden="state.isOpen">
       I'm using the default namespace ("myPlugin")
     </span>
     <span data-wp-bind--hidden="otherPlugin::state.isOpen">
       I'm using the "otherPlugin" namespace
     </span>
   </div>

   Instructions: To access the state or actions of other namespaces, you can now use the store() function.

   const otherPlugin = store("otherPlugin");
   
   const { state, actions } = store("myPlugin", {
     actions: {
       someAction: () => {
         otherPlugin.state.someValue;
         otherPlugin.actions.someAction();
       },
     },
   });

   Instructions: To access the context of other namespaces, you can pass the namespace to the getContext() function.

   store("myPlugin", {
     actions: {
       someAction: () => {
         const myContext = getContext();
         const otherContext = getContext("otherPlugin");
       },
     },
   });

9. Async actions are created using generators

   Because of the way we internally hook scoped functions like getContext() to action or derived state executions, we need to take control of asynchronous actions. That is not possible using async/await, but fortunately, it's possible when using generators. There's a longer explanation for the reasons behind this change in the new store() API proposal.

   Instructions: Replace async with * and await with yield.

   Before:

   store({
     actions: {
       myPlugin: {
         async someAction() {
           await fetch("...");
         },
       },
     },
   });

   After:

   store("myPlugin", {
     actions: {
       *someAction() {
         yield fetch("...");
       },
     },
   });

   Even though this syntax change is necessary, you can keep thinking about these actions as async functions because they are automatically converted.

   const { actions } = store("myPlugin", {
     actions: {
       *someAction() {
         yield fetch("...");
       },
       *otherAction() {
         yield actions.someAction();
       },
     },
   });
   
   const externalFunction = async () => {
     // You can use them in external functions as well.
     await actions.someAction();
   };

2. Rename data-wp-effect to data-wp-watch

Instructions: Replace data-wp-effect with data-wp-watch.

The internals haven't changed, so the referenced callbacks will keep working exactly as before.

Before:

<div data-wp-effect="effects.someSideEffect"></div>

After:

<div data-wp-watch="effects.someSideEffect"></div>

In our Core blocks and documentation, we have also changed the naming convention of the effects property and replaced it with the callbacks property to better accommodate the usage of these types of side effects outside of the data-wp-effects directive, but that's not enforced or mandatory:

store("myPlugin", {
  callbacks: {
    someSideEffect() {
      // Some logic...
    },
  },
});

<div data-wp-watch="callbacks.someSideEffect"></div>

3. Modules and Import Maps

Starting from Gutenberg 17.2, the @wordpress/interactivity package will only be exposed as an ES module.

This means that the window.wp.interactivity global is gone and if you want to access the APIs, you have to use a module that can access @wordpress/interactivity using the import map.

Before:

<script src="/wp-content/plugins/gutenberg/.../interactivity.js" defer></script>
<script src="/wp-content/plugins/my-plugin/.../view.js" defer></script>

// import { store } from '@wordpress/interactivity';
// Converted to this syntax by the DependencyExtractionWebpack plugin.
const { store } = window.wp.interactivity;

After:

<script type="importmap">
  { "imports": {
      "@wordpress/interactivity": "/wp-content/plugins/gutenberg/.../interactivity.js"
  } }
</script>
<script type="module" src="/wp-content/plugins/my-plugin/.../view.js"></script>

import { store } from "@wordpress/interactivity";

There is no support for modules in neither wp-script or block.json yet, but we will work on it. In the meantime, our recommendation is:

1. Remove your view.js from the viewScript field of the block.json.

2. Use the new gutenberg_register_module function right after your register_block_type call, and register the original file (not the one in the build folder) with the @wordpress/interactivity dependency:

   function my_plugin_register_block() {
     register_block_type( __DIR__ . '/build' );
   
     gutenberg_register_module(
       'my-plugin-block-view',
       plugin_dir_url( __FILE__ ) . 'src/view.js',
       array( '@wordpress/interactivity' ),
       '0.1.0'
     );
   }
   add_action( 'init', 'my_plugin_register_block' );

3. Use the new gutenberg_enqueue_module function in your render_callback or render.php:

   <?php
   gutenberg_enqueue_module( 'my-plugin-block-view' );
   ?>
   
   <div ...>
     ...
   </div>

If you have multiple files and you need to bundle them into a single one, our recommendation is to use esbuild with the bundle: true option.

---

If you have questions or if something is not working as expected, feel free to open a new discussion in the Interactivity API category.

[luisherranz]

Gutenberg: 17.3.0 (Dec 20, 2023)

@wordpress/interactivity version: 3.1.0 (changelog)

---

We haven't finished working on wp_initial_state so there are now new updates yet. It's safe to upgrade to the 17.3.0 version.

[luisherranz]

Gutenberg: 17.4.0 (Jan 3, 2024)

@wordpress/interactivity version: 3.1.0 (changelog)

---

We still haven't finished wp_initial_state, so no new updates yet. It's safe to upgrade to the 17.4.0 version.

[luisherranz]

Gutenberg: 17.5 (Jan 17, 2023)

@wordpress/interactivity version: 3.2.0 (changelog)

Breaking Changes

• Implement wp_initial_state(). (57556)

Enhancements

• Interactive template: Use viewModule. (57712)

---

Migration instructions

1. wp_initial_state

wp_store has been removed and replaced with wp_initial_state.

Previously:

wp_store( array(
  'state' => array(
    'myPlugin' => array(
      'isOpen' => false
    )
  )
));

Now:

wp_initial_state( 'myPlugin', array(
  'isOpen' => false
));

Important: we will likely rename it again to wp_interactivity_state in the near future. You can follow this PR if you are interested.

2. viewModule

You can now start using the new viewModule property in your block.json instead of manually registering and enqueuing the module with gunteberg_register_module and gutenberg_enqueue_module:

{
  "viewModule": "file:./view.js"
}

The only change required is to add --experimental-modules to the wp-scripts commands. Your package.json should be:

{
  "scripts": {
    "build": "wp-scripts build --experimental-modules",
    "start": "wp-scripts start --experimental-modules"
  }
}

[luisherranz]

Gutenberg: 17.6 (Jan 31, 2023)

@wordpress/interactivity version: 4.0.1 (changelog)

We've made more changes than usual in preparation for the WP 6.5 release.

Breaking Changes

• Create @wordpress/interactivity-router module. (57924)
• Interactivity Router: Replace data-wp-navigation-id with data-wp-router-region. (58191)
• Prevent the use of components in wp-text. (57879)
• Remove data-wp-navigation-link directive. (57853)
• Remove data-wp-slot and data-wp-fill. (57854)
• Remove unused state and rename props to attributes in getElement(). (57974)

Enhancements

• Add data-wp-on-window and data-wp-on-document directives. (57931)
• Add wp-each directive. (57859)
• Add wp-run directive and useInit & useWatch hooks. (57805)
• Render the root interactive blocks. (57729)
• Interactivity: Export withScope() and allow to use it with asynchronous operations. (58013)
• Server Directive Processing Refactor. (58066)
• Update preact, @preact/signals and deepsignal dependencies. (57891)

Bug fixes

• Prevent data-wp-on="" from creating onDefault handlers. (57925)

---

Migration instructions

1. The new core/router store

Instead of importing navigate and prefetch from @wordpress/interactivity, you should import the new core/router store from @wordpress/interactivity-router.

Previously:

import { navigate, prefecth } from "@wordpress/interactivity";

const { state } = store("myPlugin", {
  actions: {
    *navigate() {
      const { attributes } = getElement();
      state.isLoading = true;
      yield navigate(attributes.href);
      state.isLoading = false;
    },
    *prefetch() {
      const { attributes } = getElement();
      yield prefecth(attributes.href);
    },
  },
});

Now:

import { actions } from "@wordpress/interactivity-router";

const { state } = store("myPlugin", {
  actions: {
    *navigate() {
      const { attributes } = getElement();
      state.isLoading = true;
      yield navigate(attributes.href);
      state.isLoading = false;
    },
    *prefetch() {
      const { attributes } = getElement();
      yield actions.prefecth(attributes.href);
    },
  },
});

Doing this will download the router when the page loads, which is not usually required. Instead, you can import the store dynamically. You can also prefetch the store.

const { state } = store("myPlugin", {
  actions: {
    *navigate() {
      const { attributes } = getElement();
      state.isLoading = true;
      const { actions } = yield import("@wordpress/interactivity-router");
      yield navigate(attributes.href);
      state.isLoading = false;
    },
    *prefetch() {
      const { attributes } = getElement();
      const { actions } = yield import("@wordpress/interactivity-router");
      yield actions.prefecth(attributes.href);
    },
  },
});

2. Replace data-wp-navigation-id with data-wp-router-region

data-wp-navigation-id has been renamed to data-wp-router-region.

Previously:

<div data-wp-navigation-id="<?php echo wp_unique_id('myPlugin-'); ?>">
  ...
</div>

Now:

<div data-wp-router-region="<?php echo wp_unique_id('myPlugin-'); ?>">
  ...
</div>

3. Prevent the use of components in wp-text

Using components as the input of data-wp-text was possible.

Previously:

store("myPlugin", {
  state: {
    Comp: (props) => h("img", props),
  },
});

<div data-wp-text="state.Comp"></div>

Now this is not possible anymore. We will study the addition of another directive that is better suited for this purpose.

4. Remove data-wp-navigation-link directive

The data-wp-navigation-link directive has been removed. Use navigate and prefecth from the new core/router store (@wordpress/interactivity-router) from now on.

5. Remove data-wp-slot and data-wp-fill

The experimental data-wp-slot and data-wp-fill directives have been removed. We will add them back once we figure out how to process them on the server.

6. Remove unused state in getElement()

The experimental state in getElement() has been removed. Keep using data-wp-context instead.

7. Rename props to attributes in getElement()

We renamed props to attributes in getElement().

Previously:

<button data-wp-on--click="actions.sendAnalytics" data-event-name="some event">
  ...
</button>

store("myPlugin", {
  actions: {
    sendAnalytics() {
      const { props } = getElement();
      analyticsLibrary.sendEvent(props["data-event-name"]);
    },
  },
});

Now:

store("myPlugin", {
  actions: {
    sendAnalytics() {
      const { attributes } = getElement();
      analyticsLibrary.sendEvent(attributes["data-event-name"]);
    },
  },
});

8. Rename wp_initial_state to wp_interactivity_state

With the new WP_Interactivity_API class, all the related functions have been namespaced with wp_interactivity, including the one to set the initial state.

Previously:

wp_initial_state( 'myPlugin', array(
  'someState' => 'some state'
));

Now:

wp_interactivity_state( 'myPlugin', array(
  'someState' => 'some state'
));

[DAreRodz]

Gutenberg: 17.7 (Feb 14, 2024)

@wordpress/interactivity version: 5.0.0 (changelog)

Breaking changes

• Remove key and name arguments from data-wp-style and data-wp-class. (#58835).
• Remove the data-wp-body directive. (#58835)

Non-breaking changes

• Break up init with yielding to main to prevent long task from hydration. (#58227)
• Support setting the namespace using a string in data-wp-interactive, like data-wp-interactive="myPlugin". (#58743)
• Avoid initializing private stores as public when they have initial state. (#58754)
• Interactivity API: Remove non default suffix data wp context processing. (#58664)

---

Migration instructions

1. Remove key and name arguments from data-wp-style and data-wp-class

These directives passed a key and name arguments, respectively, while evaluating the directive value. As that value usually points to a state or context property or a getter instead of a function, no further action would be needed as they don't receive any arguments.

2. Remove data-wp-body

That directive rendered interactive HTML inside the <body> tag from an arbitrary part of the DOM tree. We removed it to leverage the runtime size and simplify the public API. If you need to render anything inside<body>, please use a WP filter in PHP like wp_footer.

[DAreRodz]

Gutenberg: 17.8 (Feb 28, 2024)

@wordpress/interactivity version: 5.1.0 (changelog)

Non-breaking changes

• Only add proxies to plain objects inside the store. (#59039)
• Improve context merges using proxies. (59187)

---

It's safe to upgrade to the 17.8.0 version.

[DAreRodz]

Gutenberg: 17.9 (Mar 13, 2024)

@wordpress/interactivity version: 5.2.0 (changelog)
@wordpress/interactivity-router version: 1.3.0 (changelog)

Breaking changes

• Rename data_wp_context function. (59465)

Non-breaking changes

• Fix navigate() issues related to initial state merges. (57134)
• Fix context object proxy references. (59553)
• Improve context merges using proxies. (59187)
• Prevent unwanted subscriptions to inherited context props. (59273)

---

Migration instructions

1. Rename data_wp_context function

The name of this utility function has changed to wp_interactivity_data_wp_context in order to make it consistent with other Interactivity API-related functions (e.g., wp_interactivity_state, wp_interactivity_config).

Previously

?>
<button
    data-wp-interactive="myblock"
    data-wp-on--click="actions.doSomething"
    <?php echo data_wp_context( array( 'isClicked' => false ) ); ?>
>Click me!</button> 

Now:

?>
<button
    data-wp-interactive="myblock"
    data-wp-on--click="actions.doSomething"
    <?php echo wp_interactivity_data_wp_context( array( 'isClicked' => false ) ); ?>
>Click me!</button> 

[DAreRodz]

Gutenberg: 18.0 (Mar 27, 2024)

@wordpress/interactivity version: 5.3.0 (changelog)
@wordpress/interactivity-router version: 1.4.0 (changelog)

Non-breaking changes

• Prevent non-objects from being set in store state. (#59886)
• Ensure that stores are available for subscription before hydration. (#59842)
• Ensure scope is restored when catching exceptions thrown in async generator actions. (#59708)
• Backport fixes from Core. (59903)
• Re-introduce data_wp_context() with _deprecated_function() call. (59834)

---

It's safe to upgrade to the 18.0 version.

[DAreRodz]

Gutenberg: 18.1 (Apr 10, 2024)

@wordpress/interactivity version: 5.4.0 (changelog)
@wordpress/interactivity-router version: 1.5.0 (changelog)

---

There are no changes in the Interactivity API; upgrading to the 18.1 version is safe.

[DAreRodz]

Gutenberg: 18.2 (Apr 24, 2024)

@wordpress/interactivity version: 5.5.0 (changelog)
@wordpress/interactivity-router version: 1.6.0 (changelog)

Non-breaking changes

• Include preact/debug when SCRIPT_DEBUG is enabled. (#60514)
• Return useMemo and useCallback hooks. (#60474)
• Allow multiple event handlers for the same type with data-wp-on. (#60661)
• Update the query block to permit non-core interactive blocks. (#60006)
• Interactivity API refactor to TypeScript (utils & kebabToCamelCase). (#60149)

---

It's safe to upgrade to the 18.2 version.

[DAreRodz]

Gutenberg: 18.3 (May 8, 2024)

@wordpress/interactivity version: 5.6.0 (changelog)
@wordpress/interactivity-router version: 1.7.0 (changelog)

Non-breaking changes

• Add full-page client-side navigation experiment setting. (#59707)

---

It's safe to upgrade to the 18.3 version.