Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop

Today we are going to see how to create a Gemstack site or in general a website using Svelkit and Storyblock. Storyblock is a CMS, so is a tool where you can use for creating the content and for managing the content, but on the market, we have different kinds of CMS of content management system. We have traditional CMS and headless CMS, right.

In the past, we have monolithic CMS or traditional CMS and use a software application that allows the user or the content creator to build and manage website without having to code and so it was quite easy. But at the end, you can create the content and you can deliver the content or the website only for the website. Right. And you can start quickly to create a website with a traditional CMS, with a monolithic CMS.

But at the end, if you want to customize something, for example, in the frontend, you have to follow some best practice provided by the CMS, because the CMS provides the Udate template updating system. And so you have to follow their rules. Right. Some examples are, for example, WordPress, Drupal, Sikore, and so on. Right. And typically, if you want to manage the content and you want to deliver also the frontend, you have to deploy the whole system. Right. So even if you are changing a little bit in the CMS, you have to deploy all the CMS. Because, the frontend is as strictly related with the backend. The backend is used for managing the content.

We have on the market a different approach. Another approach is, for example, using a headless CMS. In this case, you have split two parts. One is the backend for just managing the content. And indeed the headless content management system is a software application that allows the user and team to manage the content, not to create the website. So, to manage the content and the process. For example, creating the content, reviewing the content, previewing the content, and deploy the content. So, you have multiple tools for managing the content. And then, on the other side, you can create your own frontend. And obviously, in this case, because the frontend is totally the couple with the content, you have to integrate it, right?

Typically, the headless CMS allow you to create the content and then expose this kind of content, the APIs. So, you, as a frontend developer, you have the freedom to choose your own framework, SvelteKit or Svelte or Next React or Nuxt and Vue. So, you have the freedom to choose your stack, frontend technology stack, and you have to integrate via API. So, what is provided by the headless CMS? Typically, it is an admin interface for managing the content, storing the content, and then providing the content via the API. In this case, today, we are going to create and structure the content with Storyblock, so for the part of the content editors. Then, Storyblock exposes the content delivery API. So, this is out of the box. So, today, as a frontend developer, we can focus on the part that we like and we love, so the frontend part. So, we can choose our frontend framework and today, obviously, Svelkit and we can build our frontend. When we need the frontend and the content, we can integrate the APIs provided by the Storyblock. We will use an SDK provided by Storyblock to integrate in an easy way the APIs. So, we will see what we need from the frontend perspective for integrating with Storyblock. And then we can create our applications in a SvelteKit way, right, and we can deploy also the applications somewhere on the cloud. For example, if we will have time, we are going to deploy on Netlify, and then we can allow the end-user to consume our applications that we are going to build.

I explained a little bit the past traditional CMS and monolithic CMS. Today, we are going to use headless CMS. But why headless is better than traditional CMS? Because you have more flexibility and freedom because you can choose your front-end stack Probably if someone of you come from WordPress, probably you know that you are stuck in with some technology stack and you have to use their templating system, right? So, probably as a front-end developer, you are not happy because you can't use your own tool. Another reason for using the Endless CMS is because of the content reusability, right? We will see how we can structure the content and reuse the component that blocks across the pages. Improved performance because the APIs are provided by a system, in the case of Storyblock, by CloudFront, so by a CDN. And then you can focus on optimizing the performance of the frontend, right? Scalability, because, at the end, the endpoints are managed by the CMS, because, typically, the CMS are a SaaS application, right? So it's deployed on the cloud, so you can scale it up in an easy way. Future-proofing, because sometimes in the past, if you used WordPress, and you want to update WordPress, probably you have to rebuild the website, mainly when you have to switch for the major release. In this case, you can focus mainly on the frontend. And security and maintenance, because, at the end, the interface between the end user and the backend system is limited by the APIs, right? So, in this case, you can consume the API. The APIs are mainly read-only, so you can have more security. And, typically, enterprise CMS like Storyblock are following some certification, some rules, OWASP rules. They are ISO 27001. So, what I'm trying to say is that they are enterprise level, so they are taking care about the security. Someone else checks the security, and so on, right? Good.

So, now we can start. So, a brief introduction, but now we can start. And we prepared some exercises. Probably, we can copy and paste the URL of this document that we already prepared, right Alba? Yes. Okay, then here, you can, if you click, Alba brought a URL in the chat, if you open the chat, and also you open the URL, you will access to some of our exercises. Yes. Please let us know if you have access, to double check with you. But I am pretty sure you will have access. Okay. I will publish it just in case. Just to guide you in this kind of exercise, let me explain a little bit. So now we are going to start to create a SvelteKit project. We can start for creating an empty SvelteKit project. So because, as far as understood, someone of you didn't use SvelteKit, so we can start creating Svelte, for example, a Svelte application. Do you agree? For installing a Svelte application, I think we can use npm. So now I'm going to create a name Total Empty SvelteKit application. As you can see, you can use npm, create Svelte, and then you can use the latest version. Then you can create MyApp. MyApp is the folder where we are going to create the application. If you want, you can use your terminal and then you can follow these kind of instruction to do the same on your local computer. If you have some doubt or you don't know, please raise your hands or write in the chat. Now I try to go slow, just to be sure that you can follow us. With this kind of command, we can create an empty application so we can answer to some question if we want a Svelte demo app, or a skeleton project, or a library project. In this case, skeleton project. Then you can decide to use JavaScript JSDoc, or TypeScript, or normal. For now, we want to see how to create a empty SvelteKit application so we can select JavaScript with JSDoc commands. Then we can add some nice tools. For example, Slink, Prettier, Playwright, and VTest. First two are about linking and formatting. Then we have also the opportunity to install some testing tool, for example, like Playwright and VTest. But for now, personally, typically I choose Prettier. You can choose more than one, but now we can choose only one. Then we can click Enter. Then we can enter into the new directory. The new directory, as you can see, we have some files created by the command, and then we can go via npm install. We are installing the packages.

Obviously, I'm using npm, you can use yarn or pmpm and so on. Then we can add the Git, but for now it's not important. Then we can run npm run dev, so the server. Running the server, we have the web server is running, so now, let me show you. This is the empty page of our SvelteKit application. It means that we are able to install SvelteKit. Why I want to create an empty application just to allow you to understand the structure of a typical empty SvelteTask application. In this case, we are not integrating the CMS, we are just installing the application. Probably you can see, put it, and then also the head. Probably you can see my editor, is correct. Then we can see that we have the directory with the source code, and then we have two files, app.d.ts and app.html. Then we have the routes directory mainly where we have the page. We will see a little bit later about the routing system, but for now, the page that we can see in the browser is in the pluspage.svelte. If we are going to change something here, and then we can switch, for example, to the browser. Too many screens. We can open it. Then as you can see, we have the Hello. It's very easy, but allow us to understand the structure of the empty application.

Now, what if we want to add the Storyblock integration? From the Storyblock side, let me start with using our tool named Create Demo. Create Demo is a tool provided by the Storyblock that allow you to create in the same way that we did before, an empty application with integration already in place with Storyblock. It means that we are going to launch a command. Now, we can see. Then we will see more or less the same structure, but with some integration with Storyblock. Storyblock is your CMS. Exactly, yes. Is the CMS that we are going to use. But today, we'll be mainly focused on the Svelki part. In this case, I can remove, for example, the empty application. Because we created an empty application just for example, and then we can use our created demo tool. To do that, we can do, we can launch more or less in the same way than before. We can use MPX and then we can create the demo. Storyblock create demo with the latter's version. Then we want to create a folder, MyDemo. Then we can define which framework we want to use, and today we are using Svelkit, so we are going to use Svelkit. Then we can define which kind of package manager we want to use, and optional thing, but just to allow you to understand, we are going to define the region, the AWS region that we can use for the CMS, not for the front end, for the CMS, for the part that you want to use and manage In this case, my expectation is to have a MyDemo folder. We does velgit application with some packages added and some instruction added for the integration with the Storyblock. More or less, similar, the same. We can execute the system, the tool asks us the access token because if you want to integrate your front-end with the Storyblock, you need to use an access token. For now, we can skip this part because we will use the full space. Then for this question, we can say, we will see later about the HTTPS and the tool create the demo. Take a while because under the hood, the command that takes a clone, better clone repository from GitHub, where we have already a Svelkit application, an empty Svelkit application with some packages for integrating Svelkit and Storyblock. Then we can jump into the directory and then execute npm install and then executing the server. Now the server is up and running. In this case, we have this kind of message because we have the configuration to serve the page via HTTPS even if we are in local, okay? It will be very important to serve the page via HTTPS because the configuration forстаrts using the 3G phone network. And the cuz we use the network via HTTPS. We will see why in a few minutes. So then we can accept the certificate because we are in local. So the Vita because under the hood we are using a Vita, create the certificate, self-assigned the certificate for running localhost. So it's okay because the machine is. And as you can see, we have already a very simple page. Okay, very simple page with some content. For example, this hello world, feature one, feature two and feature three. And a little spoiler, this kind of content come from Storyblock. So it means that we have already integration. We have already placed an integration. So let me do the same that I did before. So opening the editor and then see something about the structure, right? So in this case, we have more or less the same structure than before. But in this case, in the package.json, we have some dependency more. For example, this is the SDK that we provide for the integration with the Story Block. We have, for example, this plugin that allow us to start the local web server via HTTPS. And some other stuff, for example, because we are using a Tailwind CSS, but it's not mandatory. This is just an example, right. Then, we have in the routes directory, we have more files than before, but at the end, as you can see, we have page.swelt, where we have the Story Block component. Now, we're going to see every piece and commenting this. Just to let you know that via the Create Daemon application, you have the structure already in place, you have a minimal installation and you have some file already in place, but now we understand that we can start from Svelte kit application. We can add the integration with the Storyblock. Now with Alba, you can take the... we are going to create a project from scratch and with the configuration with Storyblock because we want to create the content in Storyblock and we want to create our Svelte kit application that uses and retrieves data from Storyblock. Exactly. Do you have some questions till now? No questions, okay. In general, if you have questions while we are explaining a little bit, you can write a message. Yeah, but now because we do a lot of magic using some commands, right? Now we can do the same thing like how you will be stepping step. So you can understand all the process, right? Exactly. So if you want, we can, you can share the screen Alba, you want or? Yeah, I can. Yeah, let's do that. So I can, okay, share the screen, the desktop too, that's the right one. Okay, perfect. Can you see properly the size of the screen is okay? Okay, nice. Well, yeah, the idea was I landed into the notion page that we have just to let you know that you have here all the resources we will be sharing and also the exercise that we will be making and also the versions that you need to have, for example, for node, because our SDK under the hood is using the fetch native API. So in order to support it, you need to use these kinds of versions or up, but as we are using SpellKit, and it's kind of modern, everyone will use this kind of node version. So I don't think it's a problem anymore. And here you have all the links to everything that we will explain. And also the boiler plate repositories we created for each of the exercises. You'll have a branch for each of the exercises. So in case you get lost, you can always on load the branch and get up to speed really fast. And here you have the repository that we will end up creating with all the exercise by branches, as I told you. And you can go one by one and check if you change something in your code or whatever. And the live version of the project we will be creating. That is just a basic stuff. I mean, nothing fancy, just an article inside a blog and yeah, some kind of text.

But yeah, the idea is that as you can see already Roberto explained us how the CMS works basically nowadays. And we saw how to create the first exercise that is basically, as you can see here, how to create the spellkit boilerplate from a storyblock. Like using just this command, that Roberto explained us, we create the boilerplate directly because we already have it open source. So you don't need to do anything else more than run the command. But if we want to create this boilerplate from scratch, we have the exercise 1 manual. That is this one over here. And here is where we explain step by step what we will do. But basically, now, let's go to the code and see what we can do.

So we open our terminal. As you can see, Roberto has everything light mode, and I'm the dark mode woman. So it's funny, we are both sides in the room. And what I will do now is just copy the command of the CreateSvelkit. I will call it Ultimate Tutorial Series, because it's the example that we have. And then just proceed with the CreateSvelkit and choose the same things that we chose before. So the Svelkit demo app is the one I want or not. Wait. The Skeleton project. Yeah, this has changed. OK. Yeah, in the past, I remember only two options. It's like, there's a third one. OK. And I will use, no, not TypedScript for now, because we are using the SDK directly. And then well, it doesn't matter. So let's say nothing. OK. So now that we have it, let's open it better in the file. So I will search in Desktop, Wordops. I have it over here. Here we have it. Perfect. And now let's just install the packages again. Perfect. And yeah. We can run again this server, but just to have it ready for the next steps. So yeah. Basically, in the beginning, we explained that strblock will use SSL. So what we need to do is install the package. So I would just install the plugin. Let me copy this command. OK. And let's open a new one. Perfect. And now that we have it, we need to go to the bit config. Let me first copy all the packages I need. OK. So over here, I will add the plugin basic SSL. That we will add to the plugins of a spelt. And then we will need to set up the server to true, the HTTP core. That's the page to true. So now we can have the HTTPS version of our localhost because the iframe of the Street Blocker requires it to work properly. Because, of course, as it's an iframe, it can have some leak of information and for that it's important. But just to let you know. So then what we will do now is create our space in a street block from scratch. So we can actually have something to connect to. So for that, we just need to go to the Street Block website, create an account for free if you don't have one. And then once you have it, you can log in and you will see the content repositories that you would be creating. Of course, maybe you don't have any right now. So you just need to add a new space and create a new space from scratch. So this one, let's call it the Svell, Keith, Warsaw sample, and let's select Europe in my case, but in your case, wherever you are from. And now that we have it, we can select our plan or continue with the trial. I will continue with the trial, but you can select the free plan that we have, the community plan. Since we will use every feature that is free, so you don't need anything from enterprise plans or things like that. You can just go for the free plan and do it. And here you have the actual command that Roberto just used, but we will just skip it because we want to create everything from scratch. So now what we will do is in order to see our application inside a Stray Block before connecting to the content itself. We can do it actually go into settings over the sidebar in the left side. Here we have the visual editor configuration and over here you can see a local, well preview environment that we are using inside the Stray Block that in our case we want to have the Svelkit one. So the Svelkit one, we have it over here, so I can just copy this command and go over here and paste. And now that we have it, if we go to our content, the sample content that we have when we create a space from scratch in a Stray Block is just a homepage with some content. And for now, what we can see is a broken link because first I need to, yeah approve the SSL without certificate, would want, always forgot about that. And now if we reload, we can see a photo for page that have sense because there is no homepage URL so we can add the real path to slash. This part is kind of not obvious for everyone. So the idea is that you need to have a slack to get the content from it, but you can do this in order to have the actual proper homepage of any URL website. So you need only the domain, isn't it? For that we are the real path but we always have a slack to get the content from it in the API. So now that I made it, I can see the actual welcome page of Svelte because it's reading the slash page of our webpage. And now it's time to go and install our packages to work with StrayBlock. So let's install... Well, first I will stop the modules otherwise we will be crazy because I'm installing things without stopping the server and that's weird. OK, so now we can add the StrayBlock Svelte SDK. And we will need to add TypeScript. That's maybe something that Roberto can explain us because I didn't know it and it seems useful inside the Svelte kit like we need it, but I don't know why it needs to be installed afterwards instead of the create interplay. So once we have it, we need to go to our layout in this search over here in routes, we need to create one actually. So we create a new file and this file shall be called plus layout.ts. So over here, we need to copy-paste the thing we have in our exercise. So basically, here, if we go to this section after we configure the space, we have here the code that is needed in the layout. So I will copy and I will explain you what we are doing here. So basically, we are getting the content from this Svelte SDK. We are getting the use history block API that is just an action, something that we call hooks in React and composables in Vue that is basically getting the API request to a story block in a different way. So we have provided you already the setup of the fetch.

So you just need to add this lag and the options like filters or something that you want to change from the API request. And then everything will come in handy and already provided by this action. That actually it's open-source, so you can change how it's being done in case you want to change anything and create your own action for that.

And then we have the story block init that is a way of initializing the story block SDK. So here you can provide the access token to your space that we will do now and then use the API plugin that we'll provide in this SDK. That, the API plugin is basically what is used inside this. That's it. So it's a way of initialization the fetch. Let's say so now.

Yeah. Sorry. Just to, okay, but probably we can ask to the people if they are trying to executing the command trying to following you and if they are stuck at. I see one of the person has an issue about still blank after reload. Yeah. Probably it's important to know that if you are using Brave or some kind of tool that is blocking the cookies and things like that, there is a property here for example, that you need to put the seals off. Otherwise, it is not allowing you to see anything. I can show you that. If I do that, you see blank page. So what you need to do is always to remove this. So right now I don't have the local host running so for that I can get the SSL check to be as for preview. Okay, probably because you have to open the preview page. Yeah, first you need to open the URL. So if I run the command again, the idea is that each time you open it, you need to go to the tab. Okay, try to open. And then you need to approve the SDBS in the advanced. Well actually for me it's okay because it's already working, but you saw the first time, yeah. Yeah, the first time you have to access, yeah. Yeah. Yeah, the brave thing was, had I buried the beginning. But Erik, is your case that you didn't open it first and then approve the advance? Because we don't have a certificate, so maybe it's because of that. I can get this. No answer? Erik? OK, I did it. Now, it just says this site can provide a secure connection. Localhost sent an invalid response. Error, SSL protocol error. OK, so did you install the plugin, right? The basic SSL plugin? Then you try to jump into the vt.config. OK, then you have to import the basic SSL plugin. Oh, we changed the part of me in between trying to get it working. OK. Yeah. OK, so that the port. Yeah, because vt, if you already open vt, when you restart again. Once, exactly. Oh. Add the next port available, right? So. Yeah, that's true. Maybe he was using the Create command that you saw before, and then creating again. One is locking up in the next port. And again, one is locked up. Yeah, that could be the problem. Yeah, one of the developer told us a nice thing. OK, interesting. Builder IO that we know uses an iframe, but doesn't seem to need the special HTTPS staff. So I think that we have to check what they are doing. But essentially, because our interface is provided by HTTPS. And at a certain point, we are including an iframe. So on resources, we need to provide these kind of resources via HTTPS. So it's the reason why we have to serve the local applications, Valkit applications via HTTPS. And this is the reason why we need a certificate. I'm wondering if a builder I or usually use a preview environment like the iframe with already hosted applications with their own SSO or not. Because the idea is that in this table, we provide SSO solutions for enterprise. So usually, if you want to have an environment that is really secure and your deployment of your frontend application soul be also secure because maybe contenators are from an agency or from an external party, you need to have a HTTPS on host in order to don't have this kind of problem. But they can do it with localhost. Yeah, that's the thing. Only with localhost. Yeah, we need to check the difference between localhost and preview environments because right now, we are treating the localhost environments as the same as the ones that are already deployed in a cloud. So yeah, maybe that's kind of a nightmare to work with HTTPS local, I would say. Yeah, once you are used to use HTTPS, now it's by default. I enable the HTTPS by default on all the project. Yeah, that's true. But it's always the case because we are devrels and we are working with the same product. But yeah, we need to check how to make- Also inside the project. Also inside project. Yeah. Anyway.

Okay. So, well, now that for everyone is working the HTTPS, always is the nightmare of the worst of them mode is always having problems with that. It's the most difficult part of the worst of this one. Yeah, for next it's a nightmare because it's not working properly because they need to have an environment variable for that. I don't know, so many weird things, but okay. So the idea is that now that it's working, let's try to connect the Stray Blocker SDK with our actual space. So let's go to settings in our space. Let's go here and in the sidebar in settings, again in access tokens, right now, we can see the preview token. This token is the one used in our local machine or in the preview environments that we push for the content editors. So in order to deliver content, for example for our production side, you will create a public one that only has the rights to read content and not any other rights. So for example, I will just create one for production for later but for now we will just use the developer one. That is the preview. And once I have it, I can copy here or maybe I can just do it on my environment file and then put process M whatever here but for now, let's do it manually and that's it. So, now if we go to our exercise right here, the next step as you can see will be to define the content that is already in a storyblock because until now, we were just getting the content initializing the SDK but we need to actually get some content. And for that, we will create under the roots folder our page CIS that will retrieve the data from the homepage that is the one we have already here.

This one. So, in order to get this one, we will just go and copy this code. Okay. So, let's go here. Let's create plus page. Oh, this is not a plus. Okay. Yes. And here, let's add this that basically is getting the parent that is over here. This is the parent, the layout. I learned that while doing the WordCert and then we await the parent and get, again, the function that we passed. And now is where we can call to the homepage that is in our space because we already connected with the access token. And we specify that we want the version draft. This version is the one that is saved, but not published. If you want to be on production, you will do something like this. Probably be a variable in your environment variables that when you push the code, it will be published instead of draft. But for now, as we are in development, we want draft. And we just save the history that is coming from the response that we will send later to the pages belt. And that's what we can see over here.

So now in the pages belt that is basically the template in view, I would say, the part that all our code is being rendered. We just want to copy this file so we can see what is happening. Okay. So we removed the HTML and we have HTML over here that is representing the history as you can see if the history exists, we represent the data first to see what is coming from the API. And then we will have the components represented. And here we can see we have a couple of functions that are coming.

Okay. So the idea is that first in the month book of this belt, what we want to do is to initially say the breach of the history of work. The breach of the history of work is not something that is getting content from a story book. It's connecting to the UI of history book. So when you are clicking on any blogs that you have in your page, or any content on the right side, you will have a live preview of what you are changing or happening. If you drag and drop blogs, you will see that in real time. So let's do that now. So if I save this, and I go to now, let's see, for me, run again. If I'm changing things and then everything is broken, I can see it actually. Okay. So if I go, now I have something broken. The error is kind of really weird. Let me see. No, no. Okay, what I save wrong. The type. Yeah. The serial block data. Okay. In this case, you have to set up correctly the preprocess, or svelte preprocess, or v preprocess you have to install. Because the way Svelte load the.svelte file, right? It needs a package for compiling.svelte, or the similar for post CSS files, right?

Okay. You have to install TypeScript. You already have TypeScript. Yes. And then you need the v preprocess, or svelte preprocess. Because we are using basic stuff, you can skip the installation of the package v preprocess because it's a dependency of a SvelteKit. So what you can do is jump into the svelte config. Ah, yeah. Here. And here we have to set up the preprocess. So, ah, let me take some instruction. So, we are in the svelte config. Yes, you have to import the v preprocess in this way, I'm going to copy and paste into the chat box. You have to set up, and then after you have to set up in the config, you have to use this. Oh, wait, I was copying in the wrong part. In this one, isn't it? In the svelte, yes. And then you have to use it, to use it, you have to set this kind of preprocess, v preprocess in the config. Yeah, at the same level of kit. At the same level of kit. Okay, perfect. Yes. So we need the prepercess, the v preprecess. Funny because in the beginning, I didn't need any, You didn't? Preprocessor for running the svelte kit. Are you sure? Yeah. Are you sure? I'm pretty sure. Yeah. I don't know why it happened, but okay. So now, yeah, we have an object-object. Because you are. The history, yeah. Yeah. Yeah. You know that there is a debug directive of svelte kit, you know? No, I didn't know it. Yeah. And the funny thing in Vue, if you have this, it shows you the entire object. Ah, no. Not the object response. Like, it's just, you know? No. No, you have a directive debug that at the end is a kind of console log that you can perform in the template. Yeah. Yeah. Okay. Yeah, so the idea is that now we are seeing object-object but the idea is to see the components that we have on our right side.

Okay. Yeah, so the idea is that now we are seeing object-object but the idea is to see the components that we have on our right side. So basically the teaser component with hello world and the grid with some different features. So in order to do that, what we need to do is create the components that we want to have in our storyblock space. So here these components are coming from the blog library of storyblock as any other hell the CMS.

You will have the definition of your structure. So basically you will have the components that you need in your page. And here in the right side, you will see this schema. In this case, a feature component is using our text field called name. And then we have the grid that is a field called columns that is expecting new components to be nested. So in this case, the blocks, columns, we let's say that we only want the feature to be in so we can actually a strict, the content that we want to nest in this case, and same with page. In the page, we will have body blocks that is expecting any components that we created inside this space feature grid and these are to be added in this field. And then in the teaser, we will have the headline.

So in order to represent these kinds of components, we need to create one component per each schema that we generated in a serial block. So let's do that. Let's go to the actual notion page, create a components folder under the source directory and copy paste all the spelled components that we have created. So let's go here. Let's create the components folder and let's start adding, for example, the picture spelt and then over here, let's copy the component. The components most of them will have the same structure. So basically you will have the story block editable that is part of the story block bridge. So with this, you will have a dash line that I will show you when it's working that you can click on it and open the right side with the schema of that specific component. So in order to get the content for this component that is coming from this over here. So here the story block component is just a component inside this bulk kit SDK that what it's doing is importing the components that are under the components folder. So as you can see here, we are retrieving the block and the block is the property we are sending is that symbol. So all the properties that are related to the feature component, for example, the name field that is a text will be delivered by this property block. So let's go now to our Notion page and copy paste the rest. This will be agreed. And then once we have agreed as well, we can just get the page. And then in the page, we are rendering multiple components instead of only a text. Then inside the teaser we have also only a text. So teaser.spout, and now we have all of them. And in order to have them, we will need to import them inside our layout because otherwise the StreetBlock SDK will not know about them. So if we go to the layout, we can import them. It depends on the framework. I will say you can have auto imported or not. The components depends on the case of your framework, but in this case, we need to add them over here. So we have them, and the StreetBlock SDK knows about these components we just created. So, now that we have it, we just need, I think that's it, yeah, remove the history. That's the thing I did. So basically we removed the history as example and leave this StreetBlock component to render our components we just created. So, let's go to the StreetBlock page, and now we can see, without any styling of course, because we don't have Tywin yet. We can see the teaser. If I click on it, as I told you, the StreetBlock editable action that is coming from this Svelte SDK is opening, on the right side, the schema of that component. And if I do the same with feature one, I will open the different nested levels of the component. And for example, if I just want to move this over this one, we can see in real time the change. So now the grid is on top, and then the teaser is at the bottom. And same if we create a new block. So if we create a new, let's say, another grid, and we create a couple of features, we can see, new feature, the changes real time on the left-hand side. So that's something that other LCMs are not doing right now because they prefer to have this kind of form view. If I just make it smaller, the preview, you can see only the form and it start adding content, but maybe as a content editor, you are not really sure about which content you are changing. If it's an article, it could be simple because you are just typing something for an article and the page of the article, you already know where you are placing things, isn't it? But if it's a landing page, like this one that could have so many different sections, it's nice to have an overview on what you are building. So then you can check what it is, how it looks on mobile and try to keep the frontend application as you want and not only the content as you want. So that's why is JavaScript is really cool about it. And then, what we will do now, I hope so, is to style it a bit because yeah, I don't like it this way. So let's add some type win. Now of course it's already added in our components as you may see. And what we just need to add type win to make it happen. So we have a way on Svelte kit, as I am seeing, to add the type win plugin. So we can just, yes, proceed. You can go, it's always asking me for rights. And then once we have it, let's just install again basically. Yeah, I don't know why. We can add it quicker, but it's okay. So now that it's installed, let's add the preprocessor as we made, with it actually. So let's add- I think it is enough with preprocessor, yeah. So is that- Ah, you think this one is already- Yes, yes. Oh, ooh. No, but it was already added. Okay. Okay, okay. I need to do it manually, I don't know why. But it's like, oh, it's here. Okay, don't touch anything, Alvar. Okay, perfect. Yes. But my suggestion is to, now, to remove with preprocess. Because it's- Oh, okay, that's what you meant before. And that's why I had it working on my local. Because I had the preprocessor of Tailwind. So it's already connecting with this one. Yes, because it's needed by Tailwind because Tailwind, for example, has some post CSS. Interesting, okay. And post CSS required a preprocess. So they are using the Svelte preprocess. The big one already. Okay, okay. But, okay. Then we need to talk after the words why the TypeScript type was complaining without the preprocess, but it's okay. No, because our component at the moment, the Svelte component is made via TypeScript. Okay? So when you are executing the code in the browser, so via client server, client side rendering, right.

So you need to, let me say compile the fly, the Svelte, the Storyblock component, right. Because it is made via TypeScript. So, yeah. Probably is a kind of improvement you can do in the future, removing the dependency on the TypeScript, right? Okay. Yeah. Have sense. Now, thank you for that. Yeah. Really nice. So then when you have a ThaiWin, you can see already the styles being applied. So now you have like a proper grid, let's say. And if we change the order of the features, we can see life, how it is changing. And what is the position. And if we save, we have this preview also for the old site. I'm not getting any highlighting of hover things in the visual editor and it doesn't refresh when I edit a property value.

Okay. So that part was configured in the Bridge. So let me show you. It's in the Layout, JavaScript, not the spelt. In this one, you saw half. No, not this one, sorry. The page. Okay. In Page spelt, here you have the Straight Block Bridge. So this will be getting the data from the history that we already provide in the page.js. Did you have this amount ready in your code base? Eric, are you still there? Probably is checking, but probably we can work through all the step. So start from the plus layout.js because now we are using layout and page, right? Layout, let me say, is a container of the page. So we can, for this example, I think that we can skip the layout, but now is a really structured container. Now is a really structured in this way. So we have layout.js in the load function. We are going to initializing the story block object via the StoryBlock unit, right? So in this case, we have the StoryBlock unit with the access token, with the list of components that we need and so on, right? And because we are initializing the StoryBlock unit here, we want to send the object, the StoryBlock API to the child. In this case is the page.js is the reason why in the page.js, if you switch in plus page.js, we are inheriting from the parent. So from the layout, the object, okay? Otherwise we have to initialize twice the StoryBlock unit. Another approach, and I tend to use this kind of approach, is to create a function, a common function for example in creating under the source directory. I create a lib directory. In the lib directory I create a JavaScript file where I have a function to initialize the StoryBlock unit. And in all the part of my code, in the layout, in the page, because at the end you can create a very complex website with multiple page.swelt. So in this case, I'm reusing this kind of function where I need to initialize the object. Yeah, but at the end, just to explain the parent, then jump back into the page.js just to complete the work through all the things that we did. And then we try to answer to the question. If you jump into the page.js, Alba, okay, you are already here, okay. Yes, you need everything by the Storyblock API. And then we are performing a GET via the cdnStoriesOM tool for retrieving the content of the OMStories. And then once we have this kind of information, we are returning this. Returning an object or a data from the load function expose this kind of information to the plus page.SWELT. So is there is a why if you're switching to the plus page.SWELT, you will never have data.stories. Try to reach to plus page.SWELT. Okay, in this case, as you can see, we are exporting data, and in the data we have our story because we are returning from the load function in the page.js, the object, right? So if there is a why, we have. And because we need the Storyboard Bridge, the Storyboard Bridge is set up in the on-mount function provided by the SWELT kit, right? So and that's all, that's all. Probably we need to use the user editable, right? You are muted, I think, Alba, or I can't hear you. Yeah, sure, sorry. No, that's what I'm going to say because I saw that Eric told us that he's using the storyboard boilerplate, the one with the create command. Okay. And for him, he's not working the Bridge. So maybe it's not related to the actual template, but we can check with him after this. Yes, he can start the screen and we can see what is the missing part because I'm pretty sure something is off, of course. But the idea is that apart from the Storyboard Bridge that is listening to events that are happening. So when you are typing, it will overwrite what you have. The idea is that you need the Storyboard editor in order to have this kind of click behavior that you click on a thing and it opens the right side. So you need to have the Storyboard editor in each of the components you want to have that behavior because it can happen that you have a component that you don't want to have the interactivity at all because it's something maybe full of static that you don't want to touch. But in the case you want to have this interaction in the client side, then you need to add it over here. So let's see if I can insert the screen. Maybe I can allow more people to start the screen at the same time here, multiple, okay. So just in case he wants us to check with him what is happening. And for Nuchaporn, he is getting 401. 401, so I guess you need to check Nucha in the layout if you have the access token for your space. So the one you have access right now and you want to check. So basically in settings over here in access tokens, you need to get the preview one. I already put access token there already too. What is the color of the token? And you are getting a 401. Wait, wait, wait. Are you using a space in Europe or in other region? Like US for example. Ah, I choose US, okay. So then I think it was at this level or I need to do API options. API options, okay so API options, I'm sorry about that. I know that something was off of course. So you need to do this in order to get that one. Yeah, sorry. Yeah, because this one is changing the API of a straight blog. So instead of being api.straightblog.com will be api slash US whatever because it's a specific endpoint, let's say. Okay, okay, get it. Let me know if it works after changing it. I guess for Eric. Eric, is sharing the screen or not? Because I don't know what I will see the screen if he shares. If you have some error in the console log. Just to understand if the story region is loaded and if we have some error or is keep at this part, I don't know. Yeah, tell us Eric, because that's all that happened with the setup. The initial steps were just fine. So if it's not working, we need to check what is happening. Let's see if they are here.

If they are, we can follow with the dynamics histories in custom components. I think we will have time for your site, Roberto, for showcasing how to deploy on a static site. Yeah. Because I want to see it too.

Okay. Okay, okay. You can use a project that you built, the Dasy one. Yes, yes, yes, yes, I will start from that. Yeah, yeah. But essentially, it's quite the same of this kind of project. Just to provide some hints, because sometimes, yeah, it's pretty confusing for generating in a static mode the website. For me, it is. Yeah, you need some special stuff from Svelket, yeah. And yeah, it is nice. So I think that we can start slowly doing a kind of recap of the thing that we did. Because probably, when you take a look for the first time, looks like a lot of things. But at the end, if you think, at the end, is something that is quite easy, and you are following, the best thing is that you are following the guideline come from the framework. Because at the end, we are using the layout, the page, the.js or.swelt. We are implementing the load function. We are implementing the amount, all things that come from the framework, right? So if you like the framework, probably you can see that, you are using the same approach, even if you are not integrating with the Storyblock. Maybe I have a question, I don't know if you know it, but I have a question about this setup of Svelte itself. So, why is Svelte is able to run, JavaScript in the script, but still does Svelte developers use the JS file. Why? Yeah. Good point. Jump into the page does Svelte, Okay. This is executed on the client side. Okay, if you jump into the page dot JS, this is the logic for loading external source, right? So in this case, the load function prepare some data for this Svelte and the page dot JS load function can be executed in server side and or in the client side. And we will see during the deploy that for example, you can convert this plus page dot JS into plus page dot server dot JS forcing the execution of the load function on the server side. Okay so it's similar to using AsyncData in Nuxt. Yeah, because I was confused about that in the beginning because for me for example, this variable here spoiler and then let. It's like, ah, why let is under? There it's like, don't get it. In the beginning was really confusing for me. But then I understand, okay. Everything that happens in the load thing you can get it from there. But yeah, for me it's kind of abstract. Okay. In general in a storybook in Nuxt, you grab the thing you want to do in a different environment like server. The same in Nuxt, you just get the static props for things that you wanna do in a static mode, but you define everything inside that and not get it and this could be server, this could be client. It depends on the filename. So yeah, it was confusing in the beginning, but it's okay to know that it's because of- And another way to think about this is in page.js you have the logic for loading the data and some other stuff. So more related on the data, preparing the data, preparing the object that you need for the page.weld even if sometimes the load can be executed on the client side. On the page.weld, yes, you have the script, but mainly focus on the interaction with the user. So you have the activity part, you have the amount for example, and some other stuff, mainly for specifically for managing the interaction with the user. That makes sense. Nice, nice to know. Thank you so much. Yeah. Okay, cool. So, Nutshapong was already here, I guess... Always here. Yeah, he's always here, and the others I expect so. So let's focus now in the next exercise that is basically right now, we only have one page that is called Home and we are getting the homepage via the URL directly from the Slack. So if we go to our page, this one here, okay, we can see that we are calling the slash homepage, but we want something more dynamic that once we create one page, we are ready rendering in our application and not create a new page from scratch with the actual Slack of that URL. So in order to do that, let's go to our exercise two. We open it, and we can see then the first step will be to create a static layout just to have some kind of links at the top, and we can click on them and go to a page that's pretty basic. So this is nothing related to Sherlock. This is something you will have in a normal application. So let's go to the components. Let's create the header Spall component. And over here we can see that we just have the blog link, the about, and the homepage. That is the slash. That's it. Nothing fancy. That's what we need. And now let's add the header inside the layout itself, but this time instead of layout.js, that is where we are doing all the API data stuff, we need only to get the component in this bulk layout. So let's go to the spell layout and include the header component. And in order to have that, we also have the main. Yeah. And in this log is where the page is represented as all the other frameworks. That's cool that they are just in the same convention. I like it. So now what we will do to create dynamic pages, of course is more related to a spell keys routine than a storybook. So basically we just need to have a folder that is called 3dots Slug that is expecting any URL with any combinations of a slash to have, call that a specific route that you are creating inside a Slug. So we will just create a folder or heroes. Hey, roots please. I don't know. Ah, no. And here we will add this Slug thingy and we will just move the pages inside the Slug. And of course it would not work because we need to change what is inside the page to get this trace via the parameters that we have in the actual route here. So let's copy this, go to paste, yes, and change our static call to be a dynamic one. And now we can see that params is coming from a spell itself. That is the routing system of a spell kit I guess, because a spell by default you need to install a route, isn't it? A route up, like in view for example. But the spell kit already has it and you just get the params and then you want what is inside this lag. And with that slag is what you will create the path to call a storybook. And if it's not a path and is a slash, the domain that you have in this case is localhost, you need to always at home if there is nothing extra because home is the initial page that you are calling from a storybook. And once you have the path combined, you can get it from the API request and similar as before. We just make this new part, but the other part is the same one. So now, let me see if there's any other stuff we need to do. Yeah, so basically now we want to have a title in our page is time we change from a page that is other one from the home. And for that we need to get the content of the history and add it to the head.

But this is just a fancy way of doing it. Of course, if we don't change anything, it's all work just fine. And maybe if I refresh the server first. From there, you can just create folders and not wait. What I did? Underscore. Is the syntax of the catch all? It's a lag. I think I copy pasted and the three dots are not three dots. Let me see now. Yeah, it was, you know, I copy the three dots from notion. And they were not three dots. That's funny. It's like, okay, well, put the three dots. Don't copy paste three dots, please. And once you have it, you will have these URLs available. But of course we need to create the pages in order to represent this data. So if I create the new history called About, we can see that the slack will be about. You need call back it again. I can see the same, but they know. Okay, so About is the slack that we are calling in the static header we created. So let's call it like that. And we choose the content-type page. That is the only one we have in the starter point in the story block. But you can create your own, like an article. And we will do it later. So basically we select a page. We just save it in the root folder of our space. And this will generate a 500 error, a page that probably I need to refresh, exactly. So the very first time we create a page, we need to have content. And the idea is, as I didn't save it, there was nothing in the API. So the JSON was empty. And of course, was retrieving nothing. But now that we have a teaser that is empty, we can see the live preview and I can just add a new teaser. And we can have, well, a new teaser for about page. And now we can see the about page itself. And now we can create another one for blog. So blog, his type page, and now the blog teaser blog. And now we can see. And now we have a dynamic way of generating the pages. Of course the 500 error, you can actually customize it to say, pages being built or something like that. So the content editors know that until they have created some content, will not have anything that page, but you are working on it basically. And now that we have our pages, what we will do now is of course, adding this new block I told you. So copy in the pages bulk, over here, the head that is basically going to the head of the HTML itself. And now I think we will be able to see if we go to the preview, of course, we can see blog on the top itself, about, about, and this content is coming from storyblocks too. Yeah, using the Svelte is a convenient way to set up all the data, for example, so for the CEO and for all that stuff, setting the title, the Open Graph, meta tag and so on, yeah. Yeah, really cool. Love it. And yeah, so now, what we will do is create, well, let's edit one of the blocks, the next table blocks that we have already in our space. So you can see how is the process of actually adding more data to your database created in the server block. So if we go to the block library, that is this icon over here or this icon over here or in the sidebar, you also have the block library. So there is a couple of ways of entering this place. And once you have opened it, you can open the feature one and let's add new fields to this schema. Right now we only have name, isn't it? Let's add an image of type asset and the asset could be a PDF, MP3, you know, whatever kind of file. But in this case, we want only images because we want to add an image, that's it. So once we have it, we will have access to our digital asset manager that is actually already in a server so you don't need to set up anything. And then once you have the image, let's see if we want another description. So let's add a description of type text area. So we have a longer text. And now, if we go to our homepage, in the feature we created before, we can see that we have more content to be added. And of course, if we add some content, let's add an image to our digital asset manager, let's add this one for example. You can customize the name of the title, for example, let's say it's logo, and then render it in your frontend. But for now, you will not see any changes over here because you, in your frontend, didn't create the image at all. So you just define the schema inside the storyblock to make it happen in the left side. So in your frontend, we need to actually override the component that we have. And for that, you can see over here, the code for the feature. So let's copy it and go to our feature again, select all and override. So now instead of having only the block name, that was the part that we had before, we now have the image that is being called by the file name. So basically we have some different JSON schema that I will show, you know, and the alt that I provide. And here we are representing the description that is the text area we just added. So if I go to the homepage and I open drop JSON, of course, you can see now the image, but if I open the drop JSON, we can see how it looks to response from the API. So basically, initially we were getting the columns and in each of that columns, we have a feature. This is the component feature, you see this one. So this content before was only name, but now we have an image with a lot of data that is coming from the digital assets manager of Stray Blocks. So basically we have the file name, the copyright, everything that I showed you that you can edit and the alt text for sure. So here's where we get the content from the image and the name and I don't know why, ah, yeah, of course. If you didn't add one of these fields, you will not see it in the response. So for now, if we add a description, now we have the description here. And if I save and I go again, I will see the description coming from the API. A really nice improvement because in the past we were just sending everything empty. So it's really nice to see it live. And now that we have our new description in our images, of course, everything we made, as you already saw, could be live edited. So if I add another, a new image, now we can actually see this happening. So now if I click, I can see the image being loaded and have the CMS, and I can see everything like, that's how you can work with new fields. Basically first creating the schema and then defining it in your code. And once you're done with that, of course we have something that we did in app that I think is really important. Usually if you use the Digital Asset Manager that Estrebo provides you, you have the original URL in your response, this one, but this one is not optimized. This one is the one that the containers upload. So you always need to optimize the themes instead of using a standard service like Cloudinary or any other stuff, we have our own image service. You just need to add to the URL as slash MS/. So I will show you how you can do that. So basically in the file name here, what you can do is just instead of having directly this file name, you can just do literal strings and let me here, close it, and then add a slash MS/.

And maybe the version of the image you want to crop. For example, imagine that you want a square or a rectangle, you can do this. And this will make the changes on the fly for you. You don't need to install anything, do anything with history log, you just need to add a slash MS/. And it will be automatically cropped for you. So that's how you can work with the image service. But of course, in this case, we want a square. So I will just leave it for that's okay. But that's how you can customize your images. You can also add filters like blur or any other stuff. You have the link here in the notion page. So if you go, you can see all the options that you have. If you have faces in your image, you can actually center that image by the face. So we have really cool stuff there. That of course is needed, yeah. You can also add only the slash m slash, right? Exactly, so if you don't want to crop the image, you just need to add slash m slash. And what it does is automatically deliver a WebP image if the browser support this. Otherwise, we'll deliver the original one. So the idea is nowadays all the browsers are supporting WebP. So you will have already a proper image for performance and with quality 80. So if you wanna have the 100% quality because you want to have a huge image, let's say, you need to add the filter quality to 10 100%. That's what I made in my website when I realized. Yeah, yeah. And yes, our suggestion is to use always slash m slash because it saves a lot of bytes in terms of size of the image. Probably if you want, you can take a look about opening the image in the group of the image in the browser and inspect in the- For sure, let's do that. Just to play with the image, probably because the image is simple, probably we are going to save a few bytes. But imagine if you have a kind of picture or photos. Yeah, the difference is huge, right? So in this case- Yeah let me make it. So we can see the kilobytes. Actually it's a really small image. If we add a slash and a slash, we can see that is 6.9. But at the end, in percent is a good improvement. Think about, you have our photos, 10 megabytes. Yes, you can start to save a lot of bytes. And without the styling, nothing, knowing any technology, you just need to add a slash and a slash to the images. So that's my blogging for me. Another nice tip is, for example, if you want to resize this kind of image, for example to 64, but you don't want to think about the ratio, you can write 64 and then the zero, right? Zero, yes. And with zero, it respect the aspect ratio. Yeah, I think the other one maybe is better for that because I think it's not a square. Let me see. Yeah. No, it's a square too. A lot of them are squares, I can't create them. Yeah, in general when you have them dubbed, and you don't know, you can do these kind of techniques for resizing the images, yeah. Yeah, I mean this one is not a square. And probably is bigger. Yeah, but if we do these, we can do a slash and a slash, and then 64, well not 64, but 200 or zero, and then we can see that is not cropped, but resized. Yeah, that's really important. And same the opposite way, so we can have a vertical one. Yes. So that's how you can change the height of the width and just resize the image. Yes, we have the documentation about the image service. You already shared, right? Yeah, it's in the actual Notion page. Yeah, because now we don't want to cover this, but you can change also the colors, and you can apply some other nice effect to the image on the fly. And that's really cool.

Okay. So now, yeah, let's move this. What it will do is create a new component from scratch. So instead of changing the feature one that we change it here, let's create a new one from scratch so you see the process of creating a block. So in this case, the block will be unstable block because we'll be reused in other pages like we saw with the teaser and with the grid. So basically, send you out a new block. You can add this one that we will create right now. So let's call it Hero, and add it to our bowl library.

Now, we have an empty schema and we need to start defining the fields. I have defined it here for you so you don't need to think about the naming. You can just get all the naming from here. So Hell line for text, we want a sub-Hell-line that is also text but could be TextArea, that doesn't matter. That's up to you. Then background-image that will be again a file asset and this asset will be image again. And then last but not least, let's create a layout that will be a dropdown with two key-value pairs. So a single option we call the dropdowns in a store blocker, or single option or multi-option. So here, if you add the single option, you have the possibility to define key-value pairs that will appear in a selector and you can select one of them or you can also create a data source with these key-value pairs and reuse these key-value pairs between components, that's up to you. And then you can also link to other histories and see in the dropdown the list of pages that you created in a specific folder for example, but we will see that later. For now, let's create the self source and let's create some options over here. So the first one will be, let me remember, Constrain, what a name. Constrain and then the other one will be Full Width because we want to have a hero that provides you maybe with a container or maybe without and just full page. So now that we have the options, this is the one readable, the key, the part that the content editor will see and the value is the one that is sent via the API. So it's the one you will use in your code. But this one is just for making it look nicer to the content editor. And now that we have it, of course we can select which one will be by default. So it's automatically selected. You need to always copy paste the value, not the key in order to have this default value. And then we can save it. And now we have our scheme already to add it to our page and just render in over front end these fields. So let's see the order I put in there here. So basically... Ah, okay, I prefer to create it first. Yeah, that was my preference the other day. Now I don't know, but yeah. If we add the hero, we don't see any preview because we don't have a hero yet in our front end. But let's say, new hero without preview. And then let's add this image for example, and that's it. So let's save it. And now that we have the content, let's just create a new heroStyle component inside the components folder. So let's go, and let's say, new file heroes-style, and let's add this content. And basically here we are, again, getting the blog as always, there is no difference. Also, adding the storybook editable, the same. The only thing we are doing differently right now is that we want to extract the key value pair that we created in order to add some classes to our component. So in this case, as this is an operation we can do better in JavaScript, we do it in the script instead of doing it here. But you can also copy paste this and do it everything in the HTML, that's up to you. So now that we have that, we can see that we are representing the headline, the sub-headline, the image again, and again, without a slash M. So that's grown, let's improve it. Let's add the slash M slash. So we can have proper resize image, okay? So now that we have it, if we go back to our application and we refresh our frontend, Why is not, wait. Oh yeah, what did I did? You did the other hero component, important. Yeah, when you create one, it's not automatically important. You need to go to the layout.js and then add the new one inside your file important, yeah. I told you in other frameworks is automatically important. So I'm getting lazy Roberto. But in this case, you can optimize the loading of the component depending on the page you are, right. So because typically if you have different section of the website and you are going to implement different.SVELT file and you want to load some specific component for some section or not. You can list, but yeah, I think that we can add in our SVELT SDK because we provide these kind of a kind of option where the developer can say, okay, I want auto-loading and this is the folder or I want to list all the components that you want because in the past we are that also our functionalities to instead of provide a list of components as an object as you can see, we provide the way to provide a function to load the components at the end, yeah. We can improve it, yeah. No, but nice, yeah. So then if you add it, then a spelled nos above it and if we go to our homepage, we can see the hero over here. So let's add it at the top, this is a bright image so we can see it and then if we want to have the layout full width, we can also click on it and there is not so much change because my screen is so small but in general it will be like this. Yeah, and now that we have the hero, of course at the end I was saying that you need to add it to the layout that I forgot completely. So yeah, for that we have this Notion Nodes so you can take a look and yeah, build your own.

Okay, yeah, okay, so I put a note here so you can know about something you can do because for now, as you will see, we were doing everything manually but usually if you are working on a real project, you will not want to have a developer creating things manually. You want to have a scripts that runs command lines that creates these blocks. We have that, we have the straight blocks CLI that you can create, well let me push, that you can create your JSON schemas, of course with the structure of a straight block that for example in the very beginning you pull the components of the space we are creating them, these ones. You can get the structure of them and then modify that JSON files and then push the components to any spaces you create inside the straight block. That's how you can do it manually, programmatically. So what you can do is create a repository maybe in GitHub and create all the files for the components that you want to have in your space and then come online, it will be automatically generated. If you have a GitHub Action for example, running this command after you change the schemas. So that's how you will work in a real project and not making everything manually because of course if you want to change any of these components and they already have content you will need to be great that fields to the new ones. And for that the CLI has different commands to do that. For example, we have the migrations commands. Let me see where they here. So you can generate migrations each time you change the components and you can run the migrations to change the content that was saved in that components or that fields specifically. So for that is important that you make everything programmatically when you are building a huge project but for a personal side project or something you are creating just for fun, you can do it manually and it will work fine. There is no headache, it's okay, it's cool. I create mine, my website manually but for migrating stuff I always do it programmatically because it's easier of course. But yeah, that's the options we have. Did you have the exercise working? Is working everything for your site or something got broken in the meantime? Working quite well, nice. Nice to hear that, so happy to hear that.

Okay, so now that we have created a few components I hope that you are familiar with the UI and how it works. The generating of new components because now the plan is to create a blog with articles. So basically a section on our site that will have a new kind of page. Right now we have the homepage that is using the page template and the page template is just blocks. So it's just dynamic nestable components that we created in our space. So it's kind of a landing page that you can start adding a lot of components. But usually an article has a strict schema. So you have an image, a headline, maybe CEO title, OG image, things like that but you don't have a lot of blocks moving around. So for that, we will create a blog to see how a new template can be created in a storyblock. And we call it content type. I think Contentful also does that. Content type is more standard right now in the headless ecosystem I would say. Yes. But also in other system. In general, in the content management system you can create a different content type that define the structure of the page.

Before to proceed, I want to jump back into the hero component to highlight some nice stuff because now in the storyblocks side on the hero that we already created. So as you can see, we have multiple fields, right? Headline, sub-headline, background image and the first three, headline, sub-headline and background image are field that is useful for showing something to the end-user. Some other fields, for example, the layout, change the layout or in general the aspect for the rendering. So what I'm trying to say is that when you are going to decide in which way you want to create a structure of every component, you can define the field that you want to show, headlines, subheadline, but you can add also some other nice fields for allowing the content editor to change the aspect, to changing the layout or to changing the theme. For example, you can add, for example, background color, right? And then in the same way, you are managing the layout in the Svelte code. So because at the end, if you remember, we have a condition that is based if the layout is constrained, then apply this kind of CSS style, okay? So in the same way, you can do for multiple things. So is nice, I think, these kind of organization, because you can allow the content editor to change also the aspect. Yeah, and then you have, you can define the freedom, right? So you can have multiple fields to control the design, yeah.

Exactly and one thing that is important that Roberto mentioned is usually you will have fields that are not related to content that are related to something else like CEO or design, for example. So in this case, we have the tabs, the manage tabs. What they made is just organize the fields in different tabs for the content editor but in the API request, they are in the same route. So you don't have next table API. You just have these in the UI. So if I create a design tab and I move any fields over this tab, now if we go to the keyword itself, we will see different tabs over here and we can manage everything that is related to design here or the styles. And then in the general tab, we can have the main things that the content editor should work on. So that's how you can also structure your components to don't get a long list that they need to scroll over and get lost while they are doing it. You can always have it this way. I think that is a really nice, cool thing that you will use Embracer if you use a Stardock. Okay, so yeah. Any questions or something you wanna clarify that you didn't get or everything is fine? Okay, let's follow with the blog then. Nice. So in this exercise, as always you will have a branch where you have repository that you can check with the changes that were made in the commits. You can see actually the steps I follow that are most of them the same as we have in the Notion page basically. And the first thing to define the blog, of course, is where we want to save that blog. In this case will be a blog folder inside the space of story block. And then we will need to create a blog history that is the one we already created but inside the folder this time. So you can move it instead of deleting it. And then in entry configuration we will select the blog history as the root of the folder because it's the slash of the folder, let's say. But let's do that so it's better to see it live. So if I delete the blog and I generate a new folder, this folder can be called blog again. And then we can select default content type but let's do it later. For now let's just add the folder blog. And inside this folder let's create the new page, in this case will be blog again. And we will select the finest root of the folder as I told you. If you do that, you will see that it's the slash of the blog folder in a specific. And now let's select the content type that we have because we don't have any other, the page, and just add a hero. And let's say blog page. And yeah, of course we need to add any much. And now we have blog page. So now what we can do is create some articles, isn't it? But wait, we don't have any page for articles. We only have the page template, the content type. So let's create a new content type. And that's the next exercise of this notion page. Basically, let's create a content type that has all these different fields and the different types that we can see here. So let's go to the new block as we did before, but this time with content type instead of nested block. Let's define it as article. So we have our front end aligned with that. And now let's create all these different fields that we have here. So we will have a title, a subtitle, content this time instead of text area or text will be restressed with a lot of features already implemented by this tree block. Restressed field. And then the image with the asset type images again. And finally the teaser, that is just a text area that we will define in order to have like a cert for when we are showcasing the articles in another page. In this case, I will say that the teaser go first. So I will just move it around and you can play around with the fields in the order that you want. That's how the content editors will look at them. And now that we have it, now we will be able to create new histories, new entries, new pages with this content type. So now if I go here, I can create a new history and now I can select another content type. So what we will do is let's go to the content tab. Yeah, wait, it's a small. Okay, so in the content tab, we can select the folder and then in Settings, we can define that we want always when we create a new history to select a specific content type. In this case, let's say article. So I don't need to select article every time I want to select a different template inside the folder. So now if we save it and I create a new history, you will see by default article. Of course you can change it, it's not restrictive but in the beginning you don't need to think about it. So that's what you can do to optimize the way that content editors are creating articles. Article page one, let's create it. And this will generate of course a view without anything because we don't have anything to represent it. So if I add a new title, so new article, we will not see any preview because we don't have a component inside our SVELT kit application. So this is where the article SVELT will be created in our components folder. So let's do that, let's go to the components folder, let's add an article and we have here basically two different things I need to explain you. They deal is that right now we are getting a field type for the block as always, but this time we have a specific field type that is called risk test that is safe in the content. Basically this risk test needs to have a render. And instead of you representing the HTML via the JSON we provide you, we provide you also with an action, a method that you can add from this SVELTkit SDK and then save it in your own reactive variable. And that way you can get the HTML content render from the JSON we provide you. I will show you the JSON response.

So you get all the stuff that we are making under the hood, so you don't need to do it yourself. And then you can represent it via HTML and don't think that much about it. But there is a lot behind that, I will say. And we are creating a better one right now because right now we have one that is allowing you to render basic stuff, but we want to have also render of different blocks inside the RISC test. But this is for another day I would say.

So what I will do now, before I forgot, is go to layout, yes, and add our component. Otherwise we will not see it. Okay, so if I add the article, I can add the article here and then the article article, and then just add the small a at the beginning. Okay, so now that we have the article, let's see if we are missing something. Of course, it's already said that we need to go to layout.js in order to add it, and now if we go back, of course, we need to save because we don't have any content, and now we can start adding all content in our images and so on. So let's say new article, hello CMS. Is working nicely, yoo-hoo. And you can start seeing the content being added. And as I told you, we have the rich test content here. So if we add new hero, headline, whatever, we can add new text. We can add to this new hero headline, for example, a headline of H2, so we will have a different response. I don't know why it's not being saved. Okay. Why is not being rendered? Right, let's see if you have some error because- I can try, oh no. Wait, wait, wait, but no, no, the build is being rendered, so if I will- Did you install the Tailwind Pros? Yeah. Let me see. No. Yeah. But did you install the package? No, no, no, okay, get it. Yeah. So the idea is that the render is rendering the HTML tags, but not the style of them. Good one. Yeah, because under the hood, this is translated into H1, H2, H3, right? But at this point, because we are using Tailwind CSS and we are using this kind of typography element, so we have to install the Tailwind typography if we want- To render it properly. Yeah, to render it properly, without defining anything in our CSS, unless you want to define the style, your own style, but because we are lazy today, so we can install the Tailwind typography. Typography, yeah, I think probably is part of the exercise. Yeah. No, didn't add it, okay. Good one, I can add it right now. So the idea is that here, as you can see, the content is being delivered by the API as type doc, and this type doc has different sections. So basically it's time you create a new type of text inside the research area, like I made with the heading. You will have a different response with the specific text that is inside this type of heading, but you don't need to worry about that if you are just in the action that is rendering everything as HTML. So let's do a console log, sorry about that, if you like the book, but that's how I do it. Right now. So if I add a console log of this resolve re-test, we will see the actual response of the action. So let's open, maybe not here, maybe open it in the preview directly. Yeah, better. So if I go to the console we have on the file, wait, why is not being read? Because you have to change something, it's better that you can see in the... Okay here, yeah, the new debug, not console log, just representing the variable. That's the new debug. So here you can see that everything that we created in the API as DOC, so the heading, the paragraph, and the bold are being actually generated by their action. So you don't need to do anything more than call into the html, at, and that's it. This will render the rich tests field type basically. Basically. And, yeah. I think what I want to do now is then let's add the configuration for the typography. Let me add the typography. Login.tailing. So it looks fancier than it looks right now, please. Okay, let me add it. Okay, they say that in dev dependencies. And then we need to add it in our plugins. Plugins, plugins. Here. Exactly. And just stop? Yeah. Yeah, that's all. Yeah. And then, From there, and let's see if it looks fancier than before. Yeah. Now we have the hero as a hero. Because I was expecting like, where's my headline? Please. Okay. So now BROWSE is doing the work. And if I add a list. You have a list. See you have a list, but properly is with a fancy gray color. So you can change with BROWSE the variables of the text and things like that. But it's really cool. Yeah, BROWSE is making everything so much fancier. So, yeah, nice. And yeah, what we can do now is, these articles that we have, of course we have created only one, but we can create a couple of them. So we can showcase them in the other pages. So they users when enters into the homepage, they can just go to a new article from there instead of just being on the article itself. So, let's do that. Let's create a new history. No, I want to save. Okay. Let's create a new history called article for JS Nation. This A here. Okay. And we can create this one and then add another image and some text again and a piece with some extra content, proper text with bold, and now let's just duplicate this one and change the name. So we have already something and that's it. Okay. So now that we have the different articles, we can represent them inside our pages. In order to do that, we will need first a card that this being served between all the views that we will have.

So basically a component that will live in our project, but will not have any block inside the story block. We'll be just a way of rendering over article's data in a small way, like a teaser, a tick toll, and an image, but not the entire article. So in order to do that, let's create a component called article card in the components folder with a content that is already provided in the Notion page. So article card.spelt.spelt And then here we can see that we will expect an article and its look and not a block as we are always suspecting because it's not a story block component. It's just a component we use in our frontend. So that's why we have different variables in this case. And over here, we are also using the DATABALL staff because we can open the article if we want since we have which article we are talking about it will open the content from the article itself instead of opening a block inside the page you are at that moment. And here you can see that this slide is just being passed by the parent. So for now we can skip it. And then here we are representing the image always using the image service and the title and the teaser only instead of using also the content the risk test or the subtitle. For example, they are not here because there's no need for an overview of the articles. And now that we have the articles there of course, you will say, hey, you didn't add it to the layout. No, it's not needed because it's not working with a Storyblock directly. It's something that we just use to represent the content. We don't need to add it in the layout.

So now what I want to do is create an overview of all the articles I have on the blog history. So basically, when you go to the blog slash you expect to see the list of articles, isn't it? But right now we are not seeing them because there is no API code and there is no blog containing them. So what we can do is two things. You can create a page inside the roots directly of your project and define one for the blog itself. But if you want to have a dynamic slug that we have here, it's better to create a component that will not contain anything but in your code will get the post from there. So let's do that. Let's create a new blog that is an stable blog called all articles. And in all articles, we will just add maybe a headline or something like that. Let's see how I call it no, title. So let's call it title. And the idea is that right now, this blog page will have these all articles blog here, and we will say all articles in the title. And here we will have a title. In the title. But what we will do now is render this title, but also call to all the articles in the blog folder that are not the blog page. So in order to do that, let's create again a new component, this time call all articles is valid, and copy all the content that we have here. So I can explain you really quick. So, all articles.isValid. So here, we are getting the article card that we just created to represent the articles in a small way. The among hook that we will use in order to get the histories from it. And then the story blog API that we will call to make the request basically. So here you can see that instead of using a specific slug that we were doing in the pages. What we are doing is getting all the histories from story blog. Everything that we have in the content out and saying only the ones that started with blog. So the ones that are inside the folder blog, these ones are the ones I want. And don't give me the start page. Don't give me the block page, give me only the articles. That's what we are telling here. And of course version draft as always. And here we are retrieving the articles basically from the data histories. And the articles we will just make a for loop and send it to the article card so we can have the representation of that content. That's basically what we are doing here. So in order to have the all articles as always, let's go to layout and add the all articles here. All articles, nice. And over here... Let's add here, okay. My mouse is getting out of battery, so we need quotes. Okay, now that we have the component, now we can actually use it. So if I go, oi, if I go back to MySpace, I can see now the articles with the start that we created and the images and the title, but not the whole content as we can see if we go to them. So right now here, we can see that we have this Subheadline that is not being rendered by the article card and this reach area. So here you have the list of articles, but only with the content that you want it to represent. Anything you want to add? Just nice? No, I was checking if there is some questions. If you have some questions, you can write in the channel, in the chat or raise your hands. Yeah, essentially what we did is to create a kind of structure for the blog, right? So we have two different kinds of pages. The most flexible one is the homepage where you have the nestable components. So you can nest all the components that you want. And another one is the article one, where you have well-defined the structure with the headline and all this stuff, right? So you can have a multiple approach providing the maximum level of flexibility to the content creator, creating a blog, and then they can do everything. Or defining a structure, like in this example, the article where we have an image, a title, a subtitle. You can do also a mixed approach. For example, jump back into the home page, for example, in the structure of the page. It's just an example. So in the body, if you are going to edit the body, this structure, yes, exactly here. As you can see, because you are defining the field type of blocks, you can nest all the components that you want. But if you want to restrict the selection of the component, because think about you have thousands and thousands of components in your project, you can go in the option, the last one, allow only specific component to be inserted, right? So in this case, you can define the list of components that you can insert. So it's a mixed approach, right? Because you can provide the maximum level of freedom to the content creator, allowing block, and then that's all. Or providing like the article, providing a well-defined structure, or you can define a block, but you can restrict the selection on some specific component that you want, right? So it depends on the configuration that you want. And then you can also mix because you can have headline, sub-headline, and then you can have a third field with blocks. So what I'm trying to say is that the level of the freedom, let me say all the flexibility is better, you can decide it, right, when you are going to design and structure the components, if they are nestable components or if they are content type. Exactly. Yeah, the idea is that you have the freedom to create whatever you want. But of course you also have the tools to make the restrictive for the content editors so they don't mess up with everything they are creating. Because for now as I made it, I just blocked the ones we want to have in the page, but imagine that we have also the feature. The feature was something that was inside the grid. So now if I add one here, it will be a little bit off because it doesn't have the grid containing it. So you can see that it's full-size and it's not the intended feature of that specific block. So that's why you can restrict which kind of blocks you want to load every time. So yeah, I think it's really important to have that in place. Yeah yeah because probably you want to sit down, keep it easy and then follow some instruction with a slower pace but yeah, at the end you have the same instruction, yeah. Exactly. But as you can see, we follow a different step.

So probably in the front-end, you will have the hero.svelte component in the components directory, and the field that you can use is the field that are listed here. So probably you can access to the headline, to the background image. And yes, think about why this kind of approach. Think about their usability. Not only their usability into this kind of project, but you can reuse, via for example, the CLI that Alba showed before, you can extract the structure of the component via the CLI, and then reuse this structure on the next project. Probably, for example, if you are a freelancer and you are going to create multiple website or multiple project for your customers, or you are working on an agency and you need to build more than one project for more than one customer, probably at the end, you can create your basket case of components in terms of components for Storyblock and components for Svelte. And then you can reuse in the new project. So probably you can create some components at the very beginning, but then you can reuse them. Exactly. Yeah. Yeah, I think it's quite a nice. Do you have in general some questions or... Anyway, if you want to take your time to follow all the process, just to say that we have the ultimate tutorial for Svelte in our website, that more or less we are explaining all the things that Alba is showing us, right? So we have the ultimate tutorial, we have multiple part. The first part is focusing on integrating with the story block and then render the story of stories in SvelteKit and so on. So if you probably now you are following Alba for a timing reason, probably we are going too much fast for a new user that the first time want to integrate story block in SvelteKit but yes, at the end I think that we try to provide information about the feasibility about this kind of integration and then you can take your time following this kind of a nice tutorial, right? Exactly. Yeah and of course in the notion page you have the link in the resources. I think it's here, no, this one. Yeah, so you have all the sources to get started with story block and SvelteKit. Yeah yeah because probably you want to sit down, keep it easy and then follow some instruction with a slower pace but yeah, at the end you have the same instruction, yeah. Exactly. But as you can see, we follow a different step. We started with integration with story block at the very beginning. We set up the HTTPS. Yeah, for Italian and for Spanish it's really difficult. Once you set up all the things you can start to creating the component and following the Svelkit guideline, you can create the connection in the load function implementing the on mount method and so on, right? So at the end it's quite, once you understand the logic probably it's quite easy. Did you cover all the things on your side? There was only one thing reminded but I don't think is really important. Well, maybe I can showcase really quickly. The idea is that imagine that you instead of list all the articles in the blog page here, instead of listing all the articles here, maybe you want to have like an article feature in your homepage, like go here, it's the best article that you will ever read or something like that. You can actually do it by linking internal content in a storyblock. So I think I will showcase just this case because it's important to know about the multi option field and the listing option, but then I will give you the floor to showcase anything that you want to showcase. Okay. So the idea is right now, what we want to do is create a new component that will render the articles that we select and not all of them. So in order to do that, we will create the popular articles block components. So let's go to the block library again. Let's create a new block, let's add the popular articles name in the Nextable block, and then over here, we will create the new field types. So the first one is headline and it's type text. So nothing to worry about, but now we have to select the articles that will be a multi-option field. So the multi-option field is similar to the single option, but you can select more than one. That's the only difference. And in the multi-options field, you have the possibility, as I already told you, to create key value pairs, to have data sources internally, or to get histories from. So we will select histories. And we want all the articles that are inside the blog folder to be rendered in that selector, so we can select the ones we want. And in this case, we want to restrict the content to articles, so we skip the blog page. We just want the articles inside the folder. So that's how you can make it. And for example, if we want only three articles to be shown as feature inside the homepage, we can select three only, maximum, so we can only get maximum three. And if I do that, I will just have the popular articles created. So now, we have the possibility of creating already a component to see the live preview or just adding the content. But for now, I would just create the component so it's just here for us to see it. Let's copy paste this content and go and create popular articles as well over here. Popular articles. Articles.xsvelt. I was going to use view. My God, my default state. Okay, so here we will use the same article card we just created for the old article so we can reuse the component of course, and then just all the articles are coming from the blog. We just render them. But in order to have this content, we will need to retrieve the data we will need to retrieve the data that is added in the relation. But before explaining that, let's see what happened. So basically if I go to our homepage and I want a new section, this section we need to add it first because I block it. So let's unlock this. Okay, so now that we can see all the blogs, I want to select the popular articles block. So here I want to define a headline, maybe best articles ever. And then I want to select the articles I want to showcase. In this case will be this one and maybe this one, only two of them for example. The idea is that right now, first of course I need to go to layout and add the popular articles I've. I, this is so funny. So popular articles, yeah, this is important. So we need to add it here and then add the word popular to all here and here. Okay, so now that we have it, it will be a render, but of course it will have a problem because we are not able to render the content we have here. Why? Because the content that we are sending here, the image, the title and this here are not being resolved at all for the API. So if we go to the draft JSON, we can see in the articles field that we have IDs. What is this? We just have the relation with that specific entry, but we don't have the content. In order to have the content, we have to resolve the relation. And in order to do that, we have an API query that we can add. So basically if we go to our page, yeah, yes, we need to add the resolve relation that you can see here. So I will copy and explain you there. So in page, right now we are getting slack and that's it, but what we need to do now is create any relations that we have. So any multiple option fields or single option fields we are using inside our schema, we need to define which component it is, which block, which field it is, which field are using multi-field option or single option. So now that we have it, we can add it into our API and say, okay, now resolve the relation to get the content from that ID. And it will actually merge that content inside the articles array. But if we want to have also the Bridge working, we also need to send this to the Bridge. So in order to do that, we need to go to our pages belt and then add the resolve relation there too. So let's do that. I go to our page. Let's just add this. And basically, now instead of using the Bridge directly, we need to resolve relations again and then pass it down. This is just for the live preview. If you don't want to use the live preview to resolve relation because you don't matter, then you can remove it and don't resolve it there. That's up to you. But in this case, let's do it so you can see how it works properly.

So now we can go to the homepage, refresh so we can get rid of the error, maybe refresh entirely. The idea is that we are reading something without saving. So that's really important. If you don't save your files, it will not be rendered. My God, okay, so here you can see now that I have the articles over here and as I am resolving the relations inside the bridge, if I change it, it's supposed to change the UI, but it's not doing it. Okay, now yeah, I need to save. So now you can see that- This is a Svelte related thing. Yeah, yeah, because I... Yeah. Yeah. I think it's this. I will tell you why. Here. Let me see exactly. Exactly, exactly. So before we were having a 500 error each time we create a page, because Svelte needs to know that it needs to reload the entire data. So if you don't pass the key, it will not re-render again. So for that in the beginning, we needed to save some content. But if we have that, it's different. Now we can actually create pages without saving. Exactly. This is one of the key difference between Svelte kit and other framework like Next, Naxt, or in general Svelte. Because at the end, Svelte doesn't change the DOM, let me say, so that doesn't use the virtual DOM. So in this case, when you drag and drop some data because you are dragging, dropping the structure, so you are changing the data and not the DOM, you have to notify to Svelte to re-render the DOM via the key attributes, okay, via the key directive, sorry. And then it re-renders again the block because you are not acting on the virtual DOM, you are acting on the parallel structure that you have but is the related to the data. This is the same thing when you are going to play with the animation, for example, or the canvas with Svelte, right? So because if you are changing the text, right? You are changing the text and yeah you have a kind of reactivity on the front end but if you are changing the structure in this way you are changing the order of the arrays because drag and dropping at the end you are changing, just changing the order of the array but you are not changing the reference to the array. So in this case, you have to help Svelte to say we are changing something so render this kind of snippet of the HTML. Yeah, this is the reason. And yeah, this is the reason why Svelte is faster than them Vue or React, right? Yeah. Yeah nice, so then we can just add new articles and you can see the live preview. of them. That's how you can select some articles or some any other content from the share block internally. So you can resolve the relations with any kind of data that you have. And that's it.

Okay now we have a question about the just notice that the app CSS in Github repo becomes app.post.css. Now do you need to pay any attention? I think that somewhere we are using post CSS instead of CSS. Yeah but at the end if you are going to use post CSS you need to use post CSS. In general, for example, in my example of this workshop I'm not using the post CSS, I'm using CSS. Yeah, exactly, this is more because as we added the plugin of Tile Window inside Svelte. With Svelte-TileWindow it generates all the, let's say the requested things to Tile Window work. So these PostCSS was generated by them. So I think it should work because you are using PostCSS in TileWindow. If you don't want to use TileWindow and you want to remove it, you can get rid of it and use a CSS, normal. Yeah, exactly. But if you want to use TileWindow then leave it as is. Yeah, it's working fine. Because you have here the preprocess thingy. Yeah, for example, if you apply something to the PostCSS, if you are going to redefine something for TileWind. Yeah, but it's not a mandatory thing. Let's say it's optional.

Nice, so then do you want to show us how to deploy or? Yes, yes, if you want I can show something about the deploy. Of course I want. Yeah. But until now everything is clear. More or less, more or less, less, more. Yeah, but yeah, don't be scared about this at the end. If you try Atom this thing, and you will see that it is easier because now it is, at the end the last part of this workshop as you can see is always creating component, remembering to define the component, and that's all. So it is quite easy at the end, right? So you can speed up the process for creating new components. And my suggestion is to create some component that you can reuse it across multiple project. In the case you need to create multiple components. But so if you want, I can show something about after you are going to create your website, you want to publish somewhere, right? So locally, you are going to use NPM run dev, right? And you are using the local web server. And in this case, you have a kind of Node.js under the hood that serve the pages and so on, right? But what if you want to generate a static site from your project and publish somewhere, right? For example, on GitHub pages or Netlify or on AWS S3 or some CDN. So in this case, you can create, you can set up Svelket to generate a static site instead of dynamic, right? So I'm going to share my screen. In the screen share, you can see the control of zoom, no? No. But you can see only the terminal? Only the terminal, yeah. Okay, good. I can move this. Okay, good. Perfect. So I need the terminal. And in this case, I'm using a project, more or less, the same that we build today with Alba. Let me highlight some difference, okay? Because as far as you know, in computer science, you can achieve the same things in multiple ways, right? So just to let you know that probably is better to know that, for example, you can achieve in different way. One way is, for example, in this case, I'm not using a Svelte preprocess. I'm using Vite preprocess, right? And the main difference is that the Svelte preprocess is more complex, allow you to access to additional feature. For example, using the templating, so loading the external files and so on. For this kind of example, I think that Vite preprocess is enough, right? And the advantages is also because Vite preprocess is shipped by Svelte, all right? So I don't have to install any other things. Another way to load the components, in my case, as you can see, in my example, I'm not using the layout. Is not our best practice, right? Because the layout is very useful when you need some container shared across the pages. So my suggestion is to use the Layout.js and Layout.Svelte. But for starting to keep it simple, you can skip the layout because it's not mandatory. In this case, I'm loading in the page.js. And as you can see, I'm using a user story block function because I want to centralize and create a kind of, as you can see, is imported by SB Lib, now we can see. And my suggestion instead of using dot dot slash dot dot slash. So a relative path when you are going to import something for Svelkite, using $Lib. $Libs is the magic keyword to refer to variable. To refer to the lib, source lib directory. So in this case, for example, if you are going to move this kind of page.js in a sub folder, you don't have to rewrite the reference because it's not relative, right? So in this case, I'm importing from s.blib and in s.blib I have the user story block function where I have the story block in it. So I just moved in a centralized place the story block in it. I'm using the access token, yes, but in this case I'm loading from the.env. So for example, if you don't want to use the access token directly or coded in your source code, you can import, and I'm using a convention by Svelkit, and I'm using $env, slash static, slash public, so it means that I'm loading a public keyword, and in this case I have public access token and public region, right? So in this way I can create some parameter for controlling the access token and the region. And then I have, obviously, the.env where I have the public access token and the public region. And then, and typically the.env I put the.env in gitignore and for, because I needed an example, I have.env.example that reflect the extractor and the name of the key that I need in my source code. But as you can see I can put some example, right? So in this case, I can ignore in git the.env but I have the.env example. So for example, in the project, if I have a new developer that want to help me, they can clone on the project, copy the.env.example into.env and then customize their access token. Right? Yeah. This one. Then we have also another way, because in the past I have some issues about importing the components, especially if you are going to play client-side rendering, server-side rendering and only server-side. So in this way, I solved a problem for importing the component. As you can see the syntax is a little bit different. So now, personally I'm using the await import in this way. And this way, as you can see, is the first step to make it more dynamic, right? So because for example, this is a string, so you can loop across all the file that you have and then perform the await import. But yeah, it's just a small thing. Yeah, other thing that I want to show you, yeah, is in now. And as you can see in this case, I'm skipping the parent not just because I don't have the layout, but because I have the user story block, right? And then in the same way, I'm loading the user story block API, and then I can use the, in the similar way the other did. Probably another improvement that I can do is because I can select the draft stories of the publisher's stories and they have to set up the version, probably is better to move this R-coded value into a key in the.env, right? So just an improvement of this code. But, let me show you, in this case, if I'm going to run this kind of a project, I can see that, let me show you, okay? This is the project server by the server locally, right? And the server locally use Node.js, right? So it means that if I want to deploy this kind of project somewhere, I need Node.js on the server side. But probably, sometimes, it's something that I don't want because I want to generate some static page starting from this content, right? For this reason, for publishing things in the SvelteKit, you have the adapters. You have a lot of adapters, but I want to focus mainly on the adapter static, right? So because the adapter static allow you to create a copy or better, generate a static HTML file in the build phase, right? And then once they are ready, you can copy somewhere. Okay, so for this, you have to install NPX and FTP, the m.adapterstatic is something that I already have on my project, but let me do again, just to show you. Okay, as you can see, I already have, and then I can go into the configuration. To the configuration, I have to jump into the svelte.config configuration, and as you can see in the kit, we have adapter. In the adapter, I'm using the static one, as you can see, because by default in the default svelte.config.js, you will find something like that, okay? But because I installed the static, I'm going to change the static. And then I can use the adapter. In the adapter, I can define, essentially, you can define more parameters, but the most important are, for example, the directory, in this case build, where you want to create your static site. And then the last thing is, jump into the plus-page.js file, or if you have the layout.js file, you have to declare a variable, a constant, sorry. The constant is PRENDER true. In this case I can generate the static site, right? Okay. Now I can run npm run build. And the npm run build because we have the adaptor static, generate all the files. And now I have my static website in the build directory. So I have the index.html, I have about.html, as you can see, because in this case I have just to two pages. And then I have underscore app where I have, if I show you, probably it's better to show you in the code, if I inspect the build directory, as you can see is ignored by Git because you don't need to commit and push this kind of generated asset. And so in the underscore app you have all the, for example, CSS and JavaScript generated. As you can see, I have one JavaScript for each component.

But it is, as you can see, is compiled. Let me see, it's not compilable. Yeah, you understand what I mean. Um, yeah, but this is magical because, because I'm not instructing, I'm not defining which kind of pages I have to render, right? So if I don't list the end point to render, Svelkit start from the homepage. In the homepage, in this example, let me run again npm run dev. And let me open again the page, okay. I have the navigation bar where I have the ahref, so I have the link for the homepage and I have the link to the about, right? So part the page, find the element, the tag element A and then try to solve the link, if find the page, then they create the page, right? And obviously, if the page is served by the pluspage.js with the pre-render equal true, okay. So if you want to allow to swap it to the mp2, does the magic, you have to put the pre-render in the pluspage.js or pluslayout.js the constant pre-render equal true. There is a way to skip the magic. There is a parameter in the configuration where, for example, you can... Let me find the documentation. Okay, probably you can list the pages. Fallback no asset pages. Not this one. I don't remember the name, but yeah, I will find it and I will let you know. But yeah, at the end you can list the entries. The entries. The keyword is entries. The entries. So if you want to specify the entries, here the configuration, right? So as you can see, you can list the entries. In this case, the author of Svelkit suggest us to use the parameter that you can send when you run npm run build, but as you can see, you can also R code the list, for example, right? As you can see, npm run build, and then the list. Nice. In this case, you can define exactly what you want to build. But without this you, Svelkit do the dirty job for you. Then now the code is ready to be deployed everywhere because now they are static pages. So as you can see, we have in the build the static pages index.html and then also about. Okay, so in this case, if you want I can show you quickly, I'm going to configure, let me show you. I'm going to do configure netlify. I'm going to do configure netlify. So in netlify, I have set up my project. I link at the project with my GitHub repository of this project. And then the only thing that I can do is to performing npm run build the same thing, the same command that is executed locally. So, and then that's all, right? So the deploy setting, as you can see, we have npm run build. And I'm saying that the asset published is under build, right? In this way I can every time I push something, a new deploy is generated, right? So let me do with a particle example. So if I change something, for example, also in the README, right? So I'm going to do a new plugin. And then I'm going to commit. Okay, in this case I'm updating the README, and then I can push to the origin. So now I'm pushing my source code into the Git, but because Git is linked with Netlify, let me jump into Netlify configuration, and if I refresh, probably I can see something that is building. So I trigger the building. And then I have in the production, this, the website deployed, and this is static, it is static. It's very important, right? It's clear until now? From my side, yes, but I think I'm not the one. Yeah. Yeah, because I can tell more, what I've said stuff, but I don't want to create a more complex things. Yeah. I will say that if they don't ask for more, we can stop here because it was a long day. Yeah. And I think we all deserve to go back to other stuff. Yeah. Just to let you know that there is a way to also to link because now I changing something in the source code, right? I push it on GitHub, and then this is the trigger for triggering the new deploy. Right. But we can configure easily, story block when the content editor publish a stories, send their web book to Netlify and Netlify run again the things because the HTML is static, right? So if you change something in the content, you have to deploy again, even if you are not changing the source code. But yeah, it is feasible in this way. If there is no request about this, because I don't want to add a lot of information, right? Probably is better to understand the basics and then maybe in the future, make the second version of this workshop with the advanced stuff. Yeah, that will be nice. Yeah, because at the end, playing with the configuration of the server side, you can do some magic about the performance. But yeah, I need the other three hours. Yeah. Yeah, I can imagine that. Rendering more since, yeah, a huge topic. Yeah, yeah, yeah. But at the end now I'm using Netlify, but I repeat again myself, you are creating HTML so you can deploy, for example, on GitHub pages. Yeah, no need to go to a cloud. Or a typical CDN where you don't have any kind of server side languages, right? Exactly, yeah. So do you have some questions? Yeah, something you wanna tell, any feedback? Anythi... May I know a bit about the internationalization part? Wow! You want to go deep in it? No, but maybe, yeah, we can explain a little bit how it'll be if you want to do it. But I don't think we have, right now, an article to send to him. So, or some references, okay? Yeah, exactly, that's a problem. We don't have the reference yet. No, for Svelte we don't have the reference. Exactly, for Svelte, yeah, for Svelte. So, we can explain how it works. Yeah, yeah, yeah. But we can't send you the code, literally, because it's not done yet. Yes. It's in progress. But I can show quickly, if you- Yeah, you can show how it works. You want to see internationalization in general with Storyblock? Okay, let me do this kind of example. weekly. So, now I'm creating a basic space with Storyblock, as you can see. If you jump in, and as you can see, if you jump into the home, you can't see the multi language, right? So, because you have to jump into the settings, enabling the internationalization, you can add, for example, multiple languages, Italian, and German, okay? And then you can add the new languages, right? So, once I set up the languages, you can jump back into the content, and in the content, as you can see now, you can select the languages. You are changing the default languages, but you can switch, for example, in the Italian language. In Italian language, you can jump into the components, as you can see, but in this case, you are inheriting the value from the default language. If you want to customize, you can click Translate, and then start translating. Okay, this is the way for translating by field, right? Because you have a website, you want to translate the same structure in multiple languages, Italian, German, and so on, right? We have an Advanced stuff, now I can't explain, but where you can create different website for countries, and you can manage, for example, the homepage for Italian countries, and, for example, on the homepage for French. And because the homepage are linked, then you can, for example, add a new component in the Italian homepage, and then, if you want, you can merge the content in other homepages. This is more complex, because at the end, you can define different structure for each countries, and it is a more enterprise way for managing the languages. Yeah, sorry, I was very short, but just to let you know that, yes, it is feasible. And as you can see, you receive the parameter of the languages in the URL, and then you can, on the code side, you can retrieve the proper languages, the proper stories in the proper language. Because at the end, the story is the same, right? But you can ask, okay, give me the content in Italian, or in German, or in the proper language. Yeah, okay, yes, you understand the point, yes.

You can retrieve the languages, and then when you call the APIs to Storyblock, you have to declare the language that you need. But we can do a second, the second part of this workshop on more advanced stuff, like multilinguals and, yeah.

Yeah, exactly, that could be nice. Yeah, I have the same session in Next, but, phew, Next was unstable, and that was kind of a nightmare. I hope that nowadays is more stable and we can make some international systems to start. But you mean on the Next side.

Yeah, on the Next ecosystem. Yeah, Storyblock is always the same, but the things are always changing the way they do things. And the translations is one. The packages that they have, like I18N, those kind of packages, sometimes they are changing the way that they want to render things. Yeah. Also in Svelkit was a nightmare before the 1.0 because they changed a lot about the structure of the file and so on. Oh my God. Yeah. But now once you understand the structure, it's very easy to understand. Now it's stable because they released the 1.0, right? But I remember before the 1.0, they changed it a lot because it was not yet released, right, so they can do it. But I appreciate all the effort and all the changes because now it's very easy. Yeah. It's very easy. Yeah, I agree. It's really cool. Good. So that's all on our side. I hope that you understand or you learned a little bit or at least you are more curious about Svelkit and Storyblock and then you can take your time to explore more. Yeah, I think that they are two technologies that you can find on the market. Not just because we are from Storyblock. But yeah, if you are freelancer or in general developer, knowing a good CMS and knowing a good framework is a very useful for find new jobs, new customers, new staff. Yeah. Yeah, exactly. To have multiple possibilities. Yes, good, what can I say, thank you for your time. Yeah, thank you so much. I hope that you enjoyed the session.