Skip to main content
wordpress supportwordpress support services

WordPress Contributors Propose New Interactivity API for Frontend Blocks

Over the past year a group of WordPress contributors have been working on making it easier for developers to build interactive blocks. These are the kinds of experiences that allow visitors to submit a form and get feedback without reloading the page, load paginated content without refreshing, and improve e-commerce stores with more dynamic responses based on visitor interaction.

A new proposal for an Interactivity API aims to provide a standard way for developers to add interactivity to the frontend, making it faster to build these experiences without reinventing the wheel every time.

Automattic-sponsored core contributor Mario Santos cast the vision for what the new API will deliver:

What if effortlessly creating performant, fluid, and idiomatic frontend interactivity on block-based WordPress sites was possible? Imagine plugins providing interactions like “heart this post” or “add to cart” without page reloads. Picture instant search, commenting, and native full-page transitions as best-in-class built-ins without complex scaffolding or external tools. Envision achieving this in any block theme by default without sacrificing PHP server rendering and the plugin ecosystem for a JS runtime. Visualize block developers easily declaring and extending such behaviors in a way that is immediately familiar and compatible with the block ecosystem.

Santos published a demo video accompanied by a live interactive demo where visitors can favorite movies and have the favorite count instantly updated in the block in the header. Pagination and search update the content without refreshing the page. The code for the demo is available on GitHub.

The Interactivity API is being created for use on the frontend of block-based websites but contributors may also explore the possibility of reusing some of its directives inside the editor. They are taking a similar approach to Alpine.js with “directives” that extend HTML with special attributes, except designed specifically for WordPress and backwards compatible with its APIs.

“The API is designed for the world of blocks and takes WordPress history of being closely attached to web standards to heart,” Santos said.

“As directives are added to the HTML, they work great with dynamic blocks and PHP.”

Having a standard in place means that WordPress developers don’t have to roll their own solutions for things like tooling, inter-block communication, and frontend performance. They would be primarily responsible for the block logic, making creating interactive blocks easier and more approachable for less experienced developers.

Contributors on the project have selected Preact to build the directives system due to its HTML-friendliness, small size, performance, extensibility, and compatibility with React.

The Interactivity API is currently in the stage of gathering feedback to incorporate in development as well as expanding technical documentation.

“Although it is now distributed as a plugin, it aims to be added as an experimental feature to Gutenberg,” Santos said. “The goal is to include it in Core once enough feedback has been gathered, and it’s clear that it’s the right direction.”

Initial reactions to the proposed API have been mostly positive, as developers have previously had to build their own solutions for interactivity in the absence of a standard.

“The Interactivity API is one of the most interesting proposals for WordPress frontend UX & DX that I’ve seen in awhile,” WordPress Core contributor Weston Ruter said.

“As someone who has been experimenting a lot with using AlpineJS, HTMX, Unpoly, StimulusJS, etc. for interactivity on the frontend, having a blessed solution in WP core would be most welcome,” another developer (@r1ckd33zy) commented.

WordPress developer and WPGraphQL contributor David Levine seemed less enthused about the approach outlined in the proposal. “Great idea but shortsighted execution,” Levine said. “We need an actual block data layer, not to further pollute our markup for our scripts to parse. This just exacerbates the same problems that got us into this mess.”

A few others in the comments of the post have been critical of the approach and others have questions about long term challenges of maintaining this approach.

“This is a pretty out-there which is quite a different approach to anything I’ve seen before,” WordPress core contributor Joe Hoyle said. “That does give me caution, as it’s very wp specific / centric. I think with the block editor there’s opportunity to align more with industry innovation around front-end tooling. I think it’s really great work and very creative; but again I’m not yet sure it’s the right direction. It could be that there’s no long term solution to bring an ‘nextjs’-ification to WordPress, but I’m not sure I’m looking at it.”

The proposal includes examples of how to create interactive blocks using the API and developers have opened a lively discussion on the approach. Contributors on the Interactivity API are planning to host two sessions on April 17, 2023 (one at 08:00UTC and another at 17:00UTC) that will include a live product demo followed by a Q&A. Check out the proposal for more details and the Interactivity API GitHub repo to see some experiments the team has been working on so far.