FullStack JWT Auth: Introducing SvelteKit
Tags: javascript, webdev, svelte, css
Published: 2022-02-09 07:16:55

## Introduction

Welcome to the front-end part of this series. In this article, we'll incept working with [SvelteKit][1]. It will be introduced and the file structure we'll be working with will be shown. Let's get right in!

## Source code

The overall source code for this project can be accessed here:

{% github  Sirneij/django_svelte_jwt_auth  %}

## Live version

This project was deployed on heroku (backend) and vercel (frontend) and its live version can be accessed [here](https://django-sveltekit-jwt-auth.vercel.app/).

## What is SvelteKit?

`SvelteKit` is to `svelte.js` what `Next.js` is to `react.js` with somewhat different approach and idea. It is a front-end framework that fuses Single-Page Applications (plagued by compromising SEO and others) and Multi-Page Applications (without app-like feel) to deliver a transitional application feel which combines the best of both worlds. `SvelteKit` is ridiculously `magical` in ensuring beautiful development experience and intuitive `syntax` which makes it very easy to learn and productive. It's suitable for building web applications of all sizes, even data-intensive ones.

## File structure

The current file structure for the front-end project is as follows:

```shell
├── frontend
│   ├── package.json
│   ├── package-lock.json
│   ├── README.md
│   ├── src
│   │   ├── app.d.ts
│   │   ├── app.html
│   │   ├── components
│   │   │   └── Header
│   │   │       ├── Header.svelte
│   │   │       └── svelte-logo.svg
│   │   ├── dist
│   │   │   └── CSS
│   │   │       ├── style.min.CSS
│   │   │       └── style.min.CSS.map
│   │   ├── lib
│   │   │   ├── constants.ts
│   │   │   └── requestUtils.ts
│   │   ├── routes
│   │   │   ├── accounts
│   │   │   │   ├── login
│   │   │   │   │   └── index.svelte
│   │   │   │   ├── register
│   │   │   │   │   └── index.svelte
│   │   │   │   └── user
│   │   │   │       └── [id].svelte
│   │   │   ├── index.svelte
│   │   │   └── __layout.svelte
│   │   ├── sass
│   │   │   ├── _about.scss
│   │   │   ├── _form.scss
│   │   │   ├── _globals.scss
│   │   │   ├── _header.scss
│   │   │   ├── _home.scss
│   │   │   ├── style.scss
│   │   │   └── _variables.scss
│   │   └── store
│   │       ├── notificationStore.ts
│   │       └── userStore.ts
│   ├── static
│   │   ├── favicon.png
│   │   ├── robots.txt
│   │   ├── svelte-welcome.png
│   │   └── svelte-welcome.webp
│   ├── svelte.config.js
│   └── tsconfig.json
├── Pipfile
├── Pipfile.lock
└── README.md
```

Kindly grab it [here][2]. It contains some folders and files we'll be working with. Currently, most of the HTML and CSS(Sass) have been written and compiled. We'll continue modifying these files as we move on but before then, let's acquaint ourselves with what each sub-folder does.

- `components` is a sub-folder that was created to house additional components, in this case, `Header` component. It was created for modularity sake.
- `dist`: This houses the minimized CSS file for the entire project. It was automatically created from the `sass` files using [Live Sass Compiler by Ritwick Dey][3] VS Code extension.

- `lib`: Since many requests to the server will be made to create, authenticate, and authorize users in the app, this sub-folder houses two files that will help prevent over-bloating of each component with long scripts. The current files in this folder are `constants.ts` &mdash; only exports the `BASE_API_URI` to avoid repetition &mdash; and `requestUtils.ts` &mdash; a file that exports most of the functions used for making requests to the server as well as storing and removing `refresh` tokens to the user's browser's localStorage. It just serves as a nice abstraction to keep code organized.

- `routes`: This folder was automatically created when you run `npm init svelte@next name_of_project`. It does what its name suggests &mdash; routing. SvelteKit utilizes a somewhat `filesystem-based router` which generates your routes based on your folder/file structure. For example, since our `routes` folder contains `accounts` sub-folder and the `login` sub-folder with an `index.svelte` file, to navigate to the `login` page, your URL will be `http://localhost:3000/accounts/login`. Based on the file structure. If we had two login pages, like one for normal users and the other for admins for instance, we could have `users` and `admins` sub-folders inside the `login` folder with their respective `index.svelte` files. Then the URL to the `users` login page would be `http://localhost:3000/accounts/login/users` and the `admins` `http://localhost:3000/accounts/login/admins`. It should be noted that it's not a must to create folders and then `index.svelte` in them. I could have achieved same thing if I had only created an `accounts` folder and then `login.svelte` in it. I just wanted a clean structure. In SvelteKit, `index.svelte` is taken as the base file for the page. For instance, the `index.svelte` at the root of the `routes` folder will be served on hitting `/` URI, same as the the one in `login` folder. `__layout.svelte` is one of the special files SvelteKit recognizes &mdash; `__error.svelte` is another one. It houses the components you want on every page of the current route. Which means, on all pages. If you have used Django Templating Language, it serves same purpose as your `base.html` which other templates inherit. It's important to have the `__`(double underscores) before it. You are encouraged to consult the [docs][4] for more clarifications.

- `sass` is just the folder I created to house my sass codes. Most of styles in there were copied from the demo project that comes with SvelteKit and the compiled CSS files were the ones inside the `dist` folder.

- `store`: Stores serve same purpose as `redux`, `ContextAPI` and maybe `reactQuery` in react, and `vuex` in Vue. They simply help your application behave consistently. In our case, we have two stores &mdash; `userStore` and `notificationStore`. They do just what their names suggest &mdash; store user and notification data. We have [`writable`][5] stores in our case so that we can have access to `set` and `update` methods in addition to the `subscribe` method all store types have. The `userStore` exposes the current user's data available in object type while `notificationStore` gives a string notification message.

- `static`: This houses the static stuff such as your `images`.

That's it for this article. Up next is some detail about SvelteKit.

## Outro

Enjoyed this article, consider [contacting me for a job, something worthwhile or buying a coffee ☕](mailto:sirneij@gmail.com). You can also connect with/follow me on [LinkedIn](https://www.linkedin.com/in/idogun-john-nelson/).

[1]: https://kit.svelte.dev/ "The fastest way to build svelte apps."
[2]: https://github.com/Sirneij/django_svelte_jwt_auth/commit/d85e17fc4ecdd283176999a9e77650e3b9c877d1 "File structure commit"
[3]: https://marketplace.visualstudio.com/items?itemName=ritwickdey.live-sass "Live Sass Compiler by Ritwick Dey"
[4]: https://kit.svelte.dev/docs "SvelteKit docs"
[5]: https://svelte.dev/tutorial/writable-stores "Writable stores"