 just get things going here. So just a reminder that this session is being recorded and will be uploaded to WordPress TV. With that in mind, please do turn on your video, it'd be great to see you all, but please remain muted during the presentation. So this session is gonna be a presentation about the interactivity API. It's not a panel or discussion, there's various formats for the developer hours. This one is gonna be a presentation. It's gonna be presented by Mario, it's gonna be assisted by Lewis, I'll get them to introduce themselves shortly. If you haven't already seen it, let me just grab the link here and put it in the chat. This is the link to the proposal post about the interactivity API. And here's a link to the project repository on GitHub. So you can satiate your curiosity there. So with that out the way, I'll introduce Mario, who's gonna be leading the presentation. So Mario, would you like to introduce yourself, say a little bit about yourself and how you got involved in the development of the interactivity API? Sure, thanks, Michael. So I'm Mario, I'm from Spain. Well, I'm part of the group of contributors that have been working in the interactivity API. We are currently working on improving the whole block developer experience, development experience, and this is like the first step. So yeah, we come from Frontity that it was a startup and we were creating a React framework for WordPress. And now we seek to be core contributors and we are implementing our knowledge to bring those experiences into WordPress itself. Awesome, thank you. Mario is gonna be assisted by Lewis. Lewis, would you like to say a little bit about yourself and your involvement in the development of the interactivity API? Sure, it's pretty similar to Mario. Also involved in the group of contributors working on the interactivity API, trying to figure out how to enable these kind of new features of our capabilities for WordPress. And also previously, I worked on this Frontity framework which was a React framework for headless WordPress. And yeah, and we moved to, we stopped Frontity and focused on WordPress core cause yeah, we believe that full site editing is the future of building sites with WordPress. So yeah, instead of trying to build user experiences like more rich user experiences with external tools like in our case it was Frontity but any of the headless solutions, we want to bring those same capabilities to WordPress itself. So it can be used with the full potential of the blocks. Amazing, thank you. And full disclosure, I used to work with Mario and Lewis at Frontity. Okay, there's gonna be, as I said, this is gonna be a presentation led by Mario. There's gonna be an opportunity for Q&A. So if you've got a question, either ask it in the chat or raise your hand and hopefully we'll get around to answering all the questions. So Mario, are you happy for people to ask questions during the presentation or do you want to do the presentation and have Q&A at the end? How do you want to play it? Hmm, I'm not sure. Maybe wait for the Q&A because maybe some of the questions are answered later in the issue. That makes sense. Okay, well, if you feel it's relevant, we can stop, it's not a problem. Okay, we'll run the presentation and we'll do the Q&A at the end. Okay, but yeah, I mean, but as questions come up in your minds, you know, put them in the chat. Yeah. And we'll get around to answering you. Let me just run through some announcements quickly before we get started. As I'm sure you already know, WordPress 6.2 is out, came out a couple of weeks ago. So it's ready for use. There's the link. Also just launched recently is the new developer blog which has articles, technical articles targeted at developers. There's a link to that if you're not already aware of it. Yeah, so WordPress 6.2 has just come out. So that means WordPress 6.3 is in the planning and development stage. You can get involved. WordPress is open source, so anyone can contribute. There's a link to the WordPress 6.3 planning. WordPress Europe, of course, is happening on the 8th to the 10th of June. Since this, we've got two of these sessions, by the way, one is going to be targeted to America's time zones. This one is for Asia Pacific and EMEA. And so because this one's targeted at EMEA, the WordPress Europe will, I'm sure, be of interest to you. WordPress US, in case you can make that, is happening earlier this year than usual, that's in August, the 24th to the 26th of August. And if you can't make either of those, now that the pandemic is pretty much over to all intents and purposes, local WordCamps are now happening and you can find out all about a WordCamp happening near you by visiting central.wordcamp.org and there's the link in the chat. Okay, so with those preliminaries out the way, I will hand it over to Mario. Take it away, Mario. Thanks, Michael. So, well, first, for those who have read the proposal you may already know, but let's explain briefly what the interactivity is for. Basically, we want to provide a standard way to create, to add front-end interactivity to your blocks. And in now, Woodenberg has been focused mostly on the block editor and there was an intentional gap in the front-end of your blocks, so the interactivity API aims to cover that gap. So imagine functionalities like, like this post or add to cart or, for example, the instance search or full page transitions or comments form without page reload. Those are the user experiences that we want to enable and we want them to be easy to be curated in WordPress. So that's what the interactivity API is for. Just to clarify. And my idea for this session was to start showing some, some of these examples and then take a look at the requirements and show some code examples and go through them. So let's start if, if you want. I can set my screen. Okay, not this. Yeah. Okay. We created these movies demo site in order to show the interactivity, interactive experiences that we are talking about. For example, here I can, I can like these movies and we can see that the blocks in the top are updated and the count is going up. I can also do pagination here and we can see that the page is now reloaded. Everything is handling the client and we can see that it feels almost instant. It's because we are prefetching all the pages aggressively in this demo. I can also go to, to the movies and we can see that the, that the counter is still there and the legs are still there. I can also play the trailer and it's going to open this pop up here. That is another block and the video is going to keep playing. And whoops. And the way we are doing the different, well, the interactivity API is doing the different. It's intelligent enough to understand what parts of the page need to change and the ones that don't change are not updated. So this allows us to keep, for example, in this video while I'm navigating, it's still playing, it's not refreshed and I can go to another movie and it's going to be there. And similar to that, we also have the instance search. Here if I start typing, you can see that the results are automatically updated and the video is still playing. And all of this, it has to be compatible and it actually is compatible with the block templating system. For example, here I'm in the block, in the editor side of the movies. So if I make any change to the templates, it's going to be automatically reflected in the front end and the interactive blocks are going to remain interactive. Let's see an example. I'm in the search template. So I can add a new block here. Let's add a row and I can add some paragraphs like this movie. And I can insert an interactive block like icon, for example. And we can see that this is how you usually work with blocks. You have here all the styles. I can center the items. Here in the paragraph, I can change the color of the text to be white, for example. And if I save this and I go back to the page and I refresh it. If now I start searching, we can see that the changes that we made to the template are there over here and the interactive blocks that we included remain interactive. You can see that the likes are applied. So this is it. This is what the interactivity API is for. These are some of the use cases. So we can jump now into the examples. First, a couple of warnings. This is still experimental. We are checking what are the best APIs and approaches. And another important part is that this is meant for the front end of your blocks. It doesn't handle the block editor side that keeps working as it's working right now. In the future, we will like actually we are exploring the possibility to integrate both things and you can use reuse code both for the editor and the front end. But for now it's out of this initial proposal. So let's see how this is implemented and what we are proposing actually. What we want is, as I said, a standard system and this API is right now a standard system based on directives. For those who don't know, directives are just custom attributes that we are adding to the HTML tags that tell the interactivity API the behaviors that needs to be attached to the DOM elements or even modify them. It's kind of similar to Alpine GIS for those familiar with it but especially designed to work with WordPress. So let's dive into the examples that it's going to be easier to explain. For that we created some interactive blocks. This is a really simple example with a toggle that when I click the button it's going to show some text and it's going to console the hidden property in the console. So if I toggle this it's going to say hidden true and we replicated exactly the same behavior using React to show the difference. This one is using the interactivity API and this one is using React as you can see the functionality is exactly the same but we will see later the differences between the code and some edge cases. I think we can go into the code now and check. Here we have in the left how the block is built using the interactivity API and in the right we have the same block using React. For building the block using the interactivity API the workflow of creating blocks remains the same. It is just a new API that you can use so basically you have to do two things. You have to add the directives to your markup it doesn't need to be a dynamic block like this one it can also work with static blocks but you have to add the directives to your markup and then you have to create the store that is the one handling the JavaScript logic. Let's see this example to clarify what we mean with this. These are the custom attributes, these are the directives. In this example we are adding here data WP context that is meant to be used to create local state so here we are defining an object with the hidden property and this this state, this local state is available to this node and all its children and they can be used in the actions and effects as we will see later. Here an important note is that this is local state but it's also possible to create global state. We can do that in the store, I could create here state and add some properties that would be available not only to this node and its children but to any node in the page. Then we are adding another directive here that data WP effect that is calling the effects log show defining the store and here in the JavaScript part in the store we can see that we are just defining this effect that is console logging the hidden property is getting the context and is console logging the hidden property. So the data WP effect runs is time that this property is changed so it's going to console log the hidden property when we toggle it. Then in the same button we have data WP on click that is calling this action action session plugin toggle and yeah this is just a simple action to toggle the context. And finally we also have data WP bind hidden this directive is meant to be used to change the value of some HTML attributes in this case we are attaching the value of context hidden to the hidden HTML attributes. If we take a look at the react example we can see that all the logic that you define in React or JavaScript was like user state, user effect the toggle function these conditionals this is moved to directives so in the case of use state this is the local state that you define in React it could be equivalent to data WP context here the use effect the hook that you use in React is equivalent to data WP effect and here we can see that we are defining the console log in the use effect is the same we are defining here. Then we have the toggle function that we are defining in the store with the actions and then here we are adding some conditionals to change the hidden attribute of the HTML and for that we are using data WP bind and I think that's it regarding the examples Luis feel free to interact me if you want to add something I didn't say that ok so these are the same blocks that we were some here is important to note that as you can see we are using HTML as the templating system and it comes with some benefits the main one being that this can be understood by PHP so it can support services rendering it can support the WordPress hooks that we will see now we are going to go now through the requirements that we define before researching the best approach and we will see how they are met with these directives implementation so I think regarding how a block is built using directives this is it you need to add directives to your markup and create the store with the JavaScript logic that's the summary kind of so we can go now to the requirements or goals these are the initial goals that we defined before researching the different approaches we consider different alternatives and at the end we decided to go with directives because it was the system that was meeting these goals so let's take a quick look at them we have here block first and PHP friendly and related to that it has to be backward compatible as everything WordPress and extensible with this we mean that it has to be designed to work in the blocks world and it has to be PHP friendly, it has to support server-side rendering, it has to support WordPress APIs like WordPress hooks or translations and it has to be as extensible as WordPress is right now plugins can extend functionalities and all those things that WordPress does great then we also wanted it to be declarative and reactive this means that whenever you change the state it automatically reflects in the page in a reactive way we wanted it to be as performant as possible it has to be atomic and composable so you have small reusable parts that can help to create more complex systems and it has to be compatible with the existing block development tooling this means that you don't need extra tools to create your interactive blocks so those are the goals let's see now how they are met with the interactivity API let's start with the block first and PHP friendly and backward compatibility and extensibility as I said we are using HTML as the templating system and that makes it compatible with blocks and PHP it supports server-side rendering which is important is something that we take from granted using WordPress but the current approaches to add interactivity to your blocks usually have issues with server-side rendering let's take a look at our example again if I refresh this but using a slow network we can see the differences between the two blocks we saw the short text before it disappeared this is because from the server-side rendering we are getting that text and React is the one hydrating it and hiding it and as React doesn't have support for server-side rendering it's causing this layout shift or well this is a really basic example but imagine you have some images and they disappear it can create some layout shifts that can create a poor user experience let me refresh it again so we can see now the son text and when React hydrates the text is hidden it remains now it's interactive but you have that problem from the server you could also remove completely the server-side rendering but then you would have problems with SEO for example so it's not the best user experience and here I think it's important to know that you could do server-side rendering in React using Node for example Node.js but that's not something that all WordPress can do and not all hostings are gonna have Node.js available so that was one of the we were exploring the possibility to use React for this and that was one of the main blockers and related to this we also have the Backward Compatibility part that is basically for example using WordPress APIs like I said like WordPress hooks and translations using the directives that are included in the HTML those things work out of the box and with approaches like React that's more tricky because even if you support server-side rendering imagine there's an external plugin using a filter to modify the HTML that's something really common in WordPress imagine to add a class if that class is added in the server but React doesn't know about that hook and it's kind of impossible to know all the hooks that are being applied that class is gonna be it's gonna disappear once the hydration happens it's gonna come from the server then React is gonna update the content but as it doesn't know about the filter it's gonna remove it let's see an example for that we created this add class hook I think I don't need this anymore yeah we added a hook here that basically we are hooking into the show text block and the show text React block both blocks and we are using the HTML processor to add a red text class for those who are not familiar with the HTML processor it's just a new API to modify the markup and it's really useful so basically here what we are doing is for the show text and the show text React we are adding the red text class in the markup so let me activate it it's deactivated and if we go back to example and refresh it we can see that it has it had the red color and here in our interactive block is gonna have the red color but now if I toggle this it's gonna be blue and this is because the class has been removed if we go to the HTML this we have the deep here and we can see that the red text class is not here while in the in the interactive in the block using the interactivity API is here and that's why it's been applied and if I disable the JavaScript just so you see better how it comes from the server we can see that the well here is hidden because what we mentioned that we are able to understand the directives with PHP and with React it gets trickier but if we go here to the deep we can see that the red text class is here but as far as React starts and hydrates is gonna remove it because it's not aware of the hook adding this class hope that's clear not sure but hope that's clear something to add no the thing it disappears the class disappears in the React block because if you go to the React template to the JavaScript do you still have it there the class is not there yeah so it's just class hidden text and when React hydrates that's what it's kind of the source of truth right and it's really difficult to know that that class was added because it was added by an external plugin using hook so we cannot know the external plugin added to the HTML but didn't add it to the React JavaScript so it's not in the React JavaScript yeah here in the we can see that in the interactivity API example we don't have that class neither but as we are using HTML it's going to be here in the server so it's going to be applied and the same way it works with hooks we could use internationalization functions like this one for our test and they will work that was one of the main reasons to make HTML the templating language instead of relying on an external templating language based on JavaScript yeah so to that and WordPress hooks we can also use hooks to extend functionalities of other blocks for example here if we go to the movies let's go to this one for example we have the postfeature image block that is a figure with an image this is the HTML we could use a hook to add some directives here because it's HTML so the same way we use the hook to add a class we could use a hook to add some directives and some JavaScript to handle that logic so let's see another example here we are well let me show you first the user experience I think it's going to be easier if I go here and I activate this imagine this is an external plugin that wants to add some zoom to the postfeature image so this is what we are doing I installed the plugin and now we can zoom the image on hover and we can see that that plugin is adding some directives that we will see now and some JavaScript that understand these directives so with that we can have this zoom effect from an external plugin that is extending the postfeature image block that is including code so let's take a look at the examples for this particular example what we are doing is add them to image we are rendering we are using the filter to add this code to any postfeature image and what we are doing we are using again the HTML tag processor and we are adding data WP context in the figure we are just saying is to in false page fault and we are adding two new directives that is data WP on moose move we are calling this action that is defined in a JavaScript file that we are enqueuing so we are adding data WP on moose move out is calling zoom and on moose out is calling reset zoom and here we are again creating an store like we did in our interactivity API block in the zoom example we are getting the context we are setting it to context is to mean true and we are adding some styles to add that zoom in effect and then in the reset zoom we are just changing the context to be false and just with that well I also added some CSS but just with that and enqueuing the JavaScript files we are extending the core feature image with zooming so this way is also possible to extend the well not the directives but you can add directives to existing blocks with this kind of hooks as is usually done in WordPress and apart from that well we didn't mention it but our initial idea is to create an initial list of directives that should cover most of the use cases but it will also be possible to to create your own directives for edge cases so that's another way of extending this system and I think that's it regarding block first PHP friendly, bug word compatibility and extensibility then we had the declarative and reactive approach I think that's kind of clear we can see here that everything is reactive for example if I go here and I do this I modify the state directly we are just adding the Godfather movie this is the idea for the Godfather movie and we are adding it to the light movies array so if I add this we can see that everything in the page that depends on this state is automatically updated we can see the hurt here was triggered and the count was applied so this is the declarative and reactive approach that we are talking about then as we said we wanted it to be as performant as possible so well I think we haven't mentioned it yet but this system is using preact under the hood that is really really small and we are using signals for all the declarative and reactive approach and this make it really performant using react I go if I refresh this this is the JavaScript that is being loaded to the client as we can see is pretty small we have the vendors.js file that is the one including preact and all the dependencies we have the runtime that is including the directive code we can see that is three kilobytes and in this case is because it's using client-side navigation but that's a feature that we wanted to enable but it's going to be totally optional so if sites are not using it this would be less size and then we have the view.js files for the interactive blocks apart from that this is how it's working right now but we are already exploring ways of optimizing it for example we want to only send the directive that are including the page or we want to load the JavaScript code only when the block that needs it is in the viewport we also want to take a look so the scripts will load without blocking the page rendering so the way it's working right now is already performant but there are ways to optimize it even more and I think that's it regarding performance then well it has to be atomic and composable we already see that everything is handled by directives that are reusable across the page and it has to be compatible with the existing block development tooling for adding an interactive block using the interactivity API you just have to add the directives to the markup so the tooling remains exactly the same so I think that's it regarding the goals then it comes with some benefits of using a standard that are block communication as we have seen blocks can communicate when I was liking a movie it was updating another block in the header it has the benefit of composability and compatibility with this we mean that you can create extractor of interactive blocks using other interactive blocks and everything is going to work out of the box so for other solutions like imagine there are plugins using React and other plugins using other JavaScript other JavaScript frameworks it can get tricky both block communication and composability and compatibility can get tricky it's difficult to make them understand each other having a standard everything works so that's another benefit of it and then we have client side navigation that it was showing in the demo basically this is a feature that we wanted to enable for WordPress we think is great that WordPress has this capability but it's important to know that this is going to be optional and obtain so we think for some use cases it's going to be great to have the possibility to do client side navigation as we are doing with the movies or maybe with the query loop or commerce could benefit from this there are some use cases where this could be handy and could be great it can create great user experiences but yeah it's important that it's optional and not all size will need this so I think yeah imagine things like client side navigation on the query loop the comments forms commerce or there are many use cases where this is great but it's going to be optional so yeah and I think that's it we can see examples of block communication and composability if you want or we can jump into the Q&A whatever you prefer what we mean with block communication is that if I click this if I click this play play trailer this is slow the play trailer is going to trigger this other block so they communicate between themselves and if we take a look at the code this one this one we can see the trailer button in the render PHP file is just calling this action actions WP movie set video that is not defined in the movie trailer button is defined in the video player in the vues file we have the set video here so different block is using an action defined in a different block and this can also help with plugins and here we are using the same plugin but it could be useful to communicate different plugins using the same approach with composability or composability and and compatibility we created another example here we created a block that is well,actually is almost the same as the show test that we saw but it's like a spoiler block where you can include children and it's going to be interactive it's going to toggle so if I include here the spoiler block I can move the movie stuff that is another interactive block here and if I save this now here if I go to the movies we can see that we have the show con this is the spoiler block that is it has some directives to hide the content and show it when it's clicked and we can see that this other interactive block is here and it remains completely interactive can trigger more videos and those things so everything works you can nest interactive blocks in other interactive blocks and as they are using the same approach everything is going to work and you don't have to deal with it and I think that's it anything to add Luis? no, I don't think so amazing thank you very much Mario great presentation so I think we've got a question already from Carolina what is the plan for improving accessibility by screen reader usage when page content changes without reload I did not see accessible as part of the goals we didn't include it because we take it for granted but for sure everything we do has to be accessible and actually well I didn't include it in the examples but with this approach it's kind of not easy but you can change the area attributes for example using the same directives that we use like the data WPE bind you can toggle those attributes easily depending on the state so yeah everything we do has to be accessible and with something we have in mind yes, we've been talking a lot with Alex Stein the thing here in this phase of the interactivity API is that as Mario says these are the primitives these are like the atomic primitives so with these atomic primitives you should be able to build accessible blocks in terms of interactivity but you need to do that yourself you need to use those directives those primitive directives but you can do it the thing when it's more important to bring accessibility into the conversation is when we start going kind of in a step higher in the abstraction and we start providing components or directives that accomplish more things that are not so primitive like for example a custom directive or component for a model so when we expose those then inside those directives we need to make sure that they are changing the different area attributes and so on so that everything if you use those high level directives or components then whatever you do it's going to be accessible by default but we are not at that point yet that's kind of something that comes a bit later it's like when you create a React component you can make you can make it accessible using well changing the attributes using use effect to change the focus and so on and so on and you can do the same thing here with interactivity API is when you use like a component library for React when those components need like that accessibility kind of baked in so kind of it plays the same here if that makes sense okay thank you hope that answers can I add something? sure go ahead Greg so just like it's important to know that like the way the websites by default the teams work in WordPress is that you have full page which means when you use experiences like the search one is that what you will see that you have like the focus taken outside you know from the input filled in the search form to the beginning of the site whenever you navigate to the new result which means that like in that case it's much more complex for someone to get back to the search you know start the searching again which is like this like design it provides you better tools for people who need those assistive technologies because the focus stays in the search they can continue refining their search without you know losing the context whereas then they need to tap again to the field and it's like you know it's much more work and if you like look at other examples that you select the like button usually you would have to have a full page reload to save the state on the server get back and then finding your result on the page and like you know doing some interaction is so much more complex so it's all that is left here just to ensure that all the feedback is provided by using live area attributes and stuff like that which could be done by developer as well in the first version which is like we need to like ensure that it's visible but everything else just like you know it should be so much easier with those paradigms Thank you Greg I'm glad to see more questions are coming in that's awesome so Paul asks can you share the store code between the editor and the front-end or do you have to create a WordPress data version so the answer is not right now the developer experience for the block editor remains exactly the same as it is right now at this moment so you cannot use directives in the block editor it's something that as I said that we wanted to explore and that we are starting some explorations, we want to be able to reuse as much code as possible but for this initial version the interactivity API only affects the front-end of your blocks I hope that answers Yeah I would say if you have examples where you would want to share data between the editor and the front-end yeah please go to the github repo open a discussion, share examples, use cases so we also kind of understand the needs cause right now yeah for us it's not like super clear that the editor and the front-end have the same needs somehow they're gonna overlap we don't know if a little bit about that so yeah the more that people start sharing with us about the use cases things like that we can think about solutions to fill those gaps Great and Clement asks does the interactivity API also trigger side effects like rest requests to save data like the fav movies reflections on how this could be achieved Yes it's possible in action and effects you can do basically anything you can do in JavaScript so yeah you can do it, actually there is an experiment in the Woodenberg repo that we are using well it's not rest but it's for the that isn't related sorry but yes you can do whatever you can do in JavaScript so Where are you going to say the comments form submission Yes, because Matt is not a rest request Yeah, it's not a rest request I don't know if we can show it Do you want me to show it? Sure because it's also an interesting experiment Okay How do I version of the screen Okay Can you see my screen? Yes We can link this pull request We were trying to do client side form submissions for the comments form and here what we did was to well to add some directives well in this case it was the actual block of the comments form but you could do this with a plugin and we are using also the HTML tag processor and we are adding like a directive like Mario Soud so we are adding this core form submission here and this is the Vue.js so what we are doing here in the Vue.js is that well this is triggered on form submission and what we are doing is we are manually adding a fetch request to the WP comments post HTML which is what happens with the with the normal comments they don't do a rest API request they just do a post request to this so we did that with the same form data that the server would do we did that in the client so we have the result and we can expect the result and say if it return an error then we are going to populate the error in the screen and if not sorry for the comments how can I turn them off but if not just navigate to the new URL and here this is how it works so you just comment here and it's going to appear the comments are going to appear here without needing a full repress if you keep commenting it's going to refresh the screen and all that is doing is using this just this fetch this fetch here to the post comment and the post and it's using the HTML that it was returned to do the navigation to the next page so you can hear in an action you can fetch and call the rest API if that's what you want and then you can navigate you can update the screen updating the state or context you can do pretty much whatever you want in an action because this is just JavaScript running on the browser the thing here is that you can also use the old the regular server-side rendered methods like this post for the comments and reuse that and create this plain-side experience as well is that clear? so you have both options there yeah okay that's it for the questions if you've got any more questions please just post it in the chat one last thing I'm going to start the link to the examples just in someone who wants to take a deeper look at the code let me look for it I lost it so okay is this gift hub repo this one is for the examples that I saw in the demo and then we can keep all the conversations in the blog interactivity experiments repo we are happy to hear your feedback please whatever you have to tell us so yeah I was just wondering you talked about backward compatibility in your presentation I'm just thinking about the future the next stages of Gutenberg the collaborative working and then translation which is going to be the fourth stage how do you see this developing over the next two sort of stages of Gutenberg I would say that everything that we do for phase 3 and phase 4 has to integrate perfectly with these approach although right now the interactivity API is mostly focused on the front end and if I'm not mistaken phase 3 and phase 4 well and they are kind of related but yes maybe we have already in conversations of how should the preview of the interactivity should work in terms of UX from the blog editor how can I preview my interactive blog so everything we do for phase 3 and phase 4 should work out of the box with the interactivity API this is like a parallel I don't know how to say but it has to work we are confident that is not going to be an issue okay cool um why did you choose preact instead of react Luis do you want to answer that one um many reasons not just a single one we only have a few minutes left yeah I think that I don't know where I know I've answered that somewhere yeah first preact is smaller so it's more suited for the front end it's just so we're doing all this with 8 kilobytes which includes preact, preact hooks, preact signals and 2-3 kilobytes for the interactivity API on top of that that's around 10 kilobytes something like that which is much smaller than react itself which starts I don't know if that's 45 47 kilobytes um so that's one thing but well compatibility with react was also important um so that kind of also kind of because sometimes you for a very complex react components you don't need server side rendering for them like for example who commerce checkout or something like that maybe you want to reuse your editor component and load it in the front end and that's also something that preact is capable of doing so because react has the preact compact layer is more performant than react also now it has support for signals it's also about performance signals are a bit more performant than as sometimes preact using signals can bypass the VDOM and do apply changes directly to the DOM so we took like performance so this is a preact is great in that sense um and also I lost my thought in there oh yeah we have the we have the link here oh it's more HTML friendly so for things like SVGs and things like that preact just works out of the box with what HTML uh with the HTML attributes and in react you have to do some kind of translation because it's it doesn't support attributes it needs everything to be in camel case um yeah and I think well it give us a out of the box yeah I think I'm missing one but which is not in that list I think it's important oh yeah extensibility sorry that was it yeah it's there okay preact is extremely extensible yeah preact has something called option hooks where you can hook into into their engine and that's where we are hooking for the for the directives that's yeah that's probably the most important options because react doesn't have extensible extensibility API so in preact we are capable of hooking in and do things very low level there okay thank you we've got one last question from Paul because we're just coming up to time now it's still the proposal but seems quite usable and the question is can we start experimenting with it yes you can but be aware that it's experimental and the API is made change so at your own risk it's possible you can install the block interactivity experiments plugin and create your blocks using the interactivity API but be aware that the API's are not definite so I am not defined well are kind of defined but they can change so maybe you create a block now using the interactivity API and it's gonna be broken if the API's are updated so and on a similar point how is this eventually going to be implemented will it be a feature plugin or is the plan to after the proposal stage to merge it straight into core our idea is to right now it's a separate plugin because we were experimenting with different approaches but our idea is to include it as experimental in Gutenberg first test it test it in some blocks and once we feel confident we can integrate it into core okay amazing thank you very much we're at time so I'm not going to take any more questions now so for those people who arrived late there is going to be another presentation on this topic at 1700 UTC today that's a presentation targeted at the America's time zones and that's going to be done by Michal Kaplinsky so just to wrap up let me remind you that WordPress is open source anyone can contribute and in particular people can contribute to the interactivity API as well I've posted the link earlier but let me repost the link to the repo once again in case you want to dig in and see how you can contribute I'm sure contributions would be welcome questions and feedback yeah everything yeah raise issues as well use cases so it remains to say thanks everyone for joining and to in particular thank Mario and Lewis for this amazing presentation thank you so much thank you okay that concludes thanks all for joining goodbye thank you bye