In this course we will be using Directus 9 as our API and CMS, and of course Nextjs for the frontend of our site. Kind of like we did with <a title="" href="https://watch-learn.com/courses/making-websites-nextjs-and-strapi" target="_self">Making Websites With Next.js And Strapi</a> series.
This time however we will add Tailwind into the mix and also include React Query right from the start for better performing API requests, caching, state management and so on. Oh, and also instead of using REST API we are going to use GraphQL for this series.

Directus 9 + Next

In this series we are going to learn how to create a websites using Next.js. The main focus of the series will definitely be Next.js, but we will do some work with Strapi too, which we will use as our API and CMS

Making Websites With Next.js And Strapi

In this series we are going to learn basics of React library and all of it's advanced features that are applicable in the year 2020.

React 2020

In this series we are going to be using WordPress REST API and Sapper for Svelte to create a modern, headless website that is going to be using WordPress as a backend and Svelte as a frontend.

Creating Svelte, Sapper and WordPress Website

Viewer named Robert commented on one of the videos asking how to create a multilevel navigation in Directus 9 so that you can consume it through the API and that way create a navigation on the frontend. 

Unfortunately I wasn’t able to find a perfect no code way of doing this, so I don’t think that Robert will be very pleased with the result, since he already knows about this method. Sorry Robert.

However I think this is a good enough way to create multilevel navigation, it’s not perfect by any means, but it is good enough if your site or app does not heavily depend on multilevel navigations with a lot of levels. 

But if you need a way to allow users of your backend to create navigations, like Main navigation, Footer navigation, maybe navigation on a sidebar, with 2 or 3 levels - this way of doing things is going to be more than adequate. 

Let me show you how.

### Setup

For this demo I’m using Directus version 9.14.5, but I guess this method should work on any version that supports Repeater fields.

First of all I will create a collection called Menus.

This collection is going to have only two fields - one is going to be called title, so that we can name our menus and so that we can filter them by name on the frontend.

The other field is going to be a repeater field and that is where we are going to define our menu items. 

Let’s create repeater field, give it a name of `menu_items` 

Next let’s create two fields for the repeater - they are going to be called `label` and `url` and both are going to be just strings with input interface.

And by just doing this we created a system for single level navigation. 

However we want a multilevel navigation. So let’s create one more field, and this one is going to be of type JSON and with the repeater interface. We are going to call it  `submenu` and it is also going to consist of two fields called `label` and `url` .

And I think you can now see where I’m going with this. If you need three levels you would add one more repeater here and so on.

Of course if you need unlimited levels and you depend on that functionality, then maybe it’s best to try to find a code based solution for this problem. 

But from my experience two or three levels are going to be enough for at least 90% of cases. 

Ok, let’s save this and test it out.

### Create Menu

We go to Menus, create new add a title of “Main navigation”. 

And then on “Menu Items” you click “Create new” and start creating your menu items.

The first one is “Home” and it’s going to be only single level.

The second one is “About” and here we are going to add a few subitems. 

And let’s create one more, called “Contact” which is going to be single level item.

And that is it.

### API response

Let’s see how this is going to look when we try to get the menus from the API. 

First we go to “Roles and Permissions” . Click on “Public” and allow everyone to be able to see our navigations. 

Now go to `/items/menus`. And here we can see how this looks in JSON format that we can consume on our frontend.

One nice thing is that we can rearrange the menus in the backed, and that will reflect on our data. 

So now we have “Home”, “Contact” and “About”. 

You can do the same thing with submenu items.

Nice.

Directus 9

In this video I'm going to show you how to create multilevel navigation in Directus 9, without any code.

How To Create Multilevel Navigation In Directus 9 (NO CODE)

### What is AppWrite

[AppWrite](https://appwrite.io/) is an Open Source backend as a service platform, similar to Firebase and Supabase. What makes it different from those services is that it only has self-hosted version at the time of making this video, and the cloud version that you can pay for is coming soon.

Supabase also has a self-hosted version, but from what I understand it’s kind of a pain to setup. I didn’t try it so maybe take this with a grain of salt, and be sure to correct me in the comments. 

AppWrite on the other hand is super easy to setup locally using Docker, and that is not all, it also has one click install on Digital Ocean, which I’m going to show you in this video.

One more big difference when comparing it to Supabase is that AppWrite wraps around NoSQL database while Subabase is connected to Postgres database. So if you are choosing between these two, keep that in mind, because if you need a relational database, AppWrite is not going to be for you. 

At the time of making this video AppWrite is in version 0.14.2 but it has a great feature set comparable to Supabase. 

- It has a database
- It can handle your storage using Buckets
- It has users section which is actually authentication with more than twenty providers
- It has cloud functions out of the box with more than 15 runtimes
- It has a great set of SDKs for the most popular languages and platforms including Flutter, Android, iOS, Kotlin, Python, PHP and of course JavaScript which I’m going to show you in this video.
- SDK is super simple to use
- And you can also install one instance of AppWrite but have it run multiple projects

You would usually use AppWrite to create your own backend. Because, even if AppWrite looks like a CMS on the first glance, and you can add data to your Database from its admin area, it’s still miles away from something like Directus or WordPress which have a lot of components that can make editing actual content and data of your app enjoyable experience. 

AppWrite is just going to serve as a backend to your backend and it will allow you to easily read and write data, authenticate users and provide you with Cloud functions and storage system. But not much else. So keep that in mind… and you know… read the docs. 

In this video I’m going to show you how to setup AppWrite locally first, but for the demo we are actually going to be using Digital Oceans one click setup for AppWrite. 

I’m going to show you how to quickly get the data from the database, how to register and login users, and also how to create protected pages on your site which only authenticated users can access. 

This is going to be super simple using AppWrites JavaScript SDK. 

For the frontend I will of course be using Next.js. But you can use any framework you like.

### Local Install

To get started locally first install Docker Desktop on your machine if you don’t already have it. 

Once you have it installed, just copy the command from the modal you get when you click on “Get started” button on AppWrites site. 

Paste that command in your terminal, wait a bit, answer a few questions, and you are good to go. 

Visit `http://localhost` in your browser and you should be greeted with AppWrites account creation screen. 

### Digital Ocean install

However for this demo I’m going to be using Digital Oceans one-click install. If you wanna follow along with me, you can [sign up using my affiliate link and get $100 of credit for 60 days](https://m.do.co/c/808fb4bb0039), so you can play with AppWrite there or with any other technology you like, the link will be in the description bellow. 

And I think this is the easiest way to get started with AppWrite, but local setup is just fine if you wanna just test it out locally.

Once you sign up to Digital Ocean Account you can click on create button to create a droplet. 

Then go to Marketplace and search for Appwrite, click on it. Choose any droplet you like, but I suggest you don’t go for the cheapest one. I will choose the one for $12 per month with premium Intel chip.

After that you can choose region for your datacenter. Choose something closest to you. 

Since I’m in Croatia I will choose the one in Frankfurt.

I will choose SSH key as my authentication method, but you can choose root password if you don’t know how to use SSH or you don’t wanna bother with it. 

Change hostname to something like AppWrite and then click Create Droplet. 

Now we wait for a minute or two for our droplet to be created.

Once this is done you will see AppWrite logo and “Get started” text, click on that. And then on “Quick access to AppWrite”. 

If you get “Site can’t be reached” error, don’t worry. Wait for a few more minutes and try to refresh the page. This is because AppWrite needs a few minutes to get set up on your Droplet.

When you refresh the page after a few minutes you should be greeted with the Sign Up page, on which you can create your admin user.

Add your data and click Sign Up. And that is it, we are ready to start creating our app. 

### Create simple project

First of all let’s change the theme. 

Ok, better.

Now let’s create our first project. Name your project however you want, I will call mine “Movie Database”. 

On this page you can see all the features that AppWrite comes with. Database, Storage, Users and Functions.

Users also contain authentication methods you can use with AppWrite. We are going to authenticate with user name and password in this video.

Let’s go to the database and create our first Collection. I will name mine “Movies”. 

On this page you can set read and write permissions either on “Collection level” or if you wan’t more granular control on “Document level”. 

I’m going to set Read Access to be `role:all` so that every one can read our documents. 

Documents are items in your database and they are made up of Attributes. If you now go to documents, you will actually see “Create Attribute” instead of “Create Document” button. Because you need at least one attribute for your Documents.

So let’s create some. There are a few attribute types, String, Integer, Boolean and so on. All the usual suspects.

Let’s add a String attribute, and give it and ID of title, the size is going to be 100. Now click “Create” button.

Now I will add one more, this time of type integer. And I’m going to call this one “year”. So our movies are going to have a title and a year. 

We have two Attributes now, so that means that we can create a few Documents. 

So the title of my Document will be “Big Lebowski” and the year is going to be 1998. Note that under permissions you can add read and write access, for that specific document. So that is cool. 

Let’s add a few more Movies, or you know… Documents.

Ok, so now we got our first project set up, now we just need to click on “Home” link and then click “Add Platform” so that we can use AppWrite SDK in our Next.js app. Click “Add Platform” and choose “New web app”. 

For the name we can just write “Movie Database” again. For host name you actually need to add URL to your site that is going to be using AppWrites API. 

We are just going to add a wildcard for now, so that we can access it from anywhere, including our localhost. 

In production of course you wanna restrict access so that only your web app can use it. 

And with that we are done with our demo setup, of AppWrite. Let’s now quickly create a simple web app that that will get our Movies (or Documents) and allow us to authenticate our users.

### Next.js setup

I’m using Next.js for this demo with only Tailwind installed. To create the same setup you can just install Next with `yarn create next-app name-of-your-project` and then follow simple instructions on Tailwind page. 

If you want to automatically install Next and Tailwind together with just one line you can run `yarn create next-app --example with-tailwindcss name-of-your-project` but be aware that this is going to install Next.js with TypeScript support. So if you don’t want to use TypeScript go with the first example.

### Install AppWrite SDK

To install AppWrite SDK for web just run `yarn add appwrite` in the root of your app. 

But we are also going to add `uuid` package, because we are going to need it later on.

Nice. 

Now let’s just add `.env.local` to the root of our project and add ENDPOINT, PROJECT_ID and COLLECTION_ID. 

ENDPOINT is the url of your site plus `/v1` .

You can find PROJECT_ID by going Home and then clicking Settings. Here you can copy your Project ID.

For the COLLECTION_ID go to the Database click on Movies and then Settings. 

You can copy the Collection ID from here. 

Now just copy and paste all those variables and prefix them with `NEXT_PUBLIC_` so that we have access to them in the browser. 

And that is it. We can start developing. 

### Getting the Documents (Movies)

In `index.jsx` import `Appwrite` so that we can use the SDK.

And after that we are going to get our Movies in `getServerSideProps` , so on the server-side. But you can also do it the same way on client side. There is no need for `fetch` , `axios` and so on. SDK is going to handle all of that for us.

First we new up `Appwrite` and just call it `sdk` .

Then we define our end point and project from the data that we saved in `.env.local` . We are going to use these two lines before everything we do with AppWrite SDK. 

For the purposes of this demo I’m going to always add them, but for the project in production it would make more sense to create a React hook for that or some function that you can reuse. 

Then we wanna list documents from our Collection. And as you can see, AppWrite SDK is very simple and intuitive, you just say `listDocuments` and pass in the collection you want to list the documents from, and then wait for the response.

If we get the response we return it, otherwise we return an error. 

We await for the response to resolve, and pass it to the props of our component. 

Now we just pass `movies` prop to our component, and then we can map over it and display the title and the year of the movie. I also added a `Link` component that is going to link our movie to the URL of `/movies/id-of-the-movie` which is going to show detailed view for all of our movies.

And that is it. If we take a look at our homepage, we should see a list of movies. 

Nice.

### Getting a single document (Movie)

To link our movie to the movie details page, we first create `movies` folder under pages and in it I will create `[id].jsx` file since we are going to get our movie by ID. 

In `getServerSideProps` we are going to pass in `ctx` or context. And then we are going to use that context to get the `id` of the movie that we wanna show.

After that we just initialise AppWrite SDK like we did on the index page.

To get the document, it’s very simple, you can just use `getDocument` method, pass in Collection ID from `.env.local` and the `id` of the movie that we got from context. 

Now we just wait for the response, and then send it to our `props` property.

We receive that property in our component through props, and then just add the `movie.title` to the `<title>` tag in `Head` component, and also display the title of the movie on the page. 

And below it, we can display the year in a `` tag.

Now on our Homepage when we click the movie, we should go to the URL `/movies/id-of-the-movie` and we should see the title and the year of that movie. 

Details page of the movie… Done!

### Register users

To register users first we need to create `register.jsx` page. Import `Appwrite` of course, and also import `uuid` because we are going to need that to generate and ID for the user. 

On this page we also have a simple form with an e-mail and password fields, and of course a button for submitting the form. At the bottom we are going to display the errors if we get any.

Nice thing about AppWrite is that it has server-side validation that you can use on your frontend. I will show you how in a few moments. 

And don’t worry, all of this code is going to be available for you on Github, the link will be in the description below. 

And of course our form has a submit method that is going to call `handleSubmit` method when the user clicks the button. 

Now let’s create a state for handling our errors.

After that we are of course going to initialise AppWrite SDK. 

Now just create `handleSubmit` method. In it we first `preventDefault` of course, so that our page doesn’t reload.

And then we just use SDK method `account.create` and in it pass in the ID generated by UUID, email and password from our form. 

Then we just console log the `response` but if we get an error we wanna `setError` with the method from `useState` hook. 

That error is going to be displayed below the form. 

And that is it, let’s test it out. 

Go to the `/register` route and try to write some random string in the e-mail field.

You will get “Invalid email: Value must be a valid email address” error. 

Ok now add an email address like “john@doe.com” but add just three characters for the password. Now you will get “Invalid password: Password must be at least 8 characters” . 

So as you can see validation works.

Let’s now add a password that is at least 8 characters long and click “Sign Up”.

Nothing will happen, since we didn’t code anything to happen. But if we go to our admin area under users, we should see our new user. 

Click on the user and add a name for it, since we didn’t send the Name in our request, and then click Update. 

We registered our first user, now we can create a Login page.

### Login users

To login users we pretty much do the same thing like we did when registering users.

Create `login.jsx` page, in it we have almost the same setup with the form, handeling submit and we are using `useState` to display errors. And I’m also going to initialise Next router so that we can send the user to the User Area if the login is successful. 

In `handleSubmit` we need to use `account.createSession` method to which we will send an e-mail and password from the form. 

And this is going to create a session for our user.

Now if we get the response with the `userId` we wanna push the user to the user area page. Otherwise, we wanna set the error and display it, just like we did on the register page. 

Let’s test this out.

Try to login with invalid credentials, and you will get “Invalid credentials” error.

But if you use the right credentials of the user we just created, we should be redirected to the user area page. Of course this is going to produce an error, because there is no `/user-area` page yet.

Let’s create one now. 

### User area

First of course let’s create `user-area.jsx` inside our `pages` folder.

In it I will just add the text that is going to say Hello, and the name of the user.

Then I’ll just add a simple "This is an authenticated page.” paragraph. 

And bellow that I will add a logout button, that is going to trigger `logout` method once somebody clicks on it.

Ok, now we need to add some logic to make all of this work.

I’m going to set two states - first is going to be `user` , in it we will set the users data, so that we can display it and after that I will set `isAuthenticated` state, so that we can check if the user is authenticated.

Also we wanna initialise Next router so that we can redirect users that are not authenticated. 

After that we initialise `Appwrite` of course, like in all the previous examples.

Now I want to get the session for the current user, and wait for the response. If we get `current` property in the response, then we wanna set authenticated to true. 

But if we get `error.code` with the code of `401` which is the code for unauthorised request, we are going to push the user to the login page. 

After that we are going to use `useEffect` which is going to depend on the `isAuthenticated` state, and when that state changes we are going to to try to get the account details for the current user, with `account.get()` method. 

We don’t need to send anything to that method because AppWrite SDK is going to try to get the data for the user from the session we created when logging in. 

Now we wait for the response, and if we get it we set `user` state to be that response. 

And we can just console log out any errors we get. 

In the `logout` method we use `account.deleteSessions()` method to delete all users sessions. 

And then we just push the user to the homepage if the request was successful, otherwise we console log any errors we may get.

Lastly we are checking if the user is not authenticated, and returning blank page if that is the case. 

We do this because otherwise we would get flash of the page that the user is not supposed to see if they are not authenticated until all the other logic is run, which is just a fraction of the second, but it is visible. 

This should be it. Let’s test this out.

Now when you login with correct credentials, you should be redirected to the `/user-area` page which we now have. 

You can see the name of the user after Hello text. And if you click “Logout” button you should be redirected to the Homepage. 

And now if you try to manually go to the User Area page, you will be automatically redirected to the Login page. 

And there you have it. In a few minutes we displayed our documents and built a simple authentication system. 

### Conclusion

Of course AppWrite offers much more functionality than what I showed in the last few minutes. 

žWe haven’t even touched Cloud Functions, Storage and Webhooks. For that you will need to check out AppWrites documentation, which is always a nice thing to do. 

But, as you could see AppWrites SDK is very simple and straight to the point, so implementing more complex functionality to your app or website should not be much of a challenge.

Frontend Tips

AppWrite is a secure open source backend server for Web, Mobile and Flutter developers. And we are gonna check it out in this video.

Let's Checkout... AppWrite

Namely if somebody gets a hold of the Admin Role ID he or she can easily then signup as an administrator to our app, and the do as they please in the admin area.

In this quick episode we are going to fix that.

Viewer called Locness noticed a potential security flaw on our sign up form. In this episode we are going to fix that.

Protect Signup Form From Hackers

Remix is a React framework similar to Next.js and I would say that it’s the only real competitor to Next.

It is focused on web standards and modern web app UX. Although Remix is pretty new to Open Source, it has been around for about two years now, but as a payed software that was recently Open Sourced.

The main selling point of Remix is that it embraces web standards and tries to leverage them to provide great user and developer experience. 

Remix is trying to bring old school web development practices and patterns to the modern JS world. So if you are and old school developer like me these things are going to be pretty familiar to you.

### Philosophy

Remix philosophy consists of few parts:

Embracing Server/Client model - which means that if you are doing things Remix way, most of your data is going to be coming from the server - there is no Static Site Generation or Incremental Static Generation in Remix, only server side rendering, for which Remix provides very nice APIs to make your life as a developer easier. 

If you wanna make your site faster this may sound a bit counter intuitive, but since you can transform your data on the server this means that you are sending only the data that the user needs on every request, so your payloads can be pretty small. 

If you are using modern web infrastructure combined with native web features like `prefetch` this can make your site very fast even without serving mostly static content.

Remix is very easy to deploy and plays nicely with [Vercel](https://vercel.com/), [Cloudflare Pages](https://pages.cloudflare.com/), [Cloudflare workers](https://workers.cloudflare.com/), [Fly.io](http://Fly.io) and many others, so you can easily serve your Remix site from the servers that are closest to your users using CDNs.

Another core philosophy is that it embraces native web standards like HTML, HTTP, Web Fetch API, Request, Response, URLSearchParams and others that already live in your browser. 

Progressive Enhancement is another big thing for Remix, and because of it, data layer of Remix can function with or without JS. It uses JS to provide nicer User Experience but you can add or remove data from your data source without using JS at all, because Remix knows how to work with the lowly `<form>` tag that has been around for 20+ years, and it can send the data to server without JS. Of course as you will see in this video Remix augmented the `<Form>` tag for 21 century, but it can also function like it’s 1999. 

### Setup

So now that you have general idea what Remix is, let’s get our feet wet and let me show you how I remade the site from Directus and Next series in Remix.

Installation of Remix was breeze, I managed to get most of the functionality that we have in that app in just four to five hours. 

Keep in mind that I already had a lot of code that I could reuse from that app, and I skipped the mini cart and sign in functionality because i didn’t wanna learn another library for authentication. Since we used Next Auth in Directus Next series, and it can only be used with Next.js. 

However there is a library called [Remix Auth](https://github.com/sergiodxa/remix-auth) that you can use for that, and it seems pretty similar to Next Auth. So if you need authentication in your app you can check that out. 

The only thing I installed when remaking this app was Tailwind, so that I can have the same design that we had in DIrectus Next app. 

To install Tailwind you can just follow a quick guide on [Tailwinds website](https://tailwindcss.com/docs/guides/remix), and you’ll be good to go in no time.

When you open the app in your editor you will see a folder structure that is similar to Next.js except all the important stuff is in the `app` folder. And in `app` folder you only have routes directory. Which is very similar to the pages directory in Next.js, because just like Next - Remix uses page based routing. So whatever you add in there will automatically get its own route. 

This is the folder structure that I ended up with when the app was finished.

Styles directory is generated by Tailwind, and all the other folders are pretty much just copy and paste from the Next.js site, except I needed to save them into `app` folder as opposed to the root folder of Next.js app. 

If you wanna see all the code there will be a link in the description to the [GitHub repo](https://github.com/ivandoric/remix-directus) that you can browse through.

### Products, categories, and Filters.

First thing I wanted to do was setup the homepage. And on the homepage we have few interesting functionalities. One is getting all of our products from Directus, getting all the categories for the Filter and also filtering functionality itself.

Homepage is of course `index.jsx` file in the `routes` folder. Now, my Next app uses React Query to get the data and to filter it. However this is not the Remix way, because, remember Remix respects the Server/Client philosophy, so it would be nice to embrace that and get the data from the server instead from the client.

So I removed the React Query part of the code, and leaned in to the server. 

And this is not anything new, because Next.js does the similar thing with `getServerSideProps` just here it works a bit differently.

First you create `models` directory and in it I created a file called `index.server.js` here I added all of the getter functions for my data. 

And if you have been following my Directus Next series you can see that here I’m pretty much using the same functions for getting the data. And also the same GraphQL queries that I have been using on the Directus Next site. 

You can return whatever you need from those functions. I’m exporting functions for getting all of my products, categories, and a function for getting my filtered products that accepts an array of category IDs to filter those products.

Now back in `index.jsx` you need to export a `loader` function that will talk to the server and get your actual data. 

For categories it’s easy, you can just use `useLoderData` Remix hook and get it from there. Products are a bit more complicated because we need to filter them. 

So for that I’m using the `useFetcher` Remix hook which will allow me to first of all display all the products. But when user selects a category it will send the category IDs to the loader function which will run a different different getter function to get my filtered data. 

Our fetcher is called products in this case, and the fetcher has a submit method on it. So whenever the state of the selected categories change it will submit it to the loader. 

And loader will receive a `get` request which we can parse, and then call the `getFilteredProducts` function with an array of IDs as a parameter to get the filtered products. 

This Workflow is very similar to the Directus Next app, except here all the data fetching is happening on the server and without the need for ReactQuery. 

And if we check our front page everything is working as expected.

### Meta

There is also a difference how Remix handles meta tags compared to Next.js. In Next you would import `Head` component, add it to the beginning of the layout on your page and then add the actual tags there, like `<title>` , `<description>` and whatever else you need. 

In Remix you would export `meta` function for every page, and that would overwrite all the default tags that you can define in `root.jsx`. `root.jsx` is similar to `_app.jsx` in Next.

Also you can add dynamic data to it, by passing in the `data` variable which will then have access to all the data that you get from the `loader` function on that page.

I’m doing that on the single product page to set the title of that page to be the name of the product.

### Dynamic routes

Now, to Link the product to the product page you first need to define that page. You can do that almost identically to Next.js, except you would use dollar sign notation for defining dynamic parts of your route instead of square brackets. 

In Next you would get the page by slug by writing `[slug].jsx` but in Remix that page would be called `$slug.jsx`.

Now, my case is a bit more complicated because I don’t just wanna display the name of product in the URL but I also wanna display a category. So I would have: `/products/product-category/product-name` . 

In Next and in Remix you could create a folder called products, and in it you would create another folder called `$category` or `[catgegory]` and in it you would add a file called `$slug.jsx` or `[slug].jsx` for Next.js. So this is almost the same in both frameworks. 

But, in Remix you could also just create a file with the name: `products.$category.$slug.jsx` and you would get the same thing, which is cool. So I decided to go with that for my single product page.

Also I suggest to read up about Nested Routing in Remix which is really cool. You can do that on this address. [https://remix.run/docs/en/v1/guides/routing](https://remix.run/docs/en/v1/guides/routing#what-is-nested-routing)

### Link

To link my products to the single product page, I used the `Link` component, which is also similar to the `Link` component in Next. Except in remix you don’t have `href` property but instead you use `to` property. And also you don’t need to wrap `Link` component around anchor tag like you need to do it Next.js.

You can see the link to my products in the `ProductCard.jsx` and you can see the difference between Next and Remix. It’s very similar for the most part. The only difference is the `href` property and the missing anchor tag.

### Header

In Next.js I added the Header component which holds the Logo of the shop and navigation in `_app.jsx` . As mentioned before Remix has a file called `root.jsx` that serves the same purpose. So we can add `Header` component that is visible throughout the site there.

### Sign up

And there is just one more thing that I wanna show you, and that is the `Form` component. Which I already talked a bit about at the beginning, and said how it embraces web standards and old school way of dealing with forms. 

On Sign up page you can register and create a new user in Directus. To do that in Next we used `useMutation` hook from React Query, and we would get the data from the form by creating `handleSubmit` function, for which we would prevent default functionality of the form and then send the data to the server from there. 

This is the usual React pattern.

But since Remix embraces the `form` we can do things a bit differently. So first of all I changed `form` to be `Form` with capital F. Fun fact here is that you could leave it as just `form` with lower case F, and it would also work, it would just reload the page on sending the data, because that is what forms do, and that is the reason we need to use `preventDefault` in the Next version. 

In Remix I just added the method of `post` to the form, and I want it to do an action that is defined on the page it is on. But you could also add an action that will get instructions from another page. 

Then you need to define the action by exporting `action` function to which you pass a `request` object. And then you can easily access the data from the form by using `formData.get` function. 

When the data is defined I just send it to the server with `createUser` function, which I defined in the `user.server.js` file in `models` folder. Function for sending the data is the same as in Next.js version of the site. 

Now I’m waiting for the response from the server, and if I get `create_users_item` to be equal to `null` I can return an error. Since I’m using Directus this means that the user already exists. 

If the user does not exist then I can just redirect the user to the thank you page after it’s created on Directus API. 

Now if we get an error we can get that information by using *`useActionData`* Remix hook. And then we can display an error in our layout like this.

### Conclusion

Of course there are a lot more things to cover about Remix but I cant do that in one video. This video is just for you to get a taste of what is possible in Remix and how it works.

My time with the framework was for the most part very enjoyable.

I think it’s an all around great framework that is just going to get better with time, and is a real competitor to Nextjs. And competition is going to be great for us developers.

If you wanna take a look at the code I used in this video you can check it out on Github.

In this video we are going to checkout Remix. I’ve been playing around with Remix for the last couple of days. This video is mostly going to be about that journey and how Remix compares to Next.js.

Let's Checkout Remix ... And Compare It To Next.js

We are also going to add user area page that will only be accessible to authenticated users.  NextAuth is going to make this pretty simple for us to implement as you will see. 

In this episode we are going to implement login functionality to our Next.js and Directus app using NextAuth package.

User Authentication With NextAuth

We are going to use special endpoint that Directus provides us, and send new user information using Next.js frontend. 

In this episode we are going to implement  signup functionality for our Directus and Next.js app.  You will see, this is very easy.

Video Tutorials For Curious Frontend Developers

Latest tutorials

Directus 9How To Create Multilevel Navigation In Directus 9 (NO CODE)

Frontend TipsLet's Checkout... AppWrite

Directus 9 + NextProtect Signup Form From Hackers

Frontend TipsLet's Checkout Remix ... And Compare It To Next.js

Directus 9 + NextUser Authentication With NextAuth

Directus 9 + NextUser Sign Up

Latest Courses

Directus 9 + Next

Making Websites With Next.js And Strapi

React 2020

Creating Svelte, Sapper and WordPress Website

Get in touch