 Okay, well, great. Well, thank you for everyone for coming to five actors. So we're gonna get started and I will in the background try to figure out the captioning thing. So today we're gonna be talking about the Interactivity API and we have Mihal Chplinski here to talk us through it and give us a little example of some demos and stuff or a small demo and then we'll kind of open it up for general questions. So if you want to ask a question, you, there should be a little hand raise button down on the bottom of Zoom or you can paste it into chat and I will do my best to make sure everyone's questions get answered and yeah, just a couple of links to share. So here's a link to the, I'm just gonna drop it in chat here. So this is the link to the make posts that is that announces the API and there's also a link to the project repo if you're interested in getting involved so I'm trying to click on it and it's not working. There we go. So couple of links there. And yeah, so like I said, we have Mihal Chplinski here. So I'll get him to explain to us his background and his involvement with the API and then we'll probably just hand it over to him for demos. So over to you. Yeah, thank you so much, Ryan. So yeah, hi, Mihal, I work at Automatic and I'm part of the team that has been involved in the development of the Interactivity API. Prior to that, so prior to working in Automatic worked at a small startup called Frontity which was working on a React framework for Headless WordPress. So that's kind of my background. And yeah, the company got acquired by Automatic and we've stopped working on the framework and kind of diverted our efforts into trying to bring the same kind of developer experience that you would have with Frontity back into WordPress. So the Interactivity API is kind of the first step towards that vision. Yeah, and by the way, I'm from Poland and I live in Peru. So yeah, just a fact about me. All right, should I just go ahead with the demo? Yeah, sorry, yeah, just dive in and I'll track the questions as we go and then after you're sort of the formal demo sections then we can kind of start asking you the hard questions. Yeah, all right. Okay, let me share my screen and all right. So yeah, as part of the proposal for the Interactivity API, we've created a demo site for different kinds of movies and with the Interactivity API, you can get this kind of user experience that you are typically accustomed to from single page applications. Like when you like a particular movie, the number of likes are synchronized with this other movie likes block over here in the header and you can navigate to an individual movie page and you can see the likes are still visible here. So you can take notice that this movie has been liked. The likes are preserved in the header. You can even play the trailer and you can navigate to let's say individual actor page. You can go back to the movies page and yeah, it all just keeps working and like the movie trailer keeps playing and the navigations are instant. And yeah, you can even search for movies. So let's say you search for like avatar. Oh, it's not there actually. Okay, let's search for, I don't know, Marvel. No Marvel movies, okay. Superman, no, Spider-Man, all right. So as you see, the search is instant and it's all built with just WordPress and interactivity API. So let me show you how it interacts with, integrates, sorry, with the block editor. For instance, this is the search template of the, you know, WordPress site in this theme. And if I edit, for example, let's say post template, yeah, I can add here maybe like this movie and maybe let's put it in a, yeah, let's group it actually and let's add another block here and let's add the movie icon. Well, this should maybe be a row instead of a group. Can we, oh, the zoom is, zoom controls are, ah, calling it up for me. So no, convert to, I can convert to a row. Yeah, it actually, it doesn't matter. So it will be, the layout is not perfect but it's just to show the principle that you can edit the search template and now if I go back to my site, I can actually search for, let's say, I don't know, shh. Even without reloading the page, I can search for Schindler's list and I can already see the updated blocks show up here because the content for this search is just the HTML that is part of the search template. So yeah, this is basically like a teaser of the functionality that we want to bring into WordPress and yeah, I'd be very happy to hear people's questions and concerns and yeah, any ideas. So stop sharing. Yeah, I think if anyone has questions, just go ahead and unmute and ask them or if you're more comfortable dropping them in chat, I can facilitate that or I don't know if anyone has their hand raised. I don't see anybody hand raised. So if, yeah. Yeah, I'm happy to get much more technical than this, by the way, just depending on people's appetites. Yeah, I'll just go ahead and ask, like just say that like button, like how much, like, what is the code for something that look like? What are we at switch to do as developers to build that functionality? Sure, yeah, I can, in fact, I have it open up. I can just show it, I can show my screen and show you. Yeah, that'd be great. It's, give me one sec. All right, so this is the repo for the very same demo that you have just seen. And by the way, this code is all up on GitHub as well. So you can take a look there. I don't know if Ryan has dropped the link in the chat perhaps. Yeah, it should be in chat there. I can drop it again though. Okay, yeah, perfect. So there are a few pieces. So of course, you will first need the interactivity API runtime. At the moment, it's distributed as a plugin but we are aiming to merge it into Gutenberg at some point. So there's no definite date. There's no definite timeline yet. At the moment, yeah, you can just install it as a plugin and use it to build your blocks, your interactive blocks. For the interactive blocks, you'll need a couple of things. So first off, you will need block JSON and add interactivity true in order to opt in for your block to be an interactive block, all right? And then you will want to, well, you also want the few script. This has been part of WordPress for a couple of releases now. And you can add your view and render files to... So yeah, let me start perhaps with the render file. So the render PHP file is the file that is used to render the front-end content of your block. And in here, you'll see there are a couple of things that you might not be used to. So for example, this WP store. I was gonna say, yeah, what is the WP store on PHP side? Yeah, on PHP side, this I believe is not mentioned in the proposal itself. This is a way to create initial state on the PHP side on the server so that you can preload your store on the JS side, right, on the client side. You can preload it with some initial values from the server. So you could, for example, do something like, let's say, not selector, but maybe like state. Yeah, let's go with that. And yeah, you could have, you could pass, you know, you could maybe like translate the movie title here. And you could use the... Okay, let's say it's not like movies, but maybe, yeah, okay, let's make it array. And then, I don't know, one is some, I don't know, some movie title. I mean, it's a dumb example, but just illustrate the idea that you can do some pre-processing of your state on the server. Does that make sense? Yeah, totally. Yeah. Yeah, and then your PHP file, you'd add your directives like the data WP context, which will, in our case, let me maybe perhaps remove this so we don't get confused. So in the context, we will store the ID of the movie and then on a click, you'll add it, yeah, you call this action, which is defined in the view file. And this will add this current movie to the array of like movies. Does that make sense? Yeah, that's a great example. And it's simple to follow. So that's what I was concerned about a bit, how complex this is, but it seems pretty straightforward, at least in this example. Okay, yeah, I'm glad to hear that. Yeah, there's a bit of, in your PHP file, there's a bit of PHP, HTML, and like JSON, like Alt and one line of code. So that's a bit odd to see. Yes, so this actually, it's a known concern. So let me go to this way. I think there's already an issue on GitHub. I don't recall who has started working on this to create some helpers specifically for like passing serialized data to the context so that you don't have to do like three different languages on one line, which is a bit unwieldy. Yeah, I could definitely see folks getting like tripped up on that a bit, but outside of that, it looks pretty straightforward. A couple of follow-up questions in the chat that I'll just jump in now before we lose them. But Weston Reuters asking, how has state persisted? Like the life movie state, for example, is that just not currently wired into the user meta, for example? Yeah, so currently in the demo, no, it's not persisted in any way. So you could, I guess you could do it just like you could do, you could do whatever you want. Let me say it like this. So the state that you have in your store, you can store it in local storage. You can store it. It would be feasible, for example, in your actions to hit the REST API to save that liked option to a user meta. But is that part of the current API now? I think, Weston, please correct me if I'm wrong, but I think that's kind of where you're going with this. Is there a mechanism in place now? Yeah, so at the moment, there is no mechanism for it. So there is no way that's built in into the interactivity API to persist it from the client to the server. But yeah, it's something that we're very much aware of that people will want to do in the future. Yeah, so we have, we've been thinking about it a little bit, but it's not, we haven't decided yet if we will do it via the REST API or by, for example, yeah, there is, so I can say this, there is one example that I could maybe show super briefly. We have been working on a very, very early experiment of a comments forum that uses interactivity API and it shows the comments and reloads the comments. Just, Mihail, can you just zoom in a little bit? Can you just make your font size a little bigger? There's just been a request in there. Is that, is that good? I think so. I mean, that's good for me, but M requested it. Yeah, let me just, that's okay. I'll just bring up this example. So we've worked on an example where the comment forum can submit comments back to the server and then using a post request and then get that content, get that content, basically grab that content that's received back from the response and then diff the page and put the comment in the right place on the page. So I think the interesting code will be here in the index PHP perhaps. Let me, no, in the Vue.js perhaps. So I don't know if everybody can see this, maybe I can make it a little bit bigger if that was the request, but there isn't a lot to do it. So it's basically one action which grabs the form data. Obviously it's still an experiment, an entire example. It posts it to WP comments and then gets the response and it will diff the DOM and then do a client-side navigation. So just skipping over a lot of details here. Just want to note that this type of interaction, in this case it has to be also integrated with client-side routing, which is what this navigate function does. This is something basically too, it was a long answer to a question to which I can just say yes, it's something that we are thinking of but it's not the current focus let's say. So we want to make sure that the API is solid as it is first without the server-side persistence and we will add it in the future. But it is currently, you can install this as you're doing now and you could roll your own solutions for persistence at this point, right? Yeah, so you could do something like what is done here in this example, yes. But of course with all the caveats that the API is still very experimental. All of it can break at any point. Related to that original question, there's another question about cache logic that's part of the API, I assume. The question is related to the question above, which was the question about state persistence. Is there any cache logic that is part of the API? I mean something searching, something searching for the same movie more than one time before refreshing the page. Okay, so I wonder what, caching at what level the person had in mind. My guess, just having read that, my guess would be similar to how if you hit a data store and now you hit it the first time and then the second time, if I do entity records for posts, I get the 10 most recent ones and it doesn't hit the server every time I recall that. That's my guess. This question is from Renato de Carly, if I'm de Carly Rosa. So if there's a follow-up stuff in there or if I'm making assumptions I shouldn't, please let me know. Is there a caching layer of any form at this point? Yes, yes. In fact, the pages are in the demo. It's using client-side navigations and the HTML pages for the individual movies, for instance. They are both prefetched and cached locally. So this is why you can navigate instantly to an individual movie page. So the demo is configured in a way that all the links in the viewport will get prefetched. It's also something that we want to make configurable so that if you opt into having client-side navigations, then you can prefetch, for example, all the links. You can prefetch only the links on hover. You can maybe only prefetch them with intersection observer, stuff like that. And so this is the part where the cache gets populated and the pages are being cached for subsequent navigations. There's a question in chat about what about the store? Does it get cached? Does the store get cached? Could... Which part of the store would you... I'm not quite sure what caching in this context would mean. Well, I guess right. So we have that PHP file that populates the initial store, which renders your HTML. I guess does the client-side store get cached too? Is that dynamically generated like when it loads? What's that interaction look like? I don't know if that helps clarify. So the store is populated with the data from the server side. So this store, right, it will... If there exists a WP store, by the way, just noting that this naming is not final, so it's not... It might be WP store, it's likely to be something else in the future version of the API. It will populate the data for the store on the client-side. And this store is not... So if you reload, like if I reload this tab, for example, there is no... this state gets blown away. So you'll see that there are no likes anymore. So the state is not preserved. However, if you're due to what I was showing, perhaps this is what the person meant by this question. So if I click on a bunch of movies, and I like a few movies, and then I do a navigation, navigation back, so the store is preserved across the client-side navigations. Because we are doing... Perhaps I should explain a little bit what I mean by client-side navigations and how they are used in the API, because this is perhaps a source of confusion. Sure, I think that makes sense. Yeah, the navigations that are happening right now, they are like a single page... They are like navigations in a single page application. And there is no reloading of the whole page. It's just that the HTML for those pages has been prefetched and it's cached, and the interactivity API diffs the page, and in a way... I could say similar sort of conceptually react server components work without going too deeply into technical details now, and then diffs the page, and then patches it with the HTML from this new page. So for this reason, yes, the store is... I wouldn't say cached, but the store is preserved across the navigations, because they are navigations in JavaScript. So all the JS state is preserved on the page. I hope this made sense. I can try to clarify. We got a thumbs up. I think... Yeah, that makes sense, I think, in the sense of... It's cached in the sense of it's a big JavaScript object that's running in the browser. But beyond that, because there's not really a persistence portion in Iron Dev, there would be no way to cache that on the server side. No. So I could... Yes, by the way, there's one thing I could show. In the interactivity plugin, it has just one setting, which is client-side navigation. So if I turn it off and save, and I go back to the page... Oops. Yeah, if I reload the page, let's say I like some movies, great. I'm still on the same page, so the likes show up and they're synchronized. But if I now navigate to a new page, the state gets blown away because I've disabled the client-side navigations. So this is just doing a normal, regular page reload. So the interactive blocks keep working, but we don't have the client-side navigation. We don't preserve the JS state. I hope this helped clarify it a little bit. I have a couple... I have some pre... It makes sense to me from Richard. So I have just a list of questions that we can ask, and maybe we can rapid-fire them through them if you'd like. One question is, how can I learn more about this? Where can we get more info on this? Sure, yeah. So obviously the proposal itself, I think there were a lot of great comments there as well. We've tried to put some effort into the FAQ at the end of the proposal as well to sort of pre-empt questions that people might have about it. And then there... We are actively working on the API on GitHub. So there is a repository that I... I guess you have posted a link to. Yeah, I'll... Yeah, as well as... If you want to look at just examples of how this particular demo has been built, there is also a separate repository for that. And yeah, you can find us also obviously on the WordPress Slack to hit us up with any questions that you might have about it. Cool, so there is... Under the hood, there's some pre-act use going on here. So the question is, why did you use pre-act over react as in the editor? Right, yeah. So there are a few reasons for using pre-act over react for us. So first one, just right off the bat, is the size. So pre-act is about, if I remember correctly, 5 kilobytes or so. And react is... Well, it's significantly more. I don't remember the exact number. React plus reactdom is about 50 kilobytes maybe. I might be misremembering it, but it's significantly more. So it gives us a lot more budget for the JavaScript of the website to fill. And secondly, the pre-act is very extensible. And it has something called pre-act hooks. So not to confuse it with the hooks in the same way that react has hooks. So pre-act has... In fact, I think they're called... Sorry, I think they're called option hooks. Yeah, I should be clear about it. It's a way to extend pre-act itself, which is something that react does not have. And this is what we were able to use to create the directives layer on top of pre-act. And this is what we're also... We're able to use to create these client-side navigations feature as well. And yeah, the react also has... So it's compatible with react through a pre-act compact package. So in case we ever want to reuse the same code across the block editor and the front-end, there is sort of a pathway towards that. And yeah, the... So pre-act is very performant. It's also... There are a number of reasons. It's performant, and it also... It's more HTML-friendly than react. So pre-act is, for instance... Let me phrase it this way. So react has some incompatibilities, for example, with web components, which pre-act does not suffer from. So there are a lot of small, medium reasons that kind of all together pointed towards pre-act for us. The follow-up question to that is, does this mean Gutenberg will move from react to pre-act, the project Gutenberg? Right. No. I think at least in the short to medium term, there are no plans to do that. So I think there would be... And in fact, I don't believe there would be any benefit to that, really, for the block editor. So the reasons that we are concerned with in choosing pre-act for the front-end, they don't really... They're not the same for the block editor. So while the bundle size is important, of course, for the block editor, it's less of a concern for... Sorry, the bundle size is a concern for the front-end. It's a bit less of a concern for the block editor because it's only just loaded once. And yeah, so we have no plans to switch to that. Okay. Great answer. If anyone else has questions, feel free to drop them in. I'm just going to keep going here. But do I need to migrate all of my blocks to use the interactivity API? Right. No. The thing with the reactivity API is that it will work alongside any other blocks using any other system, jpanel.js, jQuery, whatever. So you don't have to migrate all of your current blocks to it. There are some benefits, though, to having all the blocks on your site use the interactivity API if that's a possibility. So, for instance, the client-side navigations that I've been talking about before that I've mentioned, which allow you these kind of seamless page transitions, those will only work if all of the blocks, all the interactive blocks, opt into using the interactivity API. So there is, yeah, if you have other blocks that are using other interactivity mechanisms, there is a likelihood that they might break with using the client-side navigations. So for this reason, they should all, if you want to have these page transitions as a user experience on your site, all the blocks should use the interactivity API. Cool. Next question is, can I use directives in the block editor? Maybe, I don't know, if those who haven't read their proposal and stuff, maybe can you explain what a directive is and then whether or not we can use it in the block editor? Right, right. So, yeah, the directive is, the directive is any of those special attributes that starts with data, WP, for example, WP on, WP class, WP context, those are the directives in our system and you currently, they're not designed for the block editor at the moment. We are thinking of ways that this could happen in the future, but at the moment, you shouldn't use them in the block editor. So that's kind of a brief answer to that. Right. Okay. Sorry, go ahead. Yeah, no, no, go ahead. Yeah. Okay. There's a question coming in from chat. PHP actions and filters while loading a new page through the API on the front end are already totally solved? Question mark or are there challenges to solve there yet? I think this question has to do with the client side navigation and making sure that all those hooks and filters that we know and love are actually being fired. Yeah, yeah, yeah. Yes. So yeah, that's a really good question. PHP actions and hooks indeed are, you can say solved. So what that means is that I think this person is referring to the problem, which happens if you have any sort of JavaScript framework doing the rendering or hydration on the client side. And then you have some PHP actions and hooks that can change the server side markup. So in this case, you'd end up with a with markup on the client side that that's generated, let's say by react. That is different from the markup that's generated by the server because the PHP actions and hooks, they only run on the server, they can't run on the client. But in this system, using directives, all the HTML, so the content, the directives, they are generated on the server side. So there is no hydration per se happening in the same way that there is with let's say with just react. So the any HTML that you, you will modify with with your actions and filters, it will still exist on the client side so you don't have to worry about it. That's awesome. That's such a great question. Thank you for asking that one. Very cool. All right. Oh, okay. This question, how can I preview the interactivity in the editor? Yeah, so the, I think, yeah, you mean how would you. Okay, how would you preview it in the editor there. The editor side of your interactive blocks is basically up to you at this point. So, yeah, you. So yeah, like I was like I mentioned before that we are thinking of ways that you could use the interactivity API and the editor. But, and there is there's some potential for it but for now they're not designed for the editor so you have to your edit JS files, they have to be so this is for example. Right, the movies demo, the edit JS file of this, this movie like button or movie like icon. Yeah, it's just a static emoji so you don't, you can't really see the interaction in the editor just yet. But you could, for example, add like you could create that now like it is possible now with custom blocks to be to to sort of fake the front end experience, but it's not part of the API currently. So what I'm saying, so it makes sense, you could fake it in a sense that like you could re redo. You could do the same interactions, just using react here on the in the editor side and use react blocks to, let's say like do some use state here. And then pass, I guess like an on here like passing on on on click, right. So you could sort of fake it on the editor side but there is currently not a way to to read like, like it was phrased preview the interactions on the editor side. But yeah, it is something that we are we're thinking about and we will work on. Awesome. Next question is, do I need to know react PHP and this new interactivity API. Do I need to. They need to know PHP react. And this new interactivity API. Interactivity API. Right. So you don't. Well, you, you do have need to know PHP and react in order to create custom blocks already. I would say at least custom dynamic blocks. So you if you want to add interactivity to your blocks using the interactivity API, yeah, you will, you will. At least needs to understand how to add directives to your, to your PHP files, but I hope that the API is very straightforward and it's, it's just adding attributes to to HTML generated by PHP and adding a bit of state in your state and actions in your view JS files. This covers, I think a large portion of what what people want to do. And, in fact, you don't have to so if you just want to add the interactivity. On the front end, you don't have to write any react or pre act. Unless, unless you are writing custom directives. So if you only use the built in directives like the data WP on click data on class context. You do not have to actually write any components react or react. That was good. Can I ask how many directives are part of the default package? Yeah, good question. I also, it's about, I want to say, a dozen. So it's, I can, if I go to GitHub, I can tell you exactly. So I think there are, actually, if I, I think in the proposal that we do already mentioned all of them actually, if I scroll down there. Yeah, there is, yes. So the, yeah, these are all the directives that we, we want to have in the runtime eventually, not said just, I just want to be clear that not all of them are implemented yet. So the, for instance, WP error is not implemented yet in the, in the runtime. I think WP. I think all the other ones are, no, yeah, the salt and fill ones, one is not either, for instance, and yeah, it's very likely that in the, if there is like an initial version of the interactivity API as let's say part of Gutenberg that it will initially be a smaller subset of those directives. And to follow up, you mentioned, like writing custom directors, how, what is that, what do you have any examples of that, like that you can share. Yeah, I get a good question. Let me think too. I don't have an example handy, I think, and let me see if there was an example here in the WP demo, I think. Perhaps in the video player was the one. Let me see there. No, I think not. But yeah, I could, yeah, I could show you so let me, let me show you how directive is implemented in the runtime so that you can kind of get a feeling for they are implementable in the very same way that you would extend the, that you would add them in your code. So if you go to, for instance, directives, this is, oh no, sorry, here, runtime, directives. Can we close this? Yeah. For example, let's take something simple, like maybe, yeah, on. So yeah, by creating a directive is a matter of calling the directive function. So this is like a generator. I don't know what to call it for directives. The name for your directive and the second argument is basically it's actually a preact component. So this whole thing is actually a preact component and it might sound a bit weird, but it's actually very, it's a very powerful way to express custom directives. Yeah, well, thanks for sharing that too, because I just wanted to have a visual idea of what we, you know, I'm just thinking through ideas like what can I build with this, you know, and how would I do it. So, thanks for just sharing that part of the code. Yeah, yeah. Sorry, I got caught up in the code there. So I have a question for you. It's on our list, but I'm going to jump over to it. So I write a lot of blocks. And what is the benefit of using this API over what I'm doing now? So for the example of like the blocks that have the heart block, the sort of the life block, like I have a VJS script where I have my whatever JavaScript in there doing whatever. What's the benefit of migrating my existing block over to that? Or why should I go with this instead of just doing what I've been doing up until now? Yeah, so that's a, yeah, that's a, that's a, that's a very good question. So I would say that the benefit number one is standardization. So you, you're opting into a system that we hope will become standard for all WordPress blocks. So what that implies is then that for example, the different blocks, when they use the same system for interactivity, they can communicate with each other. So you can have a gallery block talking to a dropdown block talking to another block and they use, they all use the same basically the same store and actions for talking to each other. So they, there is, there are no, you know, incompatible, you know, black boxes that blocks are currently that they, you know, they can't understand what's happening in another block. So that's, I think that's one big benefit. Having, yeah, I think having the interactivity API also, also is a benefit, for instance, with the client side navigations that we, that we showed off in the demo. It's, it's not something that you can just bolt onto your, like your page built with just vanilla JavaScript and or jQuery or just some other, any other JavaScript solution you, it's something that you want you have to kind of take into account. As you design your whole page, like if I, if I can phrase it this way. So with interactivity API, it's designed to work with client side navigations from the get go. So you, if, if your blocks all use it, then you get that benefit from just by using it, you can, you can get these smooth page transitions. Yeah. And, yeah, I hope that it's, if the alternative is using, is using react, just react to render your blocks or just use, just use vanilla JavaScript, I think there are advantages to either one, like above either one of those solutions. So if you just use react, then you can't server side render your blocks, right? Because react, you can't run a NodeJS server with WordPress. If you're just using JavaScript, then that's great. But then you are always reinventing the wheel for, for, for, you know, for every, you have to add custom solution for every little thing that you, that you want to add to your block. And you're probably better off using a standard, like, like we're proposing. So yeah, I hope. Yeah, that's, that's a great answer. Yeah, I hope that answers it. Yeah. There's a couple of questions in chat, and I just wanted to get this one out of my head, but so feel free to answer it later, but it's, is there a single store across the entire front end, or can different because you're calling store in every block. What if I had, like, what if I wrote a block and Justin wrote a block and I installed that on both my pages, would the store be the same? Or would there be multiple stores per block? Yeah, good question. Yes. So there, there is, there will be one store. The stores get merged on the client side. So this is perhaps this was not the most clear feature. And maybe it wasn't clear why the stores are structured this way. So they have the, the store function has selectors actions and then they have this, I guess, a namespace, what you could call it, and then the name of your action. The reason for it is, is precisely that that the stores are merged on the client side. And if you have multiple blocks using the store, then you want to sort of, you want to avoid name clashes. You want to avoid, yeah, your, your stores getting over right. That's a, that's a great answer. Sorry, I'm not trying to rush you. We have one more minute and there's still three more questions in chat that I definitely want to get to. Larry is asking as a beginner with API, can you please mention the tools that I'm required to install for learning API testing? I'm assuming Larry is referring to the interactivity API. Maybe just give us a Cole's notes of what you're going to need to get started. And yeah. All right. So if you'd, I assume that you want to use it on your site to write interactive blocks with it. Is that correct? That would be my assumption as well. Yeah. Yeah. Okay. Yes. So you would need the, the interactivity API plugin. So you could get it, for example, from it's not currently in the, in the WordPress, the plugin repository. But you can just get it from the releases page, which I can't see right now. Yeah. Okay. That's because I had zoomed. Okay. Yeah. You can just get it from the releases page and you, you can just start writing your blocks, your interactive blocks with it. I would advise perhaps, or I would suggest to look at the code of the WP movies demo to look at the blocks there and how they are organized and the bits and pieces that you need. So the huge JS file, the rendered JS file and what to include in the block JSON, for instance. Okay. Looks like Larry is asking for more generic stuff. Larry, go ahead and ping me after them after this and I'd be happy to help you out with that. I just want to keep the questions specific to the interactivity API, but I'm more than happy to talk to you about this after Anton also has a question which is related to why should I use this. Are there significant gains or tradeoffs between this and something like Alpine JS that is directed based as well for interactivity. Okay. Yes. Yes. So that's a, yeah, again, a good question. And yeah, that's probably a bit of a longer answer. I'll try to make it as short as possible. Yeah. Alpine is a great framework. It was definitely an inspiration for the interactivity API with Alpine though. Alpine is not compatible with server side rendering of the directives, for instance. So, yeah, I don't want to get, yeah, if we only have a few more minutes, I don't want to get into all the details. I believe that we do specify it in the proposal. It might be a bit, you might have to search for it in the body of the text. The other advantage over just Alpine is that, yeah, with, so we chose basically, let me put it this way. We chose the API to be built on top of Preact rather than just using Alpine, which to me comes with more benefits, like Preact having a bigger community than Alpine, which is just maintained, as far as I understand, is just maintained by one person. With Preact, you get a better syntax for creating custom directives. So, like I was mentioning, I was showing it before. No, this is not it. I think it was on GitHub, perhaps. Yeah, to make it brief. So, to create custom directives, the custom directives are basically just Preact components, which I think is a much more elegant primitive for creating those custom directives than the Alpine way. So, yeah, I think all those reasons, I think to me speak to Preact being a better Preact and the interactivity API that's being built on top of it is a better option. Great. Awesome, awesome, awesome. So we're about four minutes over. If anyone else has any other questions that they'd like to, well, there's a couple more questions. I'll just kind of like throw them out again. We can stay a little bit longer if people ask you. Yeah, that's cool. As long as you have time. Sorry, I'm just assuming you don't have time today. Yeah, that's fine by me. So, a question, is this going to be a plugin or will it be part of core? Right. Our goal is to merge it into Gutenberg and then eventually make it part of core. Yes. At the moment, yeah, we do distribute it as a separate plugin, but it was from the beginning, our goal to make it into Gutenberg and core. What happens with naming conflicts? I can imagine plugins, same toggle actions.toggle, for example. Right. How does the API handle that? So this was the reason for us to introduce this namespacing in the stores. So this is, let's say, I think it's not a hard requirement in a sense that it's, I think it's not enforced by the framework at this point, but we might make it so in the future that in your store, you have selectors, actions, effects, and state, and then a namespace, and then either the name of your action, state or whatever, or some other maybe even more deeply nested object. So this is a simple way to avoid the conflicts. Just quick follow up on that. So let's say that I, like I keep using Justin as an example because he's right there in my viewport, but if I had a store and I use WP movies, I had a store selectors, WP movies, and then a thing called save, how would it handle, like if I did use the same namespace, how would it handle conflicts? Or what's the plan? Maybe you probably haven't hit that edge case yet. And if that is an edge case, I'll just shut up and we can move on. I was wondering, what's the plan there? Yeah, so it would get overwritten by the contents of one or the other block basically. So it's, yeah, there, I think, yeah, it's exactly an edge case. So there's no, we are, we're, at the moment, yeah, we're banking on people using the namespaces for avoiding conflicts for this reason. And it's not, I mean, I think it's not unlike the name block naming scheme or pattern at the moment. So you are encouraged to also like name your block with something like this, right? So that there's no confusion between the block names, right? So it should be something, some namespace slash your block name. Okay, wonderful. I think that's it for all of my sort of pre-baked questions here. I guess we can wrap it up, unless I don't see anything else coming in in chat and I don't see anyone with their hand raised. So let me just say how thank you for taking us through this and for letting me subject you to all of its questions. And if you want to reach out to me, you can on WordPress Slack on Welcher or I'm Ryan Welcher on Twitter. You have to do that and I can help try to help answer questions. Mihael, if you're, are you on Slack? You know, would you prefer people reach out to me and I can reach out to you or how would you like to do that? Yeah, I can. Yeah, I'm very happy to answer questions directly as well. Okay. Yeah, it's. What's your, what is your past? Yeah, maybe just drop your Slack, my Twitter. Yeah, whatever you're comfortable with. If you completely put it on the spot, so sorry for that. Yeah, no problem. And your home phone number, your mailing address and all that stuff, right? Yeah, I'm just trying to remember if it's, yeah, that's it. Okay. Because I have a different one. Yeah, it's just that's my, that's my handle. This should be the link to get into the chat. Oh, thank you, Weston for doing that. Also, well, just a couple of sort of like housekeeping things. I just wanted to mention that the developer blog, a developer that will press.org slash news is now at a beta and it's live. Go read all the awesome stuff that Justin does there. The 6.2 is out. So if you haven't updated, go ahead and update the development of 6.3 is in fan is in the planning stage right now. I'll drop a link here for sort of for the 6.3. Development cycle stuff. A couple of word camps coming out work in Europe is eight June 8th to 10th. Work in US is August 24th 26, and there's lots of local word camp stuff being scheduled. I'll just put links in here. But yeah, but thank you for coming and we have thank you for taking us through this and like I said, if anyone has any questions they can reach out to me and I can wrangle them or however we want to do this but otherwise I think we can call it a meeting. So, thank you. Awesome. Yeah. Thank you so much, Ryan. Yeah, that was great hosting from you. And yeah, I was very happy to be here and answer your questions and yeah peace. Feel free to reach out to me as well directly if you have any questions about the interactivity API. And yeah, be very happy to hear your questions and your feedback. Okay, well, I'm going to end the meeting but thank you everyone and I'm going to be putting the recording up on repress TV as soon as it's sort of ready to go. So, thanks a lot everyone talk to you all soon. Bye.