KNJS로 단일 페이지 애플리케이션 구축

KNJS를 사용하면 서버 측 렌더링 없이 일반 단일 페이지 애플리케이션을 구축할 수 있어 유연성과 편의성을 제공합니다.

### VitePress에서 Vite 및 Vue 라우터를 사용하여 일반 단일 페이지 애플리케이션 구축하기
* 🛠 VitePress를 사용하면 서버 측 렌더링(SSR)에만 사용된다는 일반적인 생각과 달리 **Vue를 사용하여 고전적인 단일 페이지 애플리케이션(SPA)을 구축**할 수 있습니다.
* 🛑 VitePress에서 SSR을 비활성화하려면 **`ssr: false`**를 설정하면 됩니다.
* 📦 SSR을 비활성화하면 **미리 렌더링되는 경로의 수가 줄어들어 SPA에 더 적합**합니다.
* 🚀 SPA용 단일 HTML 파일을 생성하려면 **VitePress 훅(`pre-render-routes`)**을 사용하여 기본 경로를 제외한 모든 경로를 지우면 됩니다.
* 🌐 선택적으로 라우터 옵션에서 **`해시: true`**를 설정하여 해시 기반 라우팅을 사용하도록 Vue 라우터를 구성할 수 있습니다.
* 📈 VitePress로 SPA를 구축하는 이유는 **나중에 SSR과 같은 기능을 유연하게 추가**하고, **API 경로에 Nitro를 활용**하고, **파일 시스템 기반 라우팅 및 자동 가져오기**와 같은 기본 제공 기능을 활용하기 위해서입니다.
* 💡 구현을 소유하고 종속성을 설정할 수 있는 코드가 있고 원하는 대로 패키지를 설정할 수 있다는 장점이 있지만, **모든 기능이 내장된 경험을 원한다면 VitePress를 사용하는 것이 좋습니다.**

hey everybody, welcome back to a new video on this channel. Today, we have a look into building a next single-page application because you can do that with that amazing meta-framework. So, no need for SSR. Let's see how to disable it and what else to check out. Let's [Music] go. Of course, you all know KNX has amazing capabilities when it comes to service rendering, be it SSR on demand, hybrid mode, Statics, High generation, ISG, ISR. You know all the terms, and we'll make a video about that in the future too. But today, we talk about building plain old single-page applications because this is what you can do with KNJS as well, even though most people think, Oh yeah, KNX, we need service at rendering. But don't worry. We'll give you the freedom to do whatever you want, even without running a server at all, just having a single HTML file where your whole Spa lives in classic as you do it with BL VGS. So, let's have a look into our demo application and figure out how

we can set it up. Don't worry, it's a few lines of configuration and a few extras here and there. Depends on what you need. Let's check it out. And yes, as usual, we have a very, very minimal demo application with a few pages pre-generated. So, let's have a look. We have our index page here that just says index page, and then some links to the about page. Well, that should actually also go to the about page, and a user test page. The about page, same idea, just a few links, make it a little bit bigger. Here we go. And then we have also a dynamic page to show how Dynamic Pages behave when we use single page application mode. Later on, on no SSR, by just saying, Okay, this is a user, so on, so on page, and then going all the way with the next links again. And then our most important part is our KN config. So, let's have a look. The N config is pretty simple. We only have our wonderful black background and white text. And if you now generate the whole application by using

stus High generation and running pmpm generate well. Then we will see that KNX will actually preuner 10 routes here. So, this is not exactly what we want, right? We have a payload payload Json here with some build hash. We have the users about users test um all generated and all of these things. And the problem with that is obviously that now we don't really have a single page application. If we have a look in output public and let's say uh about index HTML, well, that doesn't look like an Spa. It says about page right here. So, that's not what we want. The good part is we can change the easily. So, the first thing we should do is disabling serers side rendering in general. And we can do this in our KNX config here. So, let's close the rest and just say SSR false. And this is the only thing you need to fully disable service at rendering. If we now generate the page again, let's see what's happened. Of course, the static preset is used again because we want eventually only static.

file and here it gives us a warning. This says HTML content not pre-rendered because SSR false was set. You can read more in the link. Think and this is because commonly people for whatever reason probably some wrong tutorials out there think, Oh yeah, we need SSR false for static side generation. It's not the case. If you want fully like, you know, SEO, SSR at build time static side generation, then you need to set SSR to true or just remove the option because true is the default. But as you want to build clean plain old Spa, SSR false is the way to go. So don't worry about the warning. It's actually what we want. That's also what the docs say there. So a little shortcut. And now let's check out what we actually have in our pre-rendered routes. So now we went from 10 to 5. So what exactly happened here? Well, we see okay, index is still generated, about is generated, and 44 index in 200. So what's fully missing is the whole users and then name here.

users about users test uh these routes are fully missing well that's good in that way because we don't want them to be generated. We also don't want these to be generated but let's see what actually changed because SSR false was set. The built-in crawler of KNX the Nitro well they couldn't really detect any new links because there are no links in the not generated SSR HTML because it is not generated right. Only have this like little loading spinner but you can also set that through an SP loading template. In this case it's it's not set but you can easily do that and also Define your own one. Nevertheless there is no link to be crawled so we don't have these Dynamic Pages which is totally fine but there's still one thing that's not that good. We still generate all the static pages so like index and about right now. If you have like 100 static Pages the build will still take a little longer. Now on the one side you can say okay that's good I want to have it that way.

because then you can still have a pre-rendered meta tags. Um, that you set through n config. But if you say, you know what, I just want one single file, then there's a little tweak we have to do. And then we're done. And this little trick is pretty simple. We use a hook of KN so we hooks in here. And then we use the pre-render routes hook. So we say, okay, all the routes that should be pre-rendered, let's do something with them. And in here, we have the routes our argument. Well, actually get a whole context of the hook. But the routes is in that object. And here we just say, you know what, routes, which is a set of routes, just some strings, we clear all of them. So please do not generate any routes except the default. And now, if we render the whole thing once again, let's see what's happening. And now we see, okay, we're down to the three routes that are necessary. And that's totally fine. They're all the same, all just an index HTML, 404, and 100. So the good part is

there that you can easily just upload things straight away to platforms that support a 404 HTML or 200 HTML, and then they will automatically recognize, oh yeah, okay, good, let's send everything there, perfect. And if you have your own, let's say VPS or your own, I don't know, ship on your own FTP server, then you can set up your Apache or Enginix to always serve the index HTML or 200 or 404. It doesn't matter because they're all the same for all the error codes, and then you're good to go, nice. So now we have our play Old Spa. Also, let's double-check real quick if it's really an Spa, so if there's nothing pre-rendered, and let's have a look in the output files, and then we do one more thing with the router. So let's have a look at the index HTML, and here we have some prefetches, okay, that's fine. Maybe let's enable Word WP real quick. Then we have server rendered set to true, and that's false in.

this case that's how the payload can be read here data s ISR is false and all is correct wonderful so that's great last but not least there's one more thing as mentioned we can also set up the router to do something more Spa like so if you don't want to set up your engine X or your Apache to always serve this in this document but you actually just want to have this one single fire and use fragment or hash based routing this is something that view router supports and then next it's also not too difficult to set let's do that and for this we just write router and in here we have an options object and here we set hash mode to true to say okay view router should please use the hash mode and let's have a quick look in development or also in production that doesn't really matter you know what let's just build it real quick for prod again and uh Ser it so we actually have the whole site and then see what what um the hash mode is actually doing I know most of you

probably already know that, but still, it's good to have a look at it in the video because why not. So after generating, we can deploy output public anywhere, or we use npx Serve. That's the easiest way of previewing that locally. We can also use pnpx or whatever execution option you want. And after we serve that, we can have a look at Local Host 3000. So let's quickly jump on there and see how things will work. And here we are in our demo application. Wonderful it is all deployed to production as in like we just run the generated build. We could also upload it somewhere. Now we have the hash route over here, so we clearly see, okay, all right, this is using fragment-based routing. We only need to serve the index HTML, and we're good. And now if we go to about, for example, then we have that fragment in front. That's correct as we should, and it's great. And now if we reload the page, well, that should be pretty fast. We see this little

flickering, so there's no content rendered. And also see here very clearly, nope, there is nothing available in the index HTML, no content in there. And that's great, but now you might wonder, okay, we can set it all up, it's not too difficult. And depending on whether you want to render all the static SES or only one single HTML, we can have a little thing with the hook there that we did with the pre-render output hook. But why exactly should you build Spas with with njs? Well, the reason is pretty simple. First, first of all, when you start a project, you might think, okay, we have this very tiny scope, we just build a simple spa and you're good, and you can start in and view, for example, of course too. But then if people say, yeah, but now we need server-side rendering, they really want to either build your own SSR setup, which is not that easy, and you run quite some pitfalls that well, we as in KN team already solved. That's why the framework is there too. Or you say, okay, then we

migrate our View application over to KN so that that's one way, of course, um, but on the other hand, you can say why not ensuring that everything is possible at some point. When I say okay, I have some marketing pages, I want to generate them, no problem KNX can help me with that. Or I need some service that running for certain pages but still keep things in a plain old Spa if needed, which you can do with rout roads. So then choosing KN might be a good option, as well as the other features like the file system-based routing that we have, Auto Import, and so on, so on. These are all things you can set up your own in your own View application, right? We have unplug in Auto Import, unplug in view rou, uh, and so on, so on, so that all works too. But well, you have to set up yourself, and you have to deal with when the implementation doesn't work. So that's always the benefit of owning the implementation, the code you can set up the dependency, you can set up the

package as you want, but if you want to have that whole built-in experience, then KN is a good way to go. Plus, of course, you have all the modules. You also have, of course, view plugins and other recipes and cookbooks available there. But also, nobody stops you from using just typical view code in your next application, so you can do the same. I hope that kind of makes sense, and that's also why I commonly build single-page applications with KN because it's pretty easy and straightforward to do. Plus, if you want to add then some kind of backend, some kind of API routes, Nitro is there to solve it for you. And that's it. So now we know how to build a simple Spa with KNJS, how to configure everything, and well why you should even do that and not just say let's use Plain View, which is totally fine too. It's just a matter in this case of preference and where the project might go, plus what you're comfortable with. Nevertheless, try it out, give it a shot. Also, watch the latest St

R view episode. Michael is back, so we have a little discussion about wonderful design patterns in Vue. If you haven't heard about it yet, check it out. Link is everywhere. And um, yeah, drop me comments if you have questions, if that makes sense, if you had any problems with Spa, and next, or if there's something like, hey, maybe this would be cool out of the box. So yeah, let me know. As usual, see you latest next week, uh, hopefully here in DJA View, and talk to you soon. Happy hacking. [Music]

Building a plain SPA with Nuxt!?

Web Engineering Consultant, Managing Director and Nuxt.js team member

Alexander Lichter

KNX로 단일 페이지 애플리케이션 구축

KNX는 서버 측 렌더링 없이 단일 페이지 애플리케이션(SPA)을 구축할 수 있는 유연성을 제공합니다.

이 과정에는 몇 줄의 구성과 KNX 구성에서 서버 측 렌더링을 비활성화하면 됩니다.

이렇게 하면 KNX는 정적 파일만으로 SPA를 생성하므로 서버 없이도 자유롭게 SPA를 생성할 수 있습니다.

KNX에서 정적 사이트 생성을 위해 SSR False 설정하기

흔히 오해하는 것과 달리 KNX에서 SSR을 false로 설정해도 정적 사이트 생성에는 영향을 미치지 않습니다.

KNX의 기본 제공 크롤러는 SSR을 false로 설정하면 새 링크를 감지할 수 없으므로 사전 렌더링된 경로가 감소합니다.

필요한 경로만 생성하기 위해 사전 렌더링 경로 후크를 사용하여 기본 경로가 아닌 모든 경로를 지울 수 있으므로 빌드 프로세스가 더 효율적입니다.

SPA를 위한 프래그먼트 기반 라우팅 설정하기

조각 기반 라우팅을 위해 인덱스 HTML을 제공할 자체 서버를 쉽게 설정할 수 있습니다.

보기 라우터에서 해시 모드 옵션을 사용하면 각 경로에 대해 서버를 구성할 필요 없이 조각 기반 라우팅을 활성화할 수 있습니다.

프로덕션용 사이트를 구축한 후에는 어디든 배포하거나 npx Serve와 같은 도구를 사용하여 로컬 호스트 3000에서 로컬로 미리 볼 수 있습니다.

NJS는 단순한 SPA에서 서버 측 렌더링 설정으로 쉽게 전환할 수 있는 솔루션을 제공합니다.

마케팅 페이지를 생성하고 특정 페이지에 대한 특정 서비스를 실행할 수 있는 유연성을 제공하는 동시에 필요한 경우 기존 SPA를 그대로 유지할 수 있습니다.

또한 NJS는 파일 시스템 기반 라우팅 및 자동 가져오기와 같은 기능을 제공하여 뷰 애플리케이션에서 구현 문제를 설정하고 처리하는 번거로움을 덜어줍니다.

KNJS로 간단한 단일 페이지 애플리케이션 구축하기

KNJS는 단일 페이지 애플리케이션 구축을 위한 모듈, 보기 플러그인 및 쿡북이 포함된 기본 제공 환경을 제공합니다.

Nitro는 백엔드 및 API 경로를 추가할 수 있는 솔루션을 제공하여 쉽고 간단하게 만들 수 있습니다.

개인 취향, 프로젝트 요구 사항, 편의성 수준에 따라 KNJS와 Plain View 중 하나를 선택할 수 있지만, KNJS는 원활한 SPA 구성 및 구축 방법을 제공합니다.