Hello. So yesterday we've heard some great things, exciting things that are available already today, like for example, 6.4, right? And also some new things that are coming either soon or more into the future. And one of those things is also the visual editor. So my name is Martina Michlova, I'm a senior frontend solution architect here at Magnolia. And when I talk about frontend, I don't only think about frontend as Magnolia frontend, so what you see when you are interacting with Magnolia, but also the frontend that you as developers are building, that is connected to Magnolia. And I'm going to touch a little bit both of these today, because when we as frontend developers are building this frontend application that is connected to Magnolia, we have to think about not only the end users that are going to browse through our page, but also about the editors. Since these editors are going to interact with the page, they are going to edit the new content, edit the content, etc. So what do we want for our editors? We want for them to have one good editing experience, no matter which technology we are using. If we decide to use React or FreeMarker, Angular, SSR, whatever, it shouldn't make a difference for the editors what technology we decide to use. And if there are some features that are available in Magnolia, they should be available regardless of the technology that we've decided as developers to use. Also, we want it to be very simple and easy for the editors to edit the page. So we want it for them to be fast, easy, and that they are able to see the changes that they do right when and where they are doing them. And of course, maybe, well, not of course, but maybe you have met with this, that you built a nice page, you followed the designs, everything was great, but then you open it in the edit mode, and now the designs are broken because of the green bars that are injected in that. So ideally, we want the editors to see the page as it should be without the designs breaking. With that, meet the new visual editor. Here, we can see the new visual editor. Inside is the React application. In this case, React application, that is the front-end application that you are building that is connected to Magnolia. When we hover over this React application, we see that some components have this hover overlay. That means that these components are editable by Magnolia, and we can edit them and interact with them in the visual editor. If it is a simple text component, text field, we can edit it directly here with the inline editing, change the value, and the value is saved into the Magnolia. Adding a new component is also very simple and straightforward. We can edit, and if the component contains some text fields that are inline editable, we will see the component with the placeholders. So editors can edit the component directly in this view in the visual editor without the need to opening any form. So when they start with simple components with just the content in the text, they can do it directly here. If they want to reorder the components in the page, move the components around, they can just take the component and drag it across the page. We can see here the visual indication where the component would land if we would drop it, and when we drop it, this is where the component is now saved, and we now reorder the components in the page. Deleting a component is also very simple. We can see there is a delete button there. After confirmation that we are sure we want to delete it, the component is deleted. If for some reason you are not satisfied with your change, you can see there is an undo and redo button in the up bar on top, and we can undo and redo our changes. So what we have seen here is the visual editor, and how it looks like and how it works is that the visual editor, what we've seen was the visual editor. Inside the visual editor was, in this case, the React application loaded in an iframe, and your application, when we are in the visual editor, is not connected to Magnolia directly. It is not communicated with Magnolia. Visual editor owns the data when we are in the edit mode. What it means is that the visual editor communicates with Magnolia via the new Magnolia content API. It fetches the data via the get and patch requests. It communicates and updates the data. And then your application just renders the data that it gets from the visual editor, and this communication is handled by the visual editor SDK. Let's look at how such a data flow would look like when we are talking about edit and save of the component. So let's imagine we are on this visual editor. So the visual editor fetched the data from Magnolia. It passes the data to your application. Application renders the content. Now, the editor author wants to edit a component. They click on the component. SDK in their application catches this event, sends a post message to the visual editor that this component is about to be edited. Visual editor fetches schema from Magnolia content API. And this schema gives us all the information about this component and how we are able to edit it. Visual editor then renders a form with the fields that are using the Magnolia design system components. And author now sees the visual editor with the drawer where they can edit the fields. When they interact with it and edit the fields, visual editor owning the data updates its data. And sends the updated data back to the SDK, your application. Thanks to which we end up with the live preview of the page. And after some inactivity, visual editor triggers the save using the patch request. If everything is alright, Magnolia says all good and we show the status saved. So, what about your page? How will you be able to use the visual editor? Your integration point will be the new visual editor SDK. There are four steps that we will have to follow. Number one, install. We have to add the SDK into your application using the regular NPM install, for example. Number two, initialize. So, as we said, visual editor has to own the data when we are in the visual editor. So, we have to let it own the data. As we see here in this snippet, when we are in the author mode, we let the visual editor own the data SDK, subscribes to the data and gets the updated data live from visual editor. And when we are in the public mode, then we fetch the data directly from Magnolia new delivery API, as we would do normally. Number three, map. We have to match Magnolia components to your components. It is the same way as it works right now. So, here in this case, we have the React application. So, we match the Magnolia components to the React components. And number four, markup. We have to flag what is editable. Here we can see a simple text component. And we have to make sure that the visual editor knows that the component is selectable and movable in the visual editor. So, we have to pass there the component attribute. And also, if this component contains any text field or rich text field, we can make it editable for inline editable for the editors. And we do it by flagging it as editable. Now, let's look more in depth into fetching the data and adding a new component. So, what we see here is, again, the visual editor now connecting to the new Magnolia content of Magnolia delivery API, fetching the data. This data would be the same if we would fetch directly from the React application. But in this case, visual editor does it since it owns the data. And then, visual editor sends the data to the React application, which renders the content. When we add a new component, visual editor owning the data creates the new component. And we see the live preview directly on the page. And then, right away, visual editor also sends a patch request to the Magnolia content API using the ad operation creating the new component. We send there this newly created component. And what we get as a response from the content API is the updated page data. When we are fetching, when the visual editor is fetching the data, it also fetches the available components in the given areas that we have there. That's why when we click on the plus sign before, we've seen different list of available components than when we are creating a new component here in the nested area. And always, when we create a new component, it is directly saved into Magnolia. So how about the editing of the component? So we've seen that we can inline edit components that are text fields or rich text fields. But also, we wanted to edit it in the drawer. We see there is an edit button, and the drawer is opened. What visual editor does, in this case, it fetches the form and editor schema from the new Magnolia content API. And this gives us all the information we need in order to render this form here, the drawer. And again, as I said, it is using the fields and using the design system components. When we change something here in the drawer, we see that the change is directly live in the page we have. That is thanks to the fact that the visual editor owns the data, and it updates the data itself and passes the new updated data to the SDK and sends to the React application. When we edit the field and the save is triggered, visual editor sends the patch request with the replace operation with the newly updated value. And again, we get the response of the updated page data. And when this happens and everything works correctly, we see there in the app bar that the page was saved correctly. The same saving works when we are working and editing inline, the field inline. That means that, again, when the autosave is triggered, the save is also and the visual editor sends the patch request. Now, if you are wondering whether delete component works exactly the same, then I'm here to tell you that yes, or very similarly. That means that when we click on the component that we want to delete, visual editor updates the data and then sends the patch request right now with the remove operation telling that this component should be removed. And again, we get the response from the content API that this was removed. So, to summarize what we have seen here and what the visual editor SDK will give us is, first of all, the editing experience. So, we will be able to inline edit either text field or rich text field. So, we will get also the rich text toolbars and we get also the schema-driven drawer, as you have seen. When we were adding a new component, we had there the component picker just for the available components that are available in the given area. And we are able to filter through them. We've seen the delete and if we make some change that we want to undo or redo, we have the undo and redo buttons. These changes are saved either when we click away from the field that we are editing or after a few seconds of inactivity. And we see the status update in the visual editor app bar. This communication is all handled by the SDK itself. So, you don't need to do any or handle any communication between your app and the visual editor. So, the only thing you have to do are those four steps and the SDK handles the communication for you. We can also look at how the undo and redo works a little bit more. So, when we do some changes, you can see that the undo and redo buttons become available. We are storing a few last changes that we are doing. We are storing them as a snapshot. So, that means that when we click on the undo, visual editor sends the patch request to the new content API using again the replace operation with the whole snapshot. And then the backend handles the replacement of the data. We are storing multiple snapshots that were before or after each snapshot is one operation that is triggered by the save. And the same things goes for the redo. So, with that, this was a sneak peek into the new visual editor, what we are building, what we are working on. And if you have any questions or feedback, I am happy to hear it also either now or later if you see me somewhere. Yeah. Anybody have any questions? While you're right up front, go ahead. Where is this hosted? So, where is this hosted? So, this is not the front end. It's the backend editor, right? Where is it hosted inside of Magnolia? So, more about like the wall. The wall setup will be provided by Mika that is going after my talk. Okay. Some more questions. Hey. Have you thought about a concept on how to make like components editable that will be like nested more deeply like a text area on the first level? So, if you use a design system or pre-existing UI components that you can somehow decorate them from outside to make the text editable? Not editable, but editable. You mean with the inline editing? Yeah, with the inline editing. Because from what I understood, you pass in some attributes to the components directly. But if you reuse existing components from a design system, for instance, they would probably not support the inline editing. Would it? We are... So, you are asking whether you would use the design system components in your components that you have on your page. Yes, exactly. If there could be some sort of descriptor or maybe type file or something that would tell, yeah, maybe more from outside, which fields will become editable. So, if the design system components will be available to be used in this way, then I think that we can look into how it could be done also in a way that it is inline editable. Okay. Okay. All right. Thanks for your question. Now the only one up here. Yeah, thank you for your talk. Looks pretty promising. This was all React now. And I guess that's also what enables this inline editing or this instant re-rendering. What about FreeMarker? Yeah, so we are going to support also FreeMarker. The... You mean for the reloading? Yeah, so we'll be just updating the components that need to be updated. But will it be hot reloading like we saw now or just click save or... No, it will be just updating what needs to be updated. Yes. Cool. Great. Great. More questions? Let me move back a little bit here. Thank you for the presentation. So, I have four questions. I hope it's okay. So, the versioning, it's still on publishing, right? Because you showed the redo undo, but it's not like versioning the page itself. No, the snapshots that we create that are for the undo redo, those are just locally. So, if you also reload the page, you lose them. So, it is just what the changes we are doing right now. Okay. So, now the harder question. Diff display. It will be supported with the new editor? Or, because now in SPA approach, we don't have the display in the pages app. Hope so. We are actively working on new features and adding them continuously. And we know that that is something also that you developers want and need. So, we will for sure keep that in mind. Okay. And personalization. I didn't saw anything there about variations on the new editor. It's not there yet. This is the sneak peek of the current state, the direction that we are going. So, we are actively working on this. And the work is ongoing. So, there will be the features, but not right now what I've seen. Okay. And the easiest question to the end will be a possibility to move the dialogue. Because it's like right now stuck on the right corner of the component. And if you edit something on the right side of the component, it will hide the component itself. It will be possible to position the dialogue when you open it on the screen itself of the visual editor. We haven't worked with that possibility, but we can think about that together with the design team. How could that work? Okay. More questions? This is great. Let's come to the back of the room here. Yes. Will there still be an action bar? And is it possible to define custom actions? There will be a possibility of custom actions. It is not there in what I've shown, but yes. Okay. Thank you. All right. Then, thank you so much, Martina, for your presentation. Very nice. Thank you. Thank you.