#77 – Mario Santos and Luis Herranz on What the Interactivity API Is and How You Can Use It

[00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox has a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes and in this case, how you can start to make your sites more interactive.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast, player of choice, or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you, and hopefully get you or your idea featured on the show. Head to WPTavern.com forward slash contact forward slash jukebox, and use the form there.

So on the podcast today, we have Mario Santos and Luis Herranz. They both work for Automattic but are sponsored to work full-time in WordPress.

The main focus of their work is the block developer experience, and they are part of the group of contributors that worked on the Interactivity API proposal.

The Interactivity API is the main focus of the podcast today, and if you’re working with blocks and dynamically displaying data, this is sure to be of interest to you.

We start out the podcast today with the usual introductions, and get to know Mario and Luis. And then we learn what the Interactivity API is and what it can do.

The conversation is framed around a blog post written by Mario entitled, The interactivity API, a better developer experience in building interactive blocks.

In this Mario shows examples of what website interactivity is. In short, it’s the ability for content to be amended on the fly without a page refresh. Of course, this is nothing new on the web. We’ve been seeing this for years in WordPress sites and elsewhere. But now you’re going to be able to create interactivity in a standard way across the different blocks on your site.

The project hopes to absorb complexity and make the creation of interactive objects fairly trivial. Mario and Luis talk about examples of where the API might be used, and how it can be implemented.

We also discussed the fact that in the past developers have gone their own way to make their sites interactive. It all works, but it means that no two implementations are the same. This causes issues if the project is taken over by another developer. But it’s also a drain on resources.

Mario and Luis make the point that having a standard way of creating interactivity will benefit everyone in the long run. We get into the weeds a little and talk about the approach the team took when building the API. They decided to use directives and we find out why this was, and what benefit it brings over other possible solutions.

The project is still experimental, and they’re looking for people to test and report back on what they find to move the interactivity API forwards.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to. WPTavern.com forward slash podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you Mario Santos and Luis Herranz.

I am joined on the podcast today by Luis Herranz and Mario Santos. Hello.

[00:04:15] Luis Herranz: Hey, hello Nathan.

[00:04:16] Mario Santos: Thanks for inviting us.

[00:04:18] Nathan Wrigley: You’re so welcome. We had an introduction on Slack from Anne McCarthy, who listeners to the podcast may very well have heard of, and she wanted me to chat to these two about the Interactivity API, so we’re going to get onto that. It’s a brand new project. Could be very interesting if you’re a developer implementing it, but also if you’re an implementer of WordPress websites and not a developer, you’ll be interested in the outcomes of it.

Before we do that, the usual questions at the beginning. I’m going to go to Luis first, if that’s all right. Would you mind just giving us your backstory, how you’ve come to be on a WordPress podcast, how long you’ve been working with WordPress, who you work for as much or as little as you wish.

[00:04:57] Luis Herranz: Okay, thank you. I started creating websites with WordPress 2010, I think, maybe nine, I don’t know, a long time ago. And I wanted to start a company in 2013, with Pablo Postigo. And we thought, okay, we wanted to create native apps for different companies, like services and so on.

And we knew WordPress, so we basically started with what was later known as headless WordPress, but back in 2013. And since then we iterated, we created a team. We got some investment and we started doing things on top of WordPress. Mostly in headless. First with native applications. Then we moved to just web have applications, but still on headless. Very focused on React.

And in 2019 we launched a open source framework for headless WordPress, powered by React. So we were very focused on developer experience and performance.

And in 2021, that company, Frontity was acquired by Automattic, so we could become like full-time contributors and focus on, well, basically what the Interactivity API proposal is today. Bringing some of those user experiences, what are possible with other solutions, to WordPress itself, on top of full site editing, or block themes.

[00:06:31] Nathan Wrigley: Thank you so much. That’s really interesting. I appreciate your nice history there. Thank you. And we’ll ask the same question this time of Mario. So Mario, backstory please.

[00:06:41] Mario Santos: Thank you. Actually, my story is really similar to Luis. Well first, when I finished the degree, I studied industrial engineer, but I didn’t want to be an engineer. So I started trying different things, and while I got my first job, I created a store in WordPress with WooCommerce. And then, that is when I started to learn about WordPress and all those things.

And later, based on that, I joined Frontity. I don’t remember exactly the year, 2015 maybe. And from there I really learned what was WordPress because we started going to meetups to WordCamps, and we started to, well at least I started to learn from the community.

From there the story is mostly the same as Luis. We were working on headless mainly. We were working with WordPress. And at some point, we were acquired by Automattic, and now I’m a sponsored contributor, working full-time. And as Luis said, we are focused on the developer experience, and the Interactivity API that we are going to talk about is part of it.

[00:07:45] Nathan Wrigley: Thank you so much for that. So the Interactivity API, I’m going to link in the show notes to a post which you can find. Now the post you’re going to be looking at is on the make.wordpress.org website. It’s written by Mario. It was on the 30th of March, 2023 that came out, and it’s entitled, Proposal, The Interactivity API, A Better Developer Experience in Building Interactive Blocks.

Now, if at any point during this podcast you become a little bit confused or you wish to have some more background, I would recommend pausing and going and reading what is an incredibly lengthy and detailed post, with actually a boatload of interaction and comments as well. It’s really heartening to see so many people chipping in, and giving their thoughts on this Interactivity API.

But I guess the best place to kick this conversation off simply asking, what is it? What is the Interactivity API? What does it do? Why does WordPress need such a thing?

[00:08:47] Mario Santos: I can start with this one. So, the Interactivity API is what we are proposing. The group of contributors that are working on that. It’s basically a new standard system to easily add front end interactivity to your blocks. Until now, most of the Gutenberg APIs have been focused on the block editor side, and there was unintentional gap on the front end.

So block developers could choose whatever they want. They could choose any Javascript framework, or other solutions. And the Interactivity API aims to cover that gap. Creating this standard.

So imagine functionalities like, like this post or e-commerce functionalities like add to cart, or the checkout, the instant search, page transitions, the comments form, without a page reload. So those are the user experiences that the Interactivity API aims to cover.

In a way that is real easy to build them, and block developers don’t have to deal with complex scaffolding or external tools. And it’s important to note also that it’s completely familiar and compatible with PHP and the block ecosystem. So overall, that’s what the Interactivity API is. Basically a standard to easily create any interactive experience that your users want.

[00:10:06] Nathan Wrigley: Luis, anything to add?

[00:10:09] Luis Herranz: No, it’s really filling that gap, or even that opportunity of absorbing as much complexity from the developers. Standardizing everything in a single solution, and making sure that it’s performant, and so on.

So yeah, there’s some advancement in web development in other places, mostly in the Javascript ecosystem and WordPress has never been opinionated in the front end, so this is kind of the first time for WordPress.

But yeah, we think that it’s an opportunity as well to absorb a lot of complexity for the developers, and to enable some of the user experiences that were not possible with WordPress before.

[00:10:52] Nathan Wrigley: Now we have some show notes, and we’ve got a list of questions that we’re potentially going to run through, but I’m going to skip to the end, more or less of the list of our questions. Because one of the things I think to do at the beginning would be to provide listeners concrete examples of how this might be used.

So do you have any examples that you think would demonstrate clearly the kind of things that the Interactivity API is touching on? I’ll just mention one. Which is the very first thing you’re going to see more or less when you open up Mario’s article, and it’s a video. It’s pretty short, two minutes long. And it demonstrates something a little bit like Netflix, where you’ve got, a view of three or four different video thumbnails. There’s a bunch of different movies there.

And the intention is that you would like to preserve your favorites. And so there’s a little heart icon, which is lodged in the top left of the thumbnails for each video. And as you click on that thumbnail, the heart becomes colored in. It goes from gray to red. But also in a different part of the UI, in the right hand of the view, the menu, traditional place for the menu, there’s a little total which goes up from two to three to four, and if you remove the hearts, it goes back down to two and so on and so forth.

So that’s one example of how you might use this. It’s able to do things on the page without needing to do page refreshes. And the idea is that this will be a standard way of doing it in blocks. And I wonder if you could give us some other examples. You mentioned WooCommerce and things like that. But let’s go into that a little bit. Some examples of where this might be useful for developers and end users to know.

[00:12:35] Mario Santos: Yeah, so basically the use case is anything that is interactive and requires Javascript should be able to be done with the Interactivity API in an easy way. So imagine like a slide show or light boxes in the image. So when you click on it, it zooms, and when you click out or scroll, it goes out. Some models like search, subscription, quizzes, e-commerce integrations, like you just have mentioned.

And one of the features that is enabled by having a standard is the client site navigation that basically is navigating through different pages of your WordPress site without triggering a page reload.

It’s important to know that this is something that is going to be enabled by the Interactivity API, but it’s going to be completely optional. So if you don’t need it, you don’t have to use it. But it powers other features like you can see in the movie, that we are paginating between the different pages. We are in the query loop. You have the pagination block, and you can go through the page one to the page two without page reload.

And for example, well, in the movies demo, we are showing that you can play the trailer and you can keep navigating and the video doesn’t stop. So those kind of user experiences that, for example, in this podcast you could be listening to this podcast in WP Tavern, and you could navigate to the articles.

So, maybe you can be reading an article while you are listening to the podcast in the same way. And the podcast will keep playing. Those kind of user experiences are enabled by client side navigation. And you can also find in the movies the instant search that you start typing and the list of results is automatically updated.

Infinite scroll could also work. Client size submissions like the comments form right now, in typical WordPress sites, when you submit a new comment, it triggers a page load. So this could be done directly in the client. So those are the kind of user experiences that we are talking about. And yeah, I think it’s important that this is totally compatible with the current block templating system. So whatever you change in the editor is going to keep working.

[00:14:54] Nathan Wrigley: That’s great, yeah. Luis, anything to add?

[00:14:57] Luis Herranz: I would add that I really like that demo. Because it’s a demo that we didn’t come up with. It was a demo that existed before. There is a version of that demo created with all the major Javascript frameworks out there. So there is one for React using Next, Vue using Nuxt, Svelte, Quick, Astro and so on.

So, you can compare now the WordPress version with the other Javascript frameworks, out there. I’m super happy to say that it really, in terms of user experience now with Interactivity API, you can provide the same user experience than the others. And this demo was created to show these type of complex or great user experiences.

With WordPress, now with the Interactivity API, you’re able to create that type of user experience, but leveraging the server side and the block editor. So the other Javascript frameworks version is 100% code, where this movies demo version of WordPress is done with Gutenberg and everything is a block, and you can go and change wherever you want. Which we think it’s really powerful.

And there’s yet another thing there, in comparing with the other frameworks, and it’s that if you look at the performance is a top performer there. It’s only 13 kilobytes of Javascript. Only a new experimental mode of Solid is able to be as performant as that one. So yeah, I’m really happy about enabling those user experiences, but with full compatibility with the Block editor and block themes, and with such performance.

[00:16:44] Nathan Wrigley: It’s true to say, I guess, that if you go to that demo, you will not be seeing anything that you haven’t seen somewhere else online. You’ve seen the ability to like things, and you’ve seen infinite scroll before, and you’ve seen elsewhere online the ability to paginate without a full page refresh, and you’ve seen comments being added, again without having to submit a new page and so on and so forth.

But this is creating a standard inside of WordPress. Why did you feel it was important to do this? Why not just leave developers to do their own thing? Again, we’ve seen WordPress websites implementing this. You know, I’ve been to countless WordPress websites where I’ve seen these features.

Clearly somebody’s dealt with it before and implemented it in their own way. I guess you’re just trying to make it so that everybody can build on top of the work that you are doing, rather than everybody going off in their own way and implementing a completely different solution based upon, well, however they wish to do it?

[00:17:43] Luis Herranz: Yes. It’s about absorbing complexity. So, definitely anything you can imagine, it’s possible with WordPress. The thing is how easy is to do it. And with this kind of standard, our hope is that those user experiences are not only easy, but also working practically out of the box.

[00:18:05] Nathan Wrigley: I’m guessing that this standard is going to be something that you are aiming at developers. Presumably the developers will then make it fairly straightforward for end users to interact with blocks and what have you, to make this available to them. But how would the standard actually work? What is going on in the background? How are developers going to implement this?

[00:18:25] Mario Santos: If I can add one note to the why this standard, is I think it’s also important to note apart from what Luis says, is that it absorbs a lot of complexity. In an ecosystem like WordPress where there are a lot of plugins interacting with other plugins and those kind of experiences that we have.

It’s important that following a standard enables things like block communication. For example, we can see what we were talking about in the demo that you are liking a movie and it’s updating another block, in another place. So if different blocks, created by different block developers, in different plugins are not using the same approach, it’s really difficult to be able to communicate those blocks. And having a standard solves that. And yeah, that composability and compatibility to nest the structures of different interactive blocks is possible thanks to a standard.

[00:19:21] Nathan Wrigley: Right. Okay, so you’re really opening it up so that any block developer can implement this so that, I don’t know, a different block developer can hook into the exact same standards so that two completely separate blocks, created by completely separate individuals can have interaction via the Interactivity API, right?

[00:19:42] Mario Santos: Yeah, that’s it.

[00:19:43] Luis Herranz: And they also use this, the same code, the same framework. Because if each block developer starts choosing their own framework, maybe some developers like React, some developers like Vue, some developers like Svelte or whatever comes next. Then WordPress sites could end up loading a lot of unnecessary Javascript.

So yeah, it’s important. Now that sites are, are a mix of blocks from different developers, these blocks are like small units. Yeah, it’s important to agree on a single kind of solution.

[00:20:17] Nathan Wrigley: Yeah, good point. Okay, so how is it actually going to work then? You mentioned in the article, and I think one of you mentioned it just a moment ago, that you’re trying to make it so that people are familiar with PHP, don’t necessarily have to get into the whole space of learning React or what have you. I’m not entirely clear on what the position is there, but is the intention to make this as simple as possible for people who are steeped in WordPress’s PHP history.

[00:20:44] Mario Santos: Yes. We wanted to make it as easy as possible to everyone. So yeah, that’s included. And yes, we said this is compatible with PHP, and it has been designed to be block first and PHP friendly. So yeah, it’s should be easy.

And going back to the question, how this standard work. Basically a system based on directives. I’m not sure, for those who are not familiar with directives, they are a way to extend HTML. They are custom HTML attributes that tell the Interactivity API to attach a specified behavior to a DOM element, or even transform it. So for those familiar with Alpine. it’s really similar, but it has been designed to work with WordPress.

[00:21:32] Nathan Wrigley: I know it’s potentially a bit on the technical side, but you talked about the CSS nature of things there. I’m wondering if you can give an example of how that might be implemented. What would you actually be doing, declaring those directives?

[00:21:47] Mario Santos: Okay, in order to create an interactive block using Interactivity API, you have to add directives to your markup. So you have some HTML, so you add custom attributes that are directives, and they call an action that is defined in Javascript in the view.js file of your block.

[00:22:06] Nathan Wrigley: What is the benefit of doing it in that way? You mentioned that you want it to be available to everybody. Is this the kind of thing that, obviously experienced developers can probably pick this up in a heartbeat, but are you trying to get people, how do we describe this, who are less experienced say. Is this going to be something that you could pretty quickly learn even if your developer chops are not all that impressive?

[00:22:29] Luis Herranz: Yes. The initial goal for this proposal is more enabling user experiences for WordPress that were not possible before, or were very difficult to do before. We also have a focus on developer experience, but that’s something that we think we can also keep improving over time.

This doesn’t have to be like the final API of creating blocks. We can work, keep working on simplifying things over time. For example, right now none of these touches like the editor part. So if you are creating a block, the edit is just, is still done in the same way that it is done today using a React component. But maybe in the future we can explore how we can kind of extend these directives also to the editor and if it makes sense to unify and simplify the templating for both use cases. But is not the main goal of this proposal at this moment right now.

[00:23:32] Nathan Wrigley: When you were making decisions about this, and you decided to go with directives instead of things like using React or something. Was there quite a lot of toing and froing? Was there a lot of soul searching, what the best way to do it was? Or was it just fairly straightforward from the very beginning that using directives was the way you were going to do it? How long did the conversation take before you settled on this? is it fair to say that everybody’s on board with this? This seems to be the way to do it.

[00:23:58] Mario Santos: We believe so. I mean, we have researched a lot of alternatives. Actually, as we mentioned, we come from Frontity, that it was a React framework. React was like the first alternative we had in mind, but we defined as a list of requirements and we started researching different possibilities, and at the end we come up with the solution to be the only one that it was the only one fully compatible with WordPress.

Just to explain this a bit better. As directives are custom attributes that we have in the HTML, we are using the HTML as the templating system. And this comes with many benefits, for example, were not possible with React. As HTML is the templating system, the service rendering is supported by default, for example.

That is something really important in WordPress, or WordPress, APIs like WordPress hooks, that we are used to WordPress hooks in plugins, to extend some functionality, or translations. Those things, with directives using the HTML as the templating system work out of the box. And we can keep using those APIs to even extend the directives.

And I think this was one of the main blockers to not use React. This system, the service rendering is supported, and the WordPress API are supportive as well. That using other approaches can get tricky or even impossible, I would say.

[00:25:32] Luis Herranz: Yes. I think we spent like a year or so researching this. And at first we tried with Javascript, JSX, or even JS templates like Vue or Svelte, and so on. But yeah, I think that that direction, things start getting like super complex. And once we switched to using HTML as the templating language, it was like boom. Like everything works out of the box. Everything is like super simple. Everything is compatible. So yeah, it was like seeing the light a little bit.

[00:26:04] Nathan Wrigley: if I’m a current block developer, there’s obviously now going to be this conflict of, do I carry on with what I’ve been doing so far? I’ve got some kind of interactive component in my blocks. Do I carry on with what I’ve been doing up until this point? Or do I flip over and start using the Interactivity API?

You’ve obviously just mentioned some reasons why that could be the case. But I’m wondering if there is anything else buried in there. In other words, what’s the use case to switch? There’ll be a bit of retooling, you might have to rewrite a whole bunch of stuff that you’ve already rewritten.

Do you think the benefit’s going to be in there purely for people who are creating new things? Or do you think there’s going to be a benefit for people who already have existing things out there in the real world, to go and rewrite what they’re doing using the Interactivity API?

[00:26:54] Luis Herranz: Of course, as everything in WordPress, this is optional. Even though we want it to become a standard. It’s optional. But there’s going to be some kind of sitewide experiences that can only be enabled if all the blocks use this language, or this standard. So yeah, our hope is that there’s not going to be any reason for new blocks to not use this.

Because it absorbs a lot of complexity and it works out the box with all these things. But there’s also going to be some benefit on migrating existing blocks to this system if you want to make your blocks compatible with these new user experiences. And also, get rid of all the complexity that you have to deal with in terms of bundling and performance and things like that.

[00:27:42] Mario Santos: And actually it can also improve the user experiences, beause due to this complexity, we have seen many cases of blocks using React in the front end, but having issues with the server side rendering or not having server side rendering at all. So it could be a good approach to migrate to the Interactivity API, because it’s going to be easier to improve their blocks to support server side rendering, hooks, or other user experiences. There may be cases that they could benefit from that as well.

[00:28:13] Nathan Wrigley: Yeah, I guess the intention would be for a slow but steady migration over to using the Interactivity API, to the point where it just doesn’t make sense to use anything else. One of you, I can’t remember which one of you it was, mentioned performance implications there. I’m just wondering if you could dwell on that a little bit. Have you, in your testing so far, really noticed this? Has it speeded things up, made less use of resources and so on.

[00:28:39] Mario Santos: Yes. We’ve been testing and we want to test everything better and we will keep testing it in real sites. But it’s something that we had in mind from the beginning, that it has to be as performant as possible. And that’s why the runtime code is so small. It’s around 10 kilobytes. And yes, Luis before compared with other Javascript frameworks is performing pretty well.

I think we did mention this, but it’s using React under the system. So that’s why it is so small. And yeah, it is actually performant and we are looking for other ways of optimizing it. For example, we want to only send the directives that are needed by the blocks that are in the page. Or we want to send the scripts so they don’t block the page rendering.

Or for example, we are also exploring the possibility of the scripts, so they are only load when they are in the view port. So, yeah, overall I would say it’s performant. It’s been designed to be performant. The code is relatively small, and we are still looking for ways to optimize it even more.

[00:29:51] Luis Herranz: Yeah, I think that’s important. It’s not only performant today, but you have the guarantee that it’s going to be performant in the future, in the terms of you don’t have to, as a block developer, you don’t have to deal with performance in that sense anymore. Because that’s absorbed now by, well will be, hopefully absorbed by WordPress at some point.

And then if there’s something new in the web platform that can be leveraged to increase the performance and so on, it will be done in the WordPress side. So your block will just benefit from that, from just adopting this standard.

[00:30:29] Nathan Wrigley: In the article that you wrote, Mario, the first word is the word proposal. Which implies that this is a work in progress, shall we say. And I’m just wondering how far down the path of usability you would say you’ve got. In other words, can developers begin using this out of the box? Have you seen real world examples of people using this?

And have you had some interest from developers who perhaps haven’t implemented it, but certainly want to get on board? Because I’m guessing the more yes’s we can answer to that question, the more likely it is that other people will say, okay, yeah, let’s take a, let’s take a look at this. So, can you use it, and have people been using it?.

[00:31:08] Mario Santos: I would say, yes, you can use it, but we remind that this is still experimental, although we included the proposal word there. This is still experimental, very likely to change. So the APIs that we are using right now, that are used for example in the movies demo site, we are confident that they work, but maybe the syntax change.

So we haven’t promoted it yet to be used too much. There are people experimenting with it and giving feedback. For example, there’s an ongoing experiment in WooCommerce to replicate some of their blocks using directives. But there’s nothing in production yet because, as I said, this is still experimental.

There are some missing functionalities that may break your site, and it doesn’t have any documentation yet. So, I would say you can use it at your own risk because it’s experimental. We would love people to test it. To give feedback. We want to understand better if it’s easy to use the blockers that people may face.

Just to to clarify. In order to be able to use it, we are working on repository in GitHub. It’s a plugin that you can install, and from there you can create your own interactive blocks. Or if you prefer, there’s also the repository for the movies, with some examples that you can take a look and modify or whatever you want to do.

[00:32:34] Nathan Wrigley: Are those repositories linked from Mario’s article on make.wordpress.org?

[00:32:40] Mario Santos: Yes.

[00:32:41] Nathan Wrigley: Okay, so perfect. So if you want to find those, you can just go to the article, which is going to be in the show notes and you can find them all there. Now you’re both working at Automattic, and although it was only about 30 minutes ago that you gave me your bio, I wasn’t quite sure.

I know that you’re both sponsored full-time in WordPress. Is this project, the Interactivity API, is this a focus for both of you at the moment? In other words, are you being asked to implement this, full-time, part-time? Are you tasked with making this happen?

[00:33:12] Luis Herranz: Yes, we are. But we are not the only ones. It’s a large group of contributors. But yes. It was part of when we stopped developing Frontity the headless framework, and joined Automattic, it was precisely to focus on this. And we thought it made a lot of sense. Yeah, and thanks to Automattic for sponsoring us to be able to work on this for WordPress.

[00:33:40] Mario Santos: One note on this, as you said, there are more contributors working on this Interactivity API, and yeah, we are part of a bigger group that is working on the whole developer experience of Gutenberg. So this is just a project to improve the front end interactive parts of your blocks, but there are ongoing efforts to improve the whole developer experience.

[00:34:04] Luis Herranz: Yeah, and maybe it’s a good moment to say that if anyone is interested in this topic, just come to the repository and so on. And contact us and join us.

[00:34:15] Nathan Wrigley: Yeah, I was going to ask about exactly that. How open are you to contributions? Presumably any people that you can get interested in this, the more the merrier.

[00:34:24] Luis Herranz: A hundred percent open. We need people. We need people testing these. We need people using it. We need people giving feedback. Sharing different ideas. The most exposure, the better. How do you say that?

[00:34:37] Nathan Wrigley: Yeah, exactly that. So I guess really if this podcast serves to do anything, it would be exactly that. It would be to encourage people to go over. Read the post on make.wordpress.org, and if you’re interested and you think that you can help, then certainly it looks like your help would be most welcome. Testing, getting involved.

In terms of what’s coming, you mentioned that there are things which you desire to have. So I guess that’s a roadmap question. What is on the roadmap? What do you want to have in there that is not in there? Don’t worry about timeframes. It might be a year off, two years off, six months, doesn’t really matter. What are you hoping that it will do that it currently is unable to do?

[00:35:16] Mario Santos: Basically finish the Interactivity API, because it’s not finished. But, for example, our initial idea is to create the list of core directives that covers, I don’t know, 90% of the use cases, most of the use cases. Although then developers can create their custom directives.

So for example, that list is not finished yet. We still have to ensure that the APIs work for most of the use cases. We have to finish. And our idea for this is to, at some point, include it as experimental in Gutenberg. Start testing it in real core blocks, for example. Doing some experiments there.

Ensure that those user experiences are easy to create with the Interactivity API. Start receiving more feedback. So yeah, the idea is that. Keep experimenting. Keep developing the API. Receive feedback of users using it. And I think that’s it.

[00:36:16] Luis Herranz: It’s going to be important the moment when we add, we added as experimental API in Gutenberg. Because that’s going to increase the exposure by, I don’t know, ten fold.

tenfold.

[00:36:25] Nathan Wrigley: One of you mentioned before we click record that you are going to be giving a presentation at WordCamp Europe around the Interactivity API. By good coincidence, this podcast episode is going out just prior to that. So it may be that people listening to this are very soon going to be getting in the car train or a plane to head to Athens. Which one of you is giving that talk and what is it that you’re going to be covering exactly?

[00:36:51] Luis Herranz: That would be me, Luis. I hope Mario helps.

[00:36:55] Mario Santos: Yeah, I will help.

[00:36:57] Luis Herranz: It’s going to be a workshop. I don’t know if it’s a two hour workshop or two hour and a half workshop. It’s going to be hands-on. A step by step introduction to the Interactivity API and creating some interactive blocks and user experiences.

[00:37:12] Nathan Wrigley: So very much a hands-on experience. You are going to be teaching people and hopefully getting them to learn in real time. Do you know if any of that gets recorded and put on WordPress TV?

[00:37:22] Luis Herranz: I don’t know if workshops are recorded or not. Presentations are, yes. I don’t know.

[00:37:27] Nathan Wrigley: Yeah, okay. So you can very much be seen at WordCamp Europe, in Athens. Hopefully both Luis and Mario are going to be there. Head over to the workshop and say hi, and get involved. If people want to reach out to either of you, be that on social media or email or whatever works best. Maybe we can go to Luis first. Can you give us some details of where people could get in touch with you, specifically around this topic?

[00:37:53] Luis Herranz: Sure. I actually started like, I left Twitter for a while and I’m back from last week or so. I’m going to try to answer any question that people may have about the Interactivity API and to share the progress there at my personal account, which is @luisherranz, like my name and surname in Twitter.

[00:38:11] Nathan Wrigley: Thank you very much, and Mario, where can we reach you?

[00:38:14] Mario Santos: I would say Twitter as well. I’m not actively tweeting, but if someone writes to me, I will answer for sure. Handle is @santosguillamot. It’s a bit difficult, so maybe it’s better to include the link?

[00:38:28] Nathan Wrigley: I will link to it in the show notes because yeah, that might be the best way of doing it.

[00:38:33] Luis Herranz: And probably I would say come by the Block Interactivity Experiments repository. So in GitHub, WordPress slash block interactivity experiments. And then there’s, open a issue, open a discussion. Yeah.

[00:38:47] Mario Santos: And if people don’t use Twitter, I think they can reach both of us also in WordPress Slack, if they prefer to do so.

[00:38:55] Nathan Wrigley: I will link to both of those things as well. I will include both of your Twitter handles and both of your Slacks, plus all of the links to anything that we mentioned during the course of the podcast. So yeah, an interesting discussion about the Interactivity API. I know it’s not just the pair of you, but Luis and Mario, much appreciation for taking on this work, which hopefully in the near future will be improving, not only the performance, but the interactivity of our WordPress websites. Thanks very much for joining me today.

[00:39:21] Mario Santos: Thank you a lot for inviting.

[00:39:23] Luis Herranz: Thanks, Nathan.