The WordPress Interactivity API provides a “framework” that allows developers to use predefined methods to add JavaScript interaction. Although the main functionality for developers is only provided in WordPress 6.5, a small part of it was introduced with WordPress 6.4 when the “Expand on click” function was introduced in the image block.
If you are a developer, take a look at the HTML code of the following image block. You will see an inline configuration for the Javascript functionality, with values and references to click handlers. These complex rules are applied to the block so that the interactivity API can interact with the content. (In this case, the image is enlarged when clicked).
The JavaScript file for the image block is over 5 KB in size, which is much heavier than a self-coded script for the same functionality. In addition, the base script for the API, which contains the functionality shared by all blocks, is over 30 KB in size. However, this is only loaded if there is a block on the page that requires it. This is good for performance. As long as the basic script remains this small in future versions, you can live with it. The larger scripts only come when you want to build more complex interactions based on this script.
The principle behind the API-a “standardised” way of programming interactive front-end functionalities such as button clicks, modals, etc.-is a good idea when a team is working together on such interactions. This makes it easier to ensure that the functionality is always developed in the same way by everyone involved.
However, there are also simpler ways to create this type of interaction: for example, simple Javascript or React. To learn frameworks like the new API, you need to learn several principles: the initial code (or principle) of Javascript, possibly the actual base React, as well as WordPress’ own API.
…the basis of this new API is Preact: a light version of React, which we have been using for our own projects for several years…
From discussions on Twitter/X, it turns out that the basis of this new API is Preact: a much lighter version of React that we’ve been using for our own projects for a few years now. It’s not yet clear how to mix the React approach with the API approach, or whether this is even possible or necessary. We will certainly keep an eye on this as soon as more code examples are available.
The speed of development is a key argument in favour of using such an API. Most people want to achieve goals faster. However, when using a framework, you have to make a decision about the trade-offs in terms of performance and complexity. You also need to bear in mind that you not only need to know and understand the principles behind the development of interactive elements, but also how you should use the interactivity API in the first place.
Fortunately, the documentation on WordPress.org is already quite extensive, but it definitely requires a reasonably good understanding of JavaScript and state management. (If you’re already using React, the ideas should sound familiar. However, if you already use React, you may not need this API at all).
…We want to ensure that our competences and projects are not limited by a dependency on WordPress’ own APIs…
Ideally, you would choose to learn the base language (JavaScript) and then use a framework where it benefits you. This is why we build web apps with Preact. We can accept the minimal technical overhead and this makes the creation of interactive views a lot less time consuming.
If we hadn’t already learnt Preact and React, this new API might make more sense… but only if we never wanted to build anything outside of the WordPress ecosystem. However, this is not the case for us: we also build complex interactive solutions completely without WordPress. Accordingly, we want to ensure that our expertise and projects are not limited by a dependency on WordPress’ own APIs.
If you want to learn portable skills-in this case, Javascript that works independently of WordPress-it’s better to create and implement code that isn’t always bound by the principles set by WordPress contributors. Mainly because the possibilities are more limited than with much more established solutions. It also means you are always reliant on the developers behind WordPress to fix the bugs they have introduced or add the features you need. Developers have been stumbling over the decisions of WordPress developers in the CSS area since the introduction of the Block Editor, especially since certain errors in thinking remain unresolved for a few years.
If you are familiar with writing JavaScript, you should not automatically use the interactivity API unless you want to submit your work to an official open source repository. If you do not have an established procedure for creating interactive elements, the new API is again an example of how to establish such a procedure.
One of the advantages of using the interactivity API is the reliance on a base code provided by a team of experts. This is a good reason to use it if you’re less experienced and want to put full focus on WordPress. However, many independent WordPress developers have found over the last five or six years that if they rely on the complicated codebase provided by WordPress developers, they become completely dependent on the quality of their work and their speed in solving problems. This has sometimes positive but also sometimes negative consequences for their own projects.
Conclusion
The new interactivity API is expected to be a great solution from experienced developers that will be made available to you free of charge under the open source licence. We are keeping a close eye on how the API is progressing and, once established, we will see how it can really make development work easier. As with the use of all third-party technology that we choose for our projects and our customers, we always weigh up the advantages and disadvantages.
