The Collaboration of the Interactivity API with WordPress and WooCommerce

BobWP:
As you know, you’ve been hearing a lot about the Interactivity API probably heard it on other podcasts. You’ve heard it on different posts around the space. And we’re going to throw in some woo with this one because everybody’s been talking about WordPress, but we’re going to talk about WordPress and Woo and I have two experts on the topic. Way more experts on it than me by 100% Lucio and Carlos joining me, how are you two today?

Lucio:
Doing great. Thanks for having me.

Carlos:
Hi, I am really happy to be here.

BobWP:
Alrighty, well let’s get right into this. You’re just going to have a conversation, so we need to start with the basics. What is the Interactivity API?

Carlos:
The Interactivity API is a new framework for WordPress developers that allows them to write interactive blocks. Those are blocks that the user can click and something will happen on the site. And it does in a way that is the same way for every developer. We are trying to give consistency by writing some data attributes in the HTML that will be together with some JavaScript and will allow developers to create interactive blocks. That’s the main goal of the API to give consistency.

BobWP:
Yeah. So from both of you, what is the solving for the community? What is this solving for the developer community or even the community as a whole?

Carlos:
Regarding WordPress right now, the main problem in the community, it’s not a problem in the community, it’s problem in the software is that there is no guides about how to do the front end part in your WordPress site. I mean each project will depend on each developer or team working on it. Until now, you could use React, you could use plain javascript, any framework, but now you can also do that. But we are providing a way to do all, so all developers can use the same tools. And that’s great because that way we allow plugins to be interconnected. Like blocks can talk to other playing blocks, and also they are all using the same JavaScript library. So imagine you have to plugins one for bookings and one for the dealing with the payment process. For example, with this new API, they can both share the same code base instead of using one React and the other plain JavaScript or whatever library can use. That’s the main problem we wanted to solve here.

Lucio:
Right. So as per what concerns, Woo, I think a lot of what Carlos has just said applies. So if you think about traditionally how W has handled this kind of interactive well content in the shops, if you’re a developer, you know that, well, two things. I think first of all that Woo has somewhat fallen behind the curve of the modern e-commerce experience in a way. And the other you will know that sometimes the developer experience of adding such Interactivity to a shop was a bit inconsistent. So had traditionally we had things like just normal jQuery Ajax requests all sprinkled around various functionality like the add to cart functionality for example. So we had very kind of the first inkling of an Interactivity was that back, I dunno, more than when Woo started really that was there as well. But then when we started to get integrated a little bit more with Gutenberg blocks and start transitioning into a more block based paradigm, well frankly because of Gutenberg also was very young and Wu was an early adopter like we are of data Interactivity API.

Now there was no clear direction. So everybody was developing blocks was kind of on their own. And the same applies to Woo. So we started developing blocks using React. Well that resulted in well us trying to move as fast as possible to implement this kind of experiences, but it resulted in a little bit of an inconsistent experience. So now we want to transition all our bets away from the classic themes as you are aware and more into block-based development. And there are a few downsides of the way we were developing blocks because again, we were in the early stages and we were experimenting. First of all, I would say I think the clearest downside was that our new blocks, for instance, if you have used the old products block, they were climb side rendered. That means that when the user will go to the page, JavaScript will need to load and then it would show a loading skeleton and then it’ll show the products.

That would mean that well search engines nowadays can deal a little bit better with client side engine stuff, but it was not the best SEO and it was definitely not the best UX As you are going to the store and you know how precious those milliseconds are. You want to see your products as soon as possible. You don’t want to see another loading indicator. So I think first of all, the Interactivity API allows us to do the server side rendering of all this content, which means that the server already renders the content that we have. And so the user sees it immediately and then on top of it add with, what’s it called? Hydration systems that Interactivity API is providing add the Interactivity in short. So before we had the situation in which classic teams would be service-side rendered, but then let’s say you want to switch pages in your catalog and then you get a full page reload, that’s not great experience.

Then we wanted to do something a little bit more. So we had this client side navigations that was more snappy. But the problem is a CO and the problem is just user experience on first load for example. And now we have the best of both words thanks to Interactivity API, right? We service edge render. So that’s means the crawlers can find the contents very easily. You get it immediately without any flashing of content and also you get the Interactivity. So I would say there is a clear improvement for the user experience of WordPress users and merchants to get aligned more into what modern e-commerce platform, what you would expect from a modern e-commerce platform. So that’s I think the best contribution of the Interactivity API and the WooCommerce ecosystem. But to the ecosystem at large, you can also say there is a few more developer oriented improvements that have been made thanks to the work that the in interactive API guys have done, which is, well first of all, by using their framework, we remove a lot of low level plumbing kind of coding.

In this way it means that the responsibility is handled by the framework. We don’t have to worry and it means that WooCommerce code base is more consistent, it’s cleaner, frankly, and we can rely on the expertise of the entire WordPress ecosystem to support us because we are using their framework. And so we also are able to things just much faster and they are more maintainable and they are more secure and reliable. And also wherever is building on WooCommerce, you’re not going to have this fragmentation of the whole ecosystem that everybody’s doing something a little bit differently. So we have all the same framework now and yeah, like Carbo said, you can still implement things like you wanted, right? But now we have a common ground where we all built and that means greater versatility. For example, developers can jump from one place of the code base or another or maybe build the extra blocks that are going to be shared among and across the community and the ecosystem and so on. So I would say these are just a few of the good things coming from the Interactivity API to WooCommerce. It’s truly something magical.

BobWP:
I actually took this a little different approach because listeners are probably thinking, wow, these two really know what they’re talking about. So I’m going to step back and have you introduce yourself, who you are, what you’re doing with this project, what your experience and what has been your involvement with this so far. I’ll start with Carlos.

Carlos:
Cool. Well my name is Carlos. I’ve been working as a full-time sponsor contributor of WordPress score for about two years and a half. Before that, I was working doing projects for another companies as a freelance and also as an agency developer. These last two years and a half, I’ve been full-time working in Interactivity, API, planning it, talking with another developers, starting working on the foundations of the API, doing lots of testings, lots of proof of concepts, lots of investigation, comparing with another frameworks, a lot of stuff working on that. And I will keep working on the Interactivity as long as the community needs it. I mean, I’m quite happy to be there. I remember one sentence that was when I joined them, it was like, do you want to help to do the frontend developers of 40% of the web? And it was like, yes, for sure.

BobWP:
And Lucio, tell us a little bit about yourself.

Lucio:
Sure, my name is LuLucio and where to start? Well, I’ve, let’s start with my involvement with WordPress. I’ve been involved with the WordPress community since the early days of my development career. So it’s been more than 15 years. I think at this point. I think many of us developers have started somehow with juggling around things and playing with WordPress. It provided a really good platform and still does for starting out as a developer. Then I went on a long WordPress hiatus for several years. I didn’t touch any WordPress code. I started working on more AI automation related stuff actually.

And then about same as Carlos, I think two years a half ago I got more involved into this and I’m now working for Automattic. I work for WooCommerce division and I lead a small team there who is responsible for everything which we call full store editing, which is our version of the full site editing that WordPress says. So we are really trying to spearhead very hard the transition, like I said before from the classic paradigm to the blocks paradigm. So we want to empower users and merchants specifically to customize their stores, to have their vision come to life. And we really think that the work which has been done in core and Gutenberg is the best way to go. And I think over the past two years and a half, I’ve seen so much progress in WooCommerce that I hardly can believe it actually, I’m trying to be objective here, not to be too biased, but I think it’s been incredible the amount of maturity that we have seen in the past and a half years. And we are basically not only willing, but we are committed to try to make this transition as seamless as possible for the users and just to get everybody excited about what blocks mean in the WooCommerce and leave our legacy classic paradigms behind. So that’s a little bit about my mission, let’s say.

BobWP:
So what has been, you’ve both been involved with this for a while. What do you consider really the hardest part? What’s been the biggest challenge of actually the development of the Interactivity A p? I mean, is there anything specifically you can think of or something even more general?

Carlos:
When we started investigating the best approach to deal with the problems we had before, I mean the first thing you do is to compare with another React frameworks providing the same Interactivity and the single page applications period. And most of them next swell kits, they are using the same language both in the server and the client. But WordPress is not like that. WordPress is built on PHP. That was the most difficult part to work with because as Lucio commented before, you need to be server side compatible. That was the most important part. And in WordPress there are hooks and those hooks are really powerful, but also allows third party plugins and developers to modify the HTML as they want. And that is a thing that is quite hard for new Java screen modern frameworks because most of them are working to only change the data that the user interacts to.

If you have a counter and you increase it, you only want to update the number for a product. If you want to add two pair of CT’s, I mean the number is the only part of that HTML that should be updated. The problem here is that when you compare what it comes from the server to what you have in the client, if those are different at the beginning you’ll see a flash on the side as a user or you need a loading bar as Lucia mentioned. So dealing with those hooks was the hardest part and to be fully compatible with all plugins backward compatible.

Also with block and classic themes and with anyone editing that HTML, the way to go we found was this directives thing. I dunno if we talked about directives before, but for people who are new to the Interactivity API, these directives are the core foundation of the Interactivity API. These are like HTML attributes. If you take alpine js that is quite common similar or for example HTMX that is also quite new and it’s approaching a similar way to do these things. We are adding attributes to that HTML to allow both the server and the client to know what to do with those user interactions. Imagine on click for example or text update or changing CSS classes or styles. That was for my point of view, the hardest part to deal with.

Lucio:
Yeah, well I just want to echo what you said. Basically for us it’s also mostly the difference between the server side language and the front end language, which is I think a problem that still we have to kind of figure out a final solution if there will ever be a final solution, like a paradigm or sorts. Because obviously the advantage of having the single page applications of paradigm that we had before with the React components was that we only needed to care about the React code base, but now we have to maintain the same component in PHP and in JavaScript or TypeScript in our case.

So that creates additional complexity for sure. It’s totally worth it, don’t get me wrong. But still I think that on my wishlist is a way to better handle this component reusability, try to eliminate this duplication of code and try to make sure that the component is in sync to make it more maintainable. And I think we don’t have a solution yet. And I don’t know, I also don’t know what the solution could be. I also know that we are not exactly the only one who faced this. If you think about Laravel has had similar problems because also they are PHP framework and they use view in the front end. But Laravel has different set of constraints or rather we have much more stricter constraints than Laravel. I know that something that, if I recall correctly, maybe you can correct me if I’m wrong here. I recall when I was checking on Laravel did it, is that they actually have a node emulator running on PHP to do the rendering or something of that sort, which I think we can’t do.

I was speaking with Lucio I think a couple of some months ago. I think we can’t do because we need to support all their versions of PHP and this is only a PHP eight thing or something like that. So obviously this is a problem that’s really hard for us because WordPress is deeply committed to backwards compatibility. So moving towards these kind of things is much harder. But the upside is that people can rely on us for future years, right? So yes, I would definitely say that for us as implementer of blocks on top of the Interactivity API rather than implementing the API itself, this was the hardest challenge. Trying to figure out how to optimize for removing as much as possible code duplication and using the components and making sense on how to architecture our code.

Carlos:
Yeah, it’s also on my wishlist. I would love in the future to see the Interactivity P in the editor in order not to do the react block for the editor and then the front end or the PHP plus the Interactivity API block for the front end. That would be cool. Yeah, we have been thinking in that. But as you mentioned, backward compatibility is a thing. If WordPress, we have to deal, I mean it’s a good thing to have this backward compatibility as you mentioned, if you have a WordPress site, it will work for years, but still you need to update it please and this cover for security. But we have been thinking about it. We have several options there like working on a templating system or we are still thinking about it. We are also on the front end we use, which is a lightweight kind of version of React.

There have been some people asking us to move react to the editor part in order to be lightweight. But still there’s a lot of work to do there. There’s a lot of things to stay there. We have some options. We are just making tests, but still it’s going to take some time because I mean WordPress is evolving quite a lot. We are also phase three with this collaborative workflow, the internationalization. I mean that part is, I mean we will receive more feedback of that kind of, I don’t want to repeat lots. We are working on that. We know we suffer from the same.

Lucio:
I actually wanted to, you made me think about something I wanted to add to my previous answer, although I made it clear that it was just a limited set of advantages that I was talking about. But now you mentioned shipping React instead of react is also another thing that I think it’s particularly important for e-commerce experiences. To make it clear, we haven’t moved away from React yet, but it would be beneficial for performance reasons, obviously to ship the lightweight, the most lightweight code that we can. And also connecting to what you said about the directives and what I was talking about with removing a lot of the plumbing, for instance, state management, which is something very usually very complex and that everybody even in the same team sometimes tends to do in a little bit different way. Let’s not talk about different plugins in the ecosystem. I think that by abstracting the state management, the Interactivity API, this also is a huge advantage. These are my personal feelings of working with that. So take that with grain of salt.

BobWP:
So you talked about performance, which is obviously talked about quite a bit here. Anything else as far as impact on performance you’d like to point out or are there other impacts, say accessibility that you want us to be aware of?

Lucio:
Well, just what I mentioned is a tiny part of the performance impact that this has. Mostly, it ties in with what I was saying before, that the most important positive performance impact is the fact that everything is service side rendered. So users will see content mature, maybe have been exposed to those metrics as first paint and such metrics. These are just much faster. So not only performance is going to be faster because their browser doesn’t need to ship a bunch of JavaScript, then it needs to evaluate, then it needs to render the JavaScript and so on. But it’s also just including all the content needs to be rendered and it’s also perceived performance that matters a lot in these kind of scenarios. So instead of seeing a loading indicator, you see the content coming up immediately or like Carlos was saying, you don’t see the flesh of stale content and then everything is, it should be.

That’s I think as I was saying before, the best of both worlds between basic service-side rendered stuff, which is the classic, the real classic legacy kind of approach and the single page application that enables this more snappier interactions. So we get the best of both of those. As for all impacts like maybe accessibility, I mean you render HTML, so I guess it’s compatible much out of the box with most screen readers and things like that. We have big commitment on accessibility In any case, I know core even is even more diligent than we are most of the time. So I dunno, do you have stuff to add, Carlos?

Carlos:
Yeah, regarding accessibility, we already did accessibility improvements to some core blocks with Interactive DPA like search and navigation. Cause it is much easier to work with keyboard Evan, for example. So now the navigation keyboard experience is much better than it was before. And also as we are editing the HTML, both in client with Interactivity API runtime and in the server with also using the attack processor, the new H TML processor, we are adding some area labels or indicators for screen readers and keyboard navigating for the sites. So it will be still a matter that the playing developer needs to work with. I mean we can provide the tools but we cannot help you with your plugin or make your plugin to be accessible. But we are providing a tool that will allow you to add those markup, those thermal attributes that you need to have a better experience for those people. But it’s that the main point is that we already improved some accessibility. For example, also with the new image Lightbox feature accessibility was quite important for us and we spend a lot of time working on that and this API allow us to be able to handle that expand experience for example with the keyboard. And I think that’s all the rest of you mentioned is great.

BobWP:
Very cool. So did the team at WordPress core learn anything through this collaboration working with Woo?

Carlos:
Yes, for sure. We learn a lot of Woo. I mean when you start thinking about how to make a framework for developers, I mean the first thing we thought was, okay, let’s talk to them. Let’s talk to real developers. Because a problem for core developers may be that if you are all your time working only in core, you are only working with WordPress with nothing like a default WordPress installation with just one post, just one page gut number install and just that. And the problems usually appear when you need more difficult things. I mean, for example, our blocks to test was navigation search file and the most difficult was the query loop. But now you can change the pagination, you can paginate your posts without reloading the site. But the first time we talked with Woo, it was like, okay, how do you use it for the product collection, for product filter or for an add car button, which is more interactive than an e-commerce.

I mean WooCommerce was the best fit we could find at the beginning of the project. For example, there’s one directive that at the beginning where we were not planning on including it because we were not sure about if it would be necessary at the beginning of the Interactivity API life that was WP it that is used to render loops of things. And when we presented to Woo, the first thing they said was we need an each directive. And it was like, okay, we thought about that but we were not sure. And if you are telling us to do it like now the first or the second one, yes, go for it. And also they were the first giving us the real feedback and also giving us the main pain points that Lucio told before we are dealing with this issue. We have this problem using React on the front end. We are have this loading bar that we don’t really like and that’s it. We have had a lot of conversations with them. Their help has been great and also where they were, I think the biggest guinea pig we’ve ever had in a project because I mean Woo is in a lot of sites, woo is a really huge project and they even found the time to help us with the foundation of the API. I think without wool this project would’ve not been the same. Would’ve been different for sure, would’ve been worse.

Lucio:
That’s great to hear. And I want to make it clear that we were extremely happy and honored to be the Guinea pig project and we have also maybe people are wondering how we’re talking about how did we use this since it’s not out for official use yet. So actually we did something quite really experimental and crazy in our WooCommerce code base. We have included our own forked version of the Interactivity API runtime while it was still in flux and in development. And we still do that actually right now. So the way we have done this collaboration and provided the feedback that Carlos has mentioned it because we literally copied their homework with their permission and just pasted the Interactivity API runtime into the WOO code base. And that has allowed us to kind of really be there while the development of the API was going on with hands-on, of course everybody in the community could participate obviously, but to have such a big buy-in from us, it was very important from us that this would work. So we had a lot of involvement with ecosystem as Carlos has mentioned, providing feedback but also providing contributions and so on. So that was a really amazing collaboration, which makes me think really, I’m really optimistic about the future with the blocks and the Golden instantiation of Gutenberg in WooCommerce. Basically

BobWP:
With what you’ve said there and kind of moving forward, what ways does this facilitate custom block development helping woo developers get more creative in building the future woo experiences? I mean is there other things you haven’t mentioned or things that you would like to talk to those developers specifically and say this is now the opportunities you have or will have?

Lucio:
Well I think most of the things I have mentioned in passing at least I would say the biggest deal is basically removing the responsibility of this plumbing that I was talking about from the hands of the single developers and enabling them to build experiences instead of thinking about how to deal with state management hydration now what’s the best paradigm to use for templating and ding and all these sort of things that Interactivity API does for us. So removing the heavy lifting from the developers and also creating a base, like I was mentioning before, a shared understanding across the entire ecosystem. Not only WooCommerce but WordPress Gutenberg. So we know that our blocks are going to interactive blocks, this is the way they’re going to work moving forward. This creates also a lot of future proof to your custom blocks for example.

So you can be faster, just more rapid development of this kind of dynamic components. You can be more future proof, you can get inspired by what’s going on in Gutenberg. You can see, actually one thing that we did again copying course homework is our product collection block that is soon hopefully coming out of beta is based on the query loop block that was done on Gutenberg. So at first actually we’re using a variation of the block and then we realized we couldn’t really use a variation, but we took a lot of inspiration from the work that very smart people have done on the query loop block on the navigation, on the gotchas of what kind of blocks you can put inside. There is a lot of stuff that we have taken inspiration from the work that’s going on in Gutenberg. So I would say these points maybe are a good answer to your question.

BobWP:
Well I know that listeners probably as they get through this show, they come up with questions and I actually did have a listener when they found out that I would be talking to you too, did ask a question around security. So I thought I would at least throw it out to you and I’m going to read it here. Verbatim said the proposal blog post mentioned security and their graphic as partially handled. He says he doesn’t have a lot of react knowledge, so he’d like to know more information on that. For example, is this the end of nonsense?

Carlos:
We are not ending nonsense. I mean nonces are still there. We’ll be still there because it’s a great way to deal with intercommunication between the user and the site or saving data in the system. From there, I mean the most easily in the site, the most dangerous part is forms is allowing user input from outside that can be injected to your site or server site to your database. But what we mentioned there is we are providing a framework to create interactive blocks. So they will be secure, our directives are secure, the run time is also secure. The PHP server processing of all of that, because we are in PP is also processing those directives in the server. If you want to show a taps panel for example, and also the first step for product descriptions or productization data, all that part, if it is handled by the PHP with our Interactivity API will be secure.

But also we are allowing the user to use their own JavaScript. I mean you will have a VJS file in order to write that interactions you want the blog to have and that java script will be written by the developer. So that’s the partial handle. I mean we deal with one part that is the API and the directive processing and the runtime that make that interaction. But the other part is handled by the own developer. So we cannot control that. I mean WordPress is secure. Yes, we try to be secure as always, but you as supply developer, you cannot, you need also to your clients to be secure.

BobWP:
Alrighty, cool. Well I’m sure that was the answer he was hoping for. So getting towards the end here, is there something that we haven’t touched on? I’m sure there’s a lot of things we haven’t touched on, but anything specifically from either of you or both of you that you’d like to add?

Lucio:
Yeah, actually, I mean as you said, there is probably a treasure trove of things to touch upon. I’m very proud of saying that we have been experimenting with a lot of new things. And so people who have been following WooCommerce quite closely, they might have seen also a little bit of a mess maybe sometimes as we have included the new products beta and then it became the new products beta block was supposed to replace the old products block and now we have a new block which is the product collection block, which is supposed to replace the product’s beta. And maybe some people have questions about why we did this and I would say sorry, but not sorry. Also we have been experimenting and being a little bit more liberal. That’s why we for the first time introduced beta label on our blocks because we felt like we wanted to be a little bit more out there and experiment with this new API and make sure that we could move a bit faster than our usual commitment to backwards compatibility and so on. So I think one of the most exciting parts that we are implementing is this new way of displaying your shops catalog, which I guess is the core, the heart of the e-commerce.

So now you can display your products using this new product collection beta, which is hopefully coming out of beta in the next, I don’t know, maybe I shouldn’t say anything but soon tm. And so you will have all the advantages like I was mentioning before of service side rendering. So it’s very snappy, instant rendering and also incredible interaction and Interactivity like pagination and so on. And we are also in parallel developing the new filters block. So previously we were in this limbo zone. Well, in a classic experience, you select a filter in the whole page, reloads in a react experience, you select a filter and the block reloads. But there was a bunch of limitations about doing that that I’m not going to get into because it’s going to get a little bit too tedious. But now we are implementing this new filters block which will seamlessly integrate with the product collection and everywhere you can have multiple product collection blocks in your site and have different filters assigned to them and everything is going to be very fast in reloading and now people expect from the modern e-commerce experiences.

So this is I think one of the core things that we are working on, but there is much more, like for example, developers might be happy to know that we are moving away from our jQuery ways. So actually the first Guinea pig of the Interactivity API was the add to cart button, which still used jQuery in factories. I dunno how many people know this. There’s a little setting in WooCommerce in the WooCommerce preferences that you can toggle if you don’t want Ajax to happen on the clicking of the add to cart button. That’s probably a setting that came out, I don’t know, maybe 12 years ago. I don’t even know why that’s setting why anybody would toggle that setting. But we still keep that setting by the way, we didn’t remove it, but we have transitioned the jQuery way into Interactivity API. So the add to cart works with Interactivity API and then we are doing things like the product gallery that eventually maybe, we’ll thinking as I was saying before, to take inspiration from Gutenberg, we are thinking of perhaps trying to transition into the more light box behavior that Carlos was mentioning that Gutenberg is implementing right now.

It’s not the API is not quite there for us yet, so we are doing other things, but eventually maybe the idea would be to once again try to leverage as much Gutenberg as we can. So we want to be to set out the example for the community that Gutenberg is really a solid framework that you can build the most complex use cases upon, which I think e-commerce is probably one of the most complexes and we have many other things down the line. You can imagine tabbed experiences in your single product template, a collapsible maybe your so many things on the roadmap. Imagination is the limit, let’s say. So I just wanted to give a little bit of sneak peek for people who haven’t used this new blocks you should get into them, try using the product collection. The new filters beta give us feedback. We are really keen, especially in this phase, to get as much feedback as possible. I know actually data that product collection is being used and it’s on the rise and that makes me extremely happy. I can’t wait for basically every e-commerce WooCommerce experience to be a block expert. So that’s my mission as I mentioned earlier.

BobWP:
Do you have anything we’ve left out, Carlos, that you’d like to add, that you like to highlight?

Carlos:
I would like to highlight that the Interactivity API is stable. Okay. You can use it without hesitation. It was included in a private way also in 6.4 in the previous version of WordPress. And the navigation block, as I mentioned before, navigation, search file and query, and this light box feature that was included on the last version of 6.4 in WordPress were all powered by this Interactivity API that will now in 6.5 will be public.

BobWP:
Alright, great. Now for those developers out there that want to follow all the things that are going on with it and possibly propose suggestions to the roadmap or offer use cases or whatever, how can they do that?

Carlos:
I think Gutenberg repository is the best place to go. If you have any issue or a problem, then create an issue and let us know. You can ping Luis, David or me in Gutenberg and we will be happy to answer. And also there’s a panel there in GitHub called GitHub Discussions and there’s a bar just for the Interactivity. PI like attack for discussions where you can talk about it suggest improvements, you can also showcase your blocks or your projects and those are the main points. We also are in Slack, so feel free to reach out in coordinator Slack channel, and I dunno, maybe Twitter, well now colleagues, but some of us are there looking for Interactivity word, but the best place to discuss apart from make core posts. Also in the comments of core posts that are talking about the Interactivity PI think GitHub is the best place to go. GitHub and GitHub discussions

Lucio:
For our developments. You can always follow developers to know what we’re thinking about our roadmaps. We post design snaps very frequently. Kudos to the people involved in that. Our community Slack is also available and we are also on GitHub as well. But I think for Woo, you should keep an eye on developers woo.com and give us feedback on the repo and also on Slack. Ping us and give us feedback on the way you’re using the blogs on the limitations that you’re seeing. It’s similar to what Carlos was saying about Gutenberg working in a vacuum. Sometimes when we develop for e-commerce, we don’t know all the ins and outs of people’s businesses and what their needs are. So maybe we think we have covered all of them, but there are some niche, or even maybe not so niche, but things that just fly under our radar that people can just ping about. So ping to us about. So ping us the limitations that you find with the new blocks we are experimenting with. We are really, really hungry for feedback.

BobWP:
Very cool. So I just want to thank you both for taking the time. I know this is a hot topic right now. A lot of people are interested in it and hopefully we’ll get people in there asking all sorts of questions and also contributing and helping along the way. So again, thank you both for being on

Lucio:
Anytime. Thanks for having us

Carlos:
Anytime. Happy to be here.