Remix is a full stack web framework that focuses on web standards and the server/client model so that you can develop the features your users want and need without being bogged down in over-abstractions. When you get good with Remix, you actually get good at the foundations of web development.

remix

Kamil Khadeyev

The first thing you do is install Remix! In this course, you start with a barebones Remix set up. In many situations you will start with a [Remix stack](https://remix.run/docs/en/v1/pages/stacks) but this course starts from the beginning.

Installing Remix is easy though, so you will finish this lesson by being introduced to a core Remix feature: data loaders.

Remix loaders are functions that only run on the server so you are safe to connect to databases, make API calls, and anything else you’d expect to do on a server. The data you return from these functions will be received into your components through `useLoaderData` hooks. 

We’ll see how to return static data from a loader and display it in a component. Along the way, TypeScript will complain about data that is coming into your component so we will fix that as well.


Load and Display Static Data with Remix loaders

Most applications need data persisted to a database. A really great way to manage data is through an (Object-relational mapping) ORM so you aren’t stuck writing SQL queries when you want to be building websites. 

Prisma is a modern ORM that lets you get started with a database in just a couple steps. It supports TypeScript to which you will take advantage of.

In this lesson you will initialize Prisma in your application and model out what a `Post` will look like. You’ll set a few properties that Prisma will manage (e.g. id, createdAt) and a few that you will manage. Prisma also comes with a studio that you can run to create and manage data super easily when you don’t have other means to CRUD that data (we don’t yet!).

Install and Model Data with Prisma

Now that you have a database running, you need a way to connect to it in your application. This is where Prisma client joins the fray and really shines. 

With Remix, there is a little bit of set up that we have to do to ensure that we won’t be opening extra connections to the database through Prisma. Through this set up you’ll learn about another important pattern in Remix which are services. 
You’ll create a db.server.ts service that will manage setting up the Prisma client. The folks at Remix have us covered with this code snippet that safely sets the client up for you. 

After creating the client, we will create another service `post.server.ts` that will expose all of the functions that you can use throughout your application to retrieve data from the db. One great benefit of this pattern is that when consuming these services you don’t need to know about the implementation that is powering them. Just the api that is exposed, in this case a `Post` type and `getPosts` function.

FINALLY you’ll consume that function in the data loader at the root of your application to display posts from the database.

This sounds like a lot but you get this all done in under 5 minutes.

Retrieve and Display Data from the Database through Prisma and Remix Loaders

There are many ways to style an application. While styling isn’t a focus for this course, we don’t want the application to be unbearable to look at. 


TailwindCSS is how you will style this application. With it’s utility classes, Tailwind stays out of the way once you get it set up. The [Tailwind docs have a great tutorial](https://tailwindcss.com/docs/guides/remix) which you can follow to get to styling your application. You can also follow along in this tutorial.

Set up Tailwind and Create a Presentational Component in Remix

This is where things start to get fun, you’re adding data to your database!

 To do this, you’ll learn about Remix actions. A Remix action utilizes HTML elements to accept input from the user. When creating data, you’ll set the form to a method of `post`. The form needs a route to post to so you will need to set the `action` to the route that will handle the request. In our case it is the index route the form is in.

The Remix action itself accepts a request that you can pull the form field data you need off of it. From here you can update your database directly, because you’re on the server! In this case, you’ll create a function createPost that will utilize Prisma to create a record. Once this happens, we will redirect users back to the index page that they were on.

Add Data to your Database through Remix Actions and Prisma create

At this point, your form will accept any type of input that users desire. This isn't good, you need to add form validation. 

Form validation is another area that there are many ways to accomplish what you need. One great way to get easy form validation is through a library called Zod. Zod allows you to create a schema to parse your form input against. It will return form and field errors when input doesn’t match the rules that you supply.

With Zod in place, you’ll check form input in the action previously defined. If an error is found, you’ll return an object passing in the errors you find as well as the input that users submitted. This will be used to render error messages in the form and reset form state to what was submitted. This is easy to accomplish with Remix json helper that will also set the error message for you.

Along the way you will also see how easy it is to type this data.

Validate Form Data Through a Remix Action using Zod

You are at a place where you have an app that will persist data through a sqlite database. Sqlite is great for getting started but as you build out your application, you’ll want a database that can scale with your project. 

PlanetScale is the database that you are looking for. PlanetScale is a database as a service that powers a mysql database called Vitess. Vitess is what YouTube is ran on so safe to say it will scale to all your needs. 

Because you used Prisma to set up your database, switching to PlanetScale will be easy. You will create a PlanetScale project, sign in to the CLI, follow the Prisma Quickstart guide and learn about Database workflows with PlanetScale. Who would have thought it would be so easy to migrate your database service.

Connect a Remix Application to PlanetScale Through Prisma

Our application has achieved MVP status — Minimum Viable Product that is. This means it’s time to deploy.

For this application, you will use Vercel to deploy to as it’s just a few clicks away. Vercel integrates with GitHub so once you give it access you can connect your GitHub Project. Similarly, Vercel has a PlanetScale integration that will pull in all the necessary environment variables you will need to connect your production database to your deployed application. After setting your env variables you’ll have deployed a full fledged, working application with a production database.

From there, we will test out a feature to deployment workflow for you to get a feel for how deployments on Vercel work.

Deploy a Remix Application with Production Database to the Internet Through Vercel

In lesson 08, [Deploy a Remix Application](https://egghead.io/lessons/egghead-deploy-a-remix-application-with-production-database-to-the-internet-through-vercel), we said that the app was MVP status. This isn’t quite true for many applications. You will inevitably need users on your site to make it useful for your customers (or even for yourself).

To get started adding users, you will update Prisma with a user model and associate it to Posts. From there you’ll update your posts to display user information. You’ll see how to migrate a Prisma schema in PlanetScale as you deploy these changes.

One nice tid bit you will pick up along the way is a TypeScript 4.5 feature, Awaited. Awaited will unwrap a promise type for you so that you don’t have to do it yourself which is a big relief.

Create and Utilize a User Model with Prisma in Remix

To further prep for implementing user sign up and log in, you will create a sign up and log in page. To do this, there are a few development workflows that you’ll be introduced to. You will create a reusable button component from the previous button that was created to use inside the Nav header. 

To actually reuse the buttons, you’ll need to create a nav. One thing that you shouldn’t do is apply a nav to every page you create. This is why Remix has layout routes and in this case because it’s an application layout, you will want a pathless — pathless meaning it won’t show up in the url — layout route. This is denoted with two underscores in the layout file, for an app that is `__app`.

Along the way you will be introduced to an awesome component pattern that implements an `as` prop. What this will do is let you define your button AS a link so that you can use actual HTML links instead of buttons for accessibility reasons.

Create and Use a Layout with Remix Pathless Layout Routes

You need to accept input from a user to sign them up to your application. Creating a user in the database is a straightforward Prisma.create function call. 

The tricky part here is that we want to ensure bad data is not inputed into the form. We’ve done form validation before but this lesson will show you a more complex version of it.   Among the validation that is applied, you will hash the password that’s given to us before saving it to the database as well as check the database for existing users when a sign up is attempted.

Validate User Sign Up Data in Remix and Hash a Password

Here comes the bulk of complexity when dealing with authentication. You need to handle verifying that a user account exists in the database and when it passes somehow referencing it throughout your application.

A great way to do this is through Session Storage. You can implement session storage with HTTP cookies (which is what you will do here) or with a database. You’ll implement functions `commitSession`, `destroySession`, and `getSession` but luckily the Remix docs will give you a head start here.

Along with session storage, you will need to implement an authentication strategy. Again there are a few ways you can do this whether that’s magic email, 3rd party auth like GitHub or Twitter, or email / password. Because you are already accepting email / password, that is what you will do!

Implement User Login in Remix with a Form Strategy and Session Storage

Currently the only way to know if you are logged in is if you check the cookie that is set in the browser. This isn’t super user friendly. You want to add a visual cue as well as a log out button to the nav.   To accomplish this, you can check if a user exists with the isAuthenticated function that was created in the auth service. If there is a user you will display their email, loaded up from the isAuthenticated check, as well as a log out button.

The log out button will post to a resource route. This route will log out the user and redirect them to the log in page. 

Finally, you will lock up the index page so only logged in users can see and add posts.

Implement Log out Functionality and Only Allow Logged in Users to See Posts

Finally, you want to associate users to the posts that they make. To do this you will grab the user data from authenticator.isAuthenticated API to pass to the post creation. This data does not need to be validated because it’s coming from the session storage which has already been validated.

Add User Data to a Post Creation in Remix

Learn Remix by building a full-featured blog with a database, authentication, CRUD operations, user roles, and more!

Up and Running with Remix

Learn Remix by Building a Social Media Platform with TypeScript and Prisma

https://app.egghead.io/api/v1/lessons/remix-load-and-display-static-data-with-remix-loaders/subtitles

Instructor: [0:00] The first thing you want to do is initialize your remix project with the npx create-remix command, followed by the name of your project.

[0:10] After you execute the command, you will be asked to enter project information. Information like the template your app is going to use, where to deploy, whether or not to run npm install.

[0:29] Then, choose your preferred language, TypeScript or JavaScript. Now that you have Remix installed, you'll open up your project in VS Code.

[0:45] You can run the Remix development server with the command npm run dev in your console. Now that your server is running, go ahead and open your site in the browser at localhost:3000.

[1:03] Hop back into VS Code and you can get started on creating some of your own content. Open the index.tsx file inside of the app/routes folder. In this file, you should see the code for a default Remix project.

[1:20] In this next step, you're going to get into the meat of writing a Remix application. You'll kick things off by creating a LoaderFunction above the index component. You'll export const loader with the type of LoaderFunction returning an array with an object of title and body.

[1:45] Remix will run the LoaderFunction on the server, and any code executed here will be removed from the client-side bundle. You are returning a static array of post now, but in the future, the LoaderFunction is where you will connect to your database and make any other API calls you may need.

[2:06] Now, down in your component, you can call the useLoaderData hook to retrieve posts from your LoaderFunction that you just created. Inside of the JSX, delete the template code, and create a list item for each post in the post array.

[2:29] You'll type post.map, taking the post. For each post returning an LI where the key is post.title. Then a div with an h2 for the post title and a paragraph tag for the post body. Head over to your browser and you will see the post being rendered from the LoaderFunction.

[2:53] We're not quite done yet. In your code, notice the TypeScript error coming from the map function. TypeScript has no way of knowing what type your useLoaderData hook is returning. Squash that error by creating a post type.

[3:09] Create a type of post with an attribute title, which is a string and body, which is also a string. Now, pass that type to the useLoaderData hook. You just told TypeScript what type of data the useLoaderData hook is returning.

[3:29] When you hover the post, you can see its type is post. To review what you've learned, first, you created your application with npx create-remix. Next, you modified the route route file in your app folder by creating a LoaderFunction that returns static posts.

[3:52] Then, you rendered the posts inside of your index component, and created a post type to pass to your useLoaderData hook to tell TypeScript and VS Code what type of data is being loaded.

https://app.egghead.io/api/v1/lessons/remix-load-and-display-static-data-with-remix-loaders/transcript

https://app.egghead.io/api/v1/lessons/remix-install-and-model-data-with-prisma/subtitles

Instructor: [0:00] It's time to add a database to your project. Prisma is one of the leading object-relational mapping tools or O/RMs for typescript and node.js.

[0:11] Over in your terminal, install the Prisma CLI tool with the command npm i prisma --save-dev. With the CLI installed, you can initialize Prisma with the command npx prisma init passing the data source provider flag with the value of SQLite.

[0:36] SQLite can speed up your development process by avoiding installation of heavy database software, such as Postgres and MySQL. SQLite uses a single file to store your database information. Later in the course, you will replace SQLite with a MySQL database. By running the init command, you created a Prisma folder in your project.

[1:04] When you run the OS Prisma command in your terminal, you will see a schema.prisma file. This file tells Prisma everything it needs to know about your data model. Go ahead and open that file in your editor.

[1:19] By default, Prisma defines the type of client your app will use and the data source provider information. Here is where things get fun. You should add a Post model to your schema. The first attribute you will add is an ID. It's going to be a string with a default of UUID.

[1:43] UUIDs are nice because they are harder to guess compared to auto incrementing number IDs. The next two fields createdAt and updatedAt, will be managed by Prisma as well. When you create a post, createdAt will be set to the current time.

[2:02] Likewise, Prisma will update the value of updatedAt whenever you modify a post. These fields are standard to almost all of the models you will create. Now it's time to add your custom fields. You'll add an optional title of type string.

[2:24] The question mark at the end of string signifies the fields optionality. Your post will need more than just a title. Add a required body field of type string. While you've defined your schema, you haven't told Prisma about this new model yet. Head back over to your terminal and run the command npx prisma db push.

[2:53] This created a SQLite dev.db file in your Prisma folder. It's finally time to add data to your database. To do this, you will use a tool called Prisma Studio. In your terminal, type npx prisma studio, and open the URL at localhost:5555.

[3:27] Here, you can see the post model you've created. Go ahead and click on Posts, then Add Record. You can type something like, "Persistence yay" into the body field. Now, add your first DB post to the title and save again.

[3:48] Time to celebrate because you just added your first post to your Prisma database. In review, you added the Prisma's CLI tool to your devDependencies. You ran the npx prisma init command with SQLite as your data source provider.

[4:04] Next, you opened up the schema.prisma file and added a post model to it. The post type has five fields. These fields being ID, createdAt, updatedAt, title, and body. Three of them managed by Prisma, and two of your own.

[4:22] Finally, you started Prisma Studio with npx prisma studio and opened it up in the browser, where you were able to add your own content to your database.

https://app.egghead.io/api/v1/lessons/remix-install-and-model-data-with-prisma/transcript

https://app.egghead.io/api/v1/lessons/remix-retrieve-and-display-data-from-the-database-through-prisma-and-remix-loaders/subtitles

Instructor: [0:00] As always, you will start off by installing some npm packages. In your terminal, type npm i @prisma/client. Head over to your project in VS Code, create a folder called services. This folder will store any code that interacts with your database. Inside of services, you are going to create a file called db.server.ts.

[0:42] If you take a look at the official Remix tutorial, they show you how to manage a database connection with Prisma and Remix. Remix will reload your source files every time you make a change. This causes a potential problem in development, since you don't want to create a new connection to the database every time your source files change.

[1:05] If the environment is not production and the global DB variable hasn't been set, you create a new connection and assign it to the global DB variable. You will then sign the connection to the variable you will reference in the rest of your app.

[1:21] When the source files change, this global DB variable will still be there. Now that you've copy pasted the DB code, go and create a post.server file. First things first, you can import the DB from the path ~/services/db.server.ts.

[1:54] Oops, looks like there's an error because services is in the wrong folder. To correct this, drag services into your app folder. Export the type post from Prisma Client. This way, you can keep the post type in the same place as your post database access functions.

[2:15] Users of this file won't have to know that the post type comes from Prisma. Next, you'll export a function called getPost. You will start super simple and return all the posts in the database. Time to put your getPost function to work. Head on over to your route/index file. There is no need to define your own post type. Prisma creates a type that will keep track of all of the attributes on the model for you.

[3:01] GetPost is a Prisma promise. We're going to need to await it. Along with awaiting it, we'll need to make our LoaderFunction async. Notice the new LoaderData type. This type encapsulates the post.

[3:36] If you need to add more data to the loader, the type signature won't have to change. Instead of returning an array, you're going to return Remix's helper JSON function parsing in the data. The JSON function will set the appropriate headers to indicate a JSON response.

[3:56] Since the type of the LoaderFunction has changed, the useLoaderData hook needs to be updated as well. Now, you have to destructure posts out of the response. That's it. Head over to your browser at localhost:3000, and there's the post from your database.

[4:19] In review, you installed the Prisma Client with npm install @prisma/client. Next, you instantiated the Prisma Client while making sure extra database connections wouldn't be created in development. You used Prisma's findMany function to read all the posts in the database. Lastly, you called the getPost function inside of a loader and returned JSON to your index component.

https://app.egghead.io/api/v1/lessons/remix-retrieve-and-display-data-from-the-database-through-prisma-and-remix-loaders/transcript

https://app.egghead.io/api/v1/lessons/remix-set-up-tailwind-and-create-a-presentational-component-in-remix/subtitles

Instructor: [0:00] To style this project, you will be using Tailwind. Tailwind gives you access to hundreds of utility classes that enable you to write consistent CSS across your app.

[0:11] To install Tailwind in Remix, you will use the guide at tailwindcss.com. To get started, head to your terminal and let's install some dependencies. You will need to npm install tailwindcss, post CSS, Autoprefixer and Concurrently.

[0:39] Tailwind has a command line initialization utility you can use to get started. Type npx tailwindcss css init -p. This command created two files, tailwind.config.js and postcss.config.js.

[1:01] Next, you will need to open tailwind.config.js in your editor. Here, Tailwind needs to know what files to watch in order to generate the correct CSS classes for you.

[1:14] You can add as many paths to this array as you want. The path that is pasted here will match any JS, JSX, TS, or TSX files in the app folder. Now that the configuration is all set, you need to add npm scripts to run Tailwind in Dev and during the build.

[1:38] The first script will watch the file system and output any styles found in app/styles/app.css. The build CSS script is similar. The difference being it needs to only run once and won't watch your file system.

[1:55] Now that you have commands to build your CSS, concurrently can be used to run the dev CSS and Remix Dev commands in parallel. Finally, the build command is modified to run the build CSS command in addition to Remix build.

[2:12] The last addition you need to make is to add the styles/app.css file. Go ahead and create a Styles folder. Inside of that folder, create an app.css file. You can paste in the default Tailwind directives for each of the Tailwind layers.

[2:29] After all that rigmarole, Tailwind is set up. Head over to your routes index file and you can reference the stylesheet Tailwind generates. In Remix, exporting a links function from a route page allows you to control the different links that are referenced in the HTML header attribute on the page.

[2:52] Export a function called links, then return an array with an object where the route is stylesheet and the href is styles. Looks like an old build is running, so I'm going to kill it and restart to get Tailwind running.

[3:16] Look over at the generated app.css file, and you can see the default CSS. By default, Tailwind will create these reset styles. They will make a web app look more consistent across different kinds of browsers.

[3:31] Head over to the browser to remember what the app looked like before you add a Tailwind. To prove Tailwind is working, apply a couple of classes to the H1 on this page. Head over to the browser and you can see styles are working. It's time to create a simple post component. Create a component's directory.

[3:58] This directory is where all your presentational components will live. Create another folder called post, then create a post.tsx file where the component will live. Since it's annoying to import components/post/post, create an index.tsx file, so that you can just import /components/post.

[4:27] Inside of the post file, create a function called Post. It's going to take a title and children. Export the post component from the post/index file. Head back to your routes index file and we're going to import the post component. The post component is conflicting with our post type, so alias the component as post component.

[5:24] Head over to the browser to make sure that the component is rendering correctly. TypeScript is complaining that we haven't declared a type for a component props.

[5:48] Create a types.ts file and you can define a PropsType. Props will take an optional title of type string or null. Component props without ref is a utility type that React provides. This provides types for all of the possible attributes for the HTML element you pass in as a generic.

[6:13] It looks like there's a mistake with the prop names. The prop title is already defined in component props without ref. To avoid the name collision, rename the component prop to header. It's time to add some styles to our component.

[6:44] First, you'll add some styles for the wrapper div to give all of the text inside some room to breathe. Second, you'll add some header styles to make the title stand out. Lastly, add some styles to the body. This lightens the text color, so it doesn't overshadow the header.

[7:18] Now, if you take a look in the browser, you can see our fancy new post component. Let's review what you've learned. You installed Tailwind CSS, PostCSS, Autoprefixer and Concurrently. Next, you use the Tailwind CSS CLI to generate configuration files.

[7:37] You edited the Tailwind config to add the app files to the Tailwind's watch path. Lastly, you created a new post component that takes a header in children.

https://app.egghead.io/api/v1/lessons/remix-set-up-tailwind-and-create-a-presentational-component-in-remix/transcript

https://app.egghead.io/api/v1/lessons/remix-add-data-to-your-database-through-remix-actions-and-prisma-create/subtitles

Instructor: [0:00] It's time to create a post form. You are going to use this form to fill out post information, and make an HTTP post request to the index route.

[0:11] Remix uses action functions to handle post, put, and delete requests. Inside of the Action function is where you will make a call to your database. The first thing you need to do is head over to the components folder and create a new folder called postForm.

[0:35] Inside of that folder, create a file called postform.tsx. Now, you'll create a function that will return your form JSX. At the bottom of the file, you'll export default postFormComponent. Before we go any further, split the screen so you can see the changes as you make them.

[1:05] Here, I'm going to paste in the styled form component. Next, you can create an index.tsx file and export the postForm from postForm. To get your form rendering, pop over to the routes index file, import the component, and render it just above the posts list.

[1:28] When you save, you can see what the post form looks like. Back in the form component, you can see that the form has a flex and flex column classes. Go ahead and add a gap attribute to let flex manage the space between fields.

[1:50] This lets you remove all the margin bottom classes. Looking at the contents of the form, you have an input field for the title attribute, a text area for the post body, and a submit button at the bottom.

[2:09] For now, this component should take props with the type of component props without ref, passing in a string of form. Instead of passing the method statically, move that attribute up to the component props, and give the prop a default of post.

[2:36] We will pass the method directly and then spread the rest of the props on to the form component. Head back over to the index route. Here, you will add an action prop to the form.

[2:49] You don't want to define this prop inside the component because it is dependent on the page context it is rendered in. Since you are calling the form inside of an index action, Remix uses this to determine that you are posting to an index route and not some parent layout component.

[3:10] Next, head up to the top of the file where you will define an Action function. You can export const action Action function. This function will need to be async. Inside of the params, pluck off the request.

[3:31] When an action is submitted, Remix adds an async FormData function to the request. Const form = await request.FormData. Each field of your postForm component is added to this form. Const raw title = form.get passing in title.

[3:56] Const raw body = form.get passing in body. Now that you have input for a post, it's time to create a call to the database. You'll make a call to an async CreatePost function, passing in the raw title and raw body.

[4:15] This function doesn't exist yet, so you'll go create it in post.server.ts. There is one more thing to do in this Action though. That is to return a redirect back to the index route. To create your DB function, head over to post.server.

[4:34] Here, go export a CreatePost function. The arguments will take an object with a title and body. You can use the pickUtility type to create a type from the object being passed in. This lets you pass in the post type from Prisma and reference the title and body attributes in the type.

[5:00] You can return db.post.create. As you can see from the TypeScript documentation, this function expects an object with an attribute of data, and then the title and body attributes to create the post. Now that this functionality is in place, you can head to the browser and create post with your form.

[5:37] To review, you added a postForm component that takes a method in action prop. Then, you exported an action from the index route. Finally, you received the post input from the formData and created the post with Prisma.

https://app.egghead.io/api/v1/lessons/remix-add-data-to-your-database-through-remix-actions-and-prisma-create/transcript

https://app.egghead.io/api/v1/lessons/remix-validate-form-data-through-a-remix-action-using-zod/subtitles

Ian Jones: [0:00] Right now, if you press the submit button without filling out the inputs, an empty post will be created. You want the user to at least fill out the body of a post. To accomplish this, you will need to add data validation in your action.

[0:18] As we all know, when you encounter a problem, the first thing you should do is install an npm package. Head over to the terminal and run npm install zod. Zod is a validation library where you can define a schema for your input and validate that input against the rules you've written. Zod works great with TypeScript, and has many useful helper functions.

[0:48] Head over to your Services folder and create a validations.ts file. In the validations file, import Z from Zod. It's time to create the createPost schema. CreatePost will be an object. This object will have a key of title, and the title will be optional.

[1:22] Next, as you might have guessed, the object will have a body of type string, where the minimum length is greater than or equal to 1.

[1:36] Back in your index route, you can call const result = createPost.safeParse. Now, you can pass in raw title and raw body. If you use the parse function, Zod will throw an error, if the input doesn't match the schema. You want to be able to handle the error yourself.

[2:03] SafeParse will return an object with the attribute success error and data to result that success is false, then there was an error in parsing the data. Here, you can return an object with the key of error, then parse result.error.flattened.

[2:23] You also want to add the form fields to return state of the form to the user. To show you what the Response will look like, head up above the Action function and create an Action data type. The error will have a form error attribute which will be an array of strings.

[3:02] Then there will be a field errors attribute, which is an object with a key of title. Title will be an array of strings and then a key of body. Which will also be an array of strings. Next, we have fields, which are title and body.

[3:22] All of the attributes with the question mark are optional. Instead of using raw title, you can use result.data.title. Likewise with raw body, you're not using the reference to the post, so you can just remove it.

[3:46] One last thing before you move on, wrap this object with a call to the JSON helper function from Remix. In the second param, add a status of 400. Open up your dev console in the browser and you can see this validation code in action.

[4:10] When you click Create Post with an empty body, you can see Remix is returning an error with a status of 400. You are returning JSON back from the Action. To get a reference to the Action Response, call useActionData passing in the action data type.

[4:33] Now, you can pass error and fields down into the post form component. The first thing you should do, is add error and fields to the post form type. At this point, the type can live in its own file. Create a type of props and paste in the action data type.

[5:05] Props will be a union type of the action data type and the component props without ref type. Back in the component file, import type Props from types. There, you can pull off error and fields from the props. Next, if there is a field error, you should display under the input in red.

[5:42] Check if the fielderror.title exists. If it does, render a P tag with red text. Now, you can do the same for the body field error and the top-level form error. Head over to your browser and let's see this working.

[6:10] When you create a post with an empty form, you get the error displayed with "String must contain at least one character." To prove things are still working, add a post without a title. Notice what happens when you type into the title field and hit "Submit".

[6:34] The form values disappear. The action is already passing back the form fields it received. All you need to do, is add the form fields to the default value of your input and text area. Let's try it again. When you type into the title field and hit submit, the form keeps its state, but the extra error information is displayed.

[7:02] It looks like TypeScript is upset. You have to make the error and fields coming from Action data undefined because these values aren't set until the user submits the form. Let's review what you've learned. You installed Zod and created a Create Post Schema to parse the data coming into the Action's function.

[7:34] If somebody sends a request that didn't successfully parse, you returned the error in the form fields. Lastly, you added the errors to the post form and passed any values the user typed in back to the form.

https://app.egghead.io/api/v1/lessons/remix-validate-form-data-through-a-remix-action-using-zod/transcript

https://app.egghead.io/api/v1/lessons/remix-connect-a-remix-application-to-planetscale-through-prisma/subtitles

Ian Jones: [0:00] Here's where things get really fun. PlanetScale is a database as a service that wraps a MySQL database called Vitess. Vitess is the database that runs YouTube. When you use PlanetScale, you're giving yourself a lot of room to grow.

[0:14] PlanetScale is focused a lot on their developer experience, which is the reason it's being used for this application. It truly can take you from side project to production. They have a free tier, so it makes it a great choice for a side project.

[0:28] Head on over to their sign-up page to get started. Now that you have an account, create your first PlanetScale database. I'll name it after, Remix Social.

[0:39] The central piece to the PlanetScale workflow is the CLI they have created. You can see the command for creating a database from the CLI here.

[0:49] If you haven't already installed the PlanetScale CLI, check out the instructions on their GitHub page, and pick the instructions that suits your operating system.

[1:00] Head over to the terminal and log in there. You can type the command pscale auth login. It will open a web browser and authenticate with your account.

[1:10] To prove that you are logged in, you can list all the databases with pscale db list. You can look at the Prisma quickstart docs to get a sense for what you need to do to wire up Prisma to PlanetScale.

[1:26] Since Prisma is an ORM, it has abstracted the details of what kind of database you are using. This makes it easy to change your code and start using a different database.

[1:38] Head over to the schema.prisma file, and you'll see just how easy it is to switch to PlanetScale.

[1:45] This project has been using SQLite up until now. It has served its purpose in getting you going. The difference here is that now you're using MySQL as a provider. Notice you have to set the preview flag of referential integrity. This is required to get things going.

[2:04] Now that you have Prisma configured, head over to your .env file and update the database URL. This URL will point Prisma to the correct PlanetScale database and port to connect to. You will use the pscale command to open up port 3309 to talk with the PlanetScale service.

[2:27] Stepping back a little, PlanetScale uses a git-like system to track changes in the database. The main branch is what your live system will use. You can branch off of main and make updates to your branch.

[2:43] When you created deploy request, you can see a diff of changes you are about to make to the main branch.

[2:50] With all that said, create a new branch called initial setup. Now that you have a new branch, use pscale connect to open a new connection to your database. This is the connection to PlanetScale that the Prisma Client will use to access the database.

[3:09] In a new terminal, run the command npx prisma db push. You've used this command before with your SQLite database. Prisma is doing the same thing now, but it is pushing your schema up to a MySQL Database in the cloud.

[3:29] You can open up Prisma Studio and see the database. Prisma Studio is pointed to the PlanetScale connection. Since you haven't created any post yet, it's an empty database. Just like before, you can add data through this UI.

[3:47] Back in your terminal, start up the development server. You can see the post that you created in Prisma Studio. You can also create a post through the application UI. There is your second post.

[4:03] Awesome. The last thing to do, is to merge the initial setup database branch into the main branch. Before you can merge any changes, you have to promote the main branch to production.

[4:22] Then, head over to branches then initial setup. Now, click Create Deploy Request. This is like creating a pull request on GitHub. You can leave comments here and interact with your team around this database change.

[4:46] You can also see the Schema Changes tab. This will show you the diff of what's changed. You've only made editions, so everything is green. Go ahead and click Deploy Changes. Now, you can delete the initial setup branch.

[5:06] Back in your terminal, you can switch to the main branch and restart the server. You will notice that the data didn't carry over between branches. This process is a nice way to test out changes to the database.

[5:27] In review, you created a PlanetScale account. You downloaded the pscale CLI tool, and you created a new PlanetScale database and connected to it.

[5:39] You updated the Prisma schema as well as the database URL. Then you ran the CLI command npx prisma db push, which you've run before. Finally, you created a deploy request and merged it and then reconnected to the main branch.

https://app.egghead.io/api/v1/lessons/remix-connect-a-remix-application-to-planetscale-through-prisma/transcript

https://app.egghead.io/api/v1/lessons/remix-deploy-a-remix-application-with-production-database-to-the-internet-through-vercel/subtitles

Instructor: [0:00] Now you have a minimum set of features on your app. It's time to deploy to production. There are many different platforms you can choose from, but I have used Vercel in the past. It has always fit my needs. All the lessons in this course are in this GitHub repository. You will want to deploy only the Remix Social folder. Head over to Vercel and create an account. Go ahead and create a new project. This is where you will link your Vercel project to a GitHub repository. I have to update my GitHub permissions to allow Vercel to import Remix Social. Here, you can update the project name to Remix Social. Vercel wasn't able to detect that this was a Remix project, so you can select "Remix" in the drop-down menu. You need to edit the root path of your project to point to the Remix Social folder. This initial Deploy will break because Prisma requires a database URL to be set. You can fix this by adding the PlanetScale integration to your project. Over in Settings, then Integrations, you can click the Marketplace button. Go ahead and search for PlanetScale and add the integration. This integration will connect Vercel to one of your PlanetScale databases. It will generate all the necessary environment variables to connect to the production PlanetScale database branch. Head back over to your Vercel project settings. You need to add an environment variable called DATABASE_URL. You can remember that this variable is in our local infile while in development. You can use the value in this PlanetScale-Prisma database variable. Head up and create a DATABASE_URL environment variable and set the variable to be available in production and preview environments. When you head back over to your deployed application, you can still see that the application is in a broken state. Even though you updated the environment variables, the application hasn't been redeployed with this new configuration. You can head over to Deployments and redeploy the code with the new .env variables. With the magic of editing, it's deployed. Let's visit and see our application. Now, everything's working. You just deployed a fully functioning application with a production database to the Internet. It has never been easier to build web applications than it is today. Head back to your code, and you can make a small change to get a feel for what the development flow looks like. Add a simple to the index route. Create a branch and push it up to GitHub. It's a good idea to take a screenshot of the UI change you've made so your team can easily see what changed. Next, I like to add a GIF to my pull request to spice it up. You can see that Vercel automatically added a preview deployment to this pull request. This is a nice way for your team to look at the changes you've made without having to pull the code down. Merge the branch and head over to Vercel. You can see that a Deploy to production has automatically been kicked off. Your application has been deployed. You can see that the has been added to the page. To review, you signed up for a Vercel account. Next, you linked your GitHub repository and added an integration for PlanetScale. The PlanetScale integration added a bunch of environment variables, which you used to create your database URL environment variable. Then, you made a simple change and merged it into the main branch on GitHub to get a feel for the development

https://app.egghead.io/api/v1/lessons/remix-deploy-a-remix-application-with-production-database-to-the-internet-through-vercel/transcript

https://app.egghead.io/api/v1/lessons/remix-create-and-utilize-a-user-model-with-prisma-in-remix/subtitles

Instructor: [0:00] The next part in your application building journey is to add authentication. Authentication is a big piece of almost every application you see on the web today.

[0:12] I want to take you through form authentication where a user signs up with a username and password. The first step is to add a user model to Prisma into your database. A user row will be created whenever someone signs up for an account.

[0:28] Go ahead and create a new PlanetScale branch called User.

[0:37] In another tab, you can connect the branch you just created. With Pscale connect, remake social, user passing in the port. Now, you can create a Git branch. Make sure to pull master before you create a new branch to get the latest changes.

[0:56] It's a good idea to always branch both your database and your code. This allows you to keep track of changes over time, and document step-by-step how your code changes.

[1:07] It is time to update your Prisma schema. As you can see, you have an ID created at and updated fields, all of which are managed by Prisma. There's a name that's optional and email that's required, and this is unique.

[1:24] This is what a user will use to log in to their account. There's a hashed password and a roll of default of user. Users will have many posts. This connection is important.

[1:38] Eventually, users will be able to follow each other to view one another's posts. You have to be able to associate post with a user. Prisma is telling you that this is an error because it knows that the post doesn't have any reference to the user model yet.

[1:55] Let's add the reference. Now, the post has an author ID that points to a user row. When you reference a post, you will be able to query the author along with the post and access the author via post.author.

[2:11] Let's go push our changes up to PlanetScale. Like always, run npx prisma db push.

[2:22] Now, you can add users to the database, open up Prisma Studio, and you can create a user with a post.

[2:36] There you go. Now, you have a user. Obviously, this password isn't hashed. When you add the signup process, you will hash the password before you create the user. Over in the post table, you can add a post and reference it to the user.

[2:52] All ready. Let's head back to the terminal and restart the development server. You can see here, you have Ian's first post, but none of the user information is being displayed. Let's add the author name to this post. Add the author name to the props and you can display the author named conditionally in a paragraph tag.

[3:29] Next, you can add the author name prop to your types as an optional string. It's time to add the author to our getPost call in post.server. It looks like Create Post is complaining because the author ID is required now.

[3:51] Add an author ID to fix the issue.

[3:59] For the getPost call, you can add include users. You don't want to include the hashed password to the user. You can pass a Select-Object and grab the email and ID.

[4:13] For Prisma, include is additive. It will return all attributes on the post. Then any attributes you selected on the user. Select is the opposite. You have to explicitly select all the attributes you want Prisma to return.

[4:31] Head over to the Index Route. Now you can add post.author.email as the author name prop to the post component. TypeScript will complain about this, but when you head over to the browser, you can see the email field being displayed under the post.

[4:48] It's time to make TypeScript happy. Create Post needs an author ID. You can pass a non-existent ID for now and we'll fix it in the future. To fix the loader data type, you can use the return type from getPost to accomplish this.

[5:08] You will notice that the post type that is returned is wrapped in a Prisma Promise. You can use this awaited TypeScript utility type to access the type that is being wrapped by the Promise. I had to Google around a bit to find the solution.

[5:25] Luckily, Awaited is a new-utility type added in TypeScript 4.5 that solves this exact problem. Previously, you had to add a custom type to your project to unwrap a premise type.

[5:40] The other benefit of this approach is that now you can change the get_post() function without worrying about TypeScript being upset in the future. You are all finished with the code changes.

[5:53] I opened up a deploy request for the user branch on PlanetScale and ran into some errors. There's an error merging the post table. When you add a column to a table, you have to give a row, a default value.

[6:08] To resolve this error, you can merge this deploy request and make the author ID on the Post Table, default to null. Back to the schema file, you can add a question mark to the author and author ID attributes on the post.

[6:24] With these changes in place, push them up to PlanetScale with npx prisma db push. Now on PlanetScale, you can open up another deploy request and make the author ID default to null.

[6:47] To review, you added the user model. This model has basic user information like name and email. A user has many posts on the post model. You make the author optional. Next, you updated the get_post() function.

[7:05] You pass then Includes-block to add the author email address and ID to the post. Then, down in the post component, you pass the author name.

[7:17] Inside of the index route, you pass the author email to the author name prop. Finally, you fixed the TypeScript error by using some of TypeScripts utility types like return type and awaited.

https://app.egghead.io/api/v1/lessons/remix-create-and-utilize-a-user-model-with-prisma-in-remix/transcript

https://app.egghead.io/api/v1/lessons/remix-create-and-use-a-layout-with-remix-pathless-layout-routes/subtitles

Instructor: [0:00] You are going to build UI components that are required for authentication, components like UserForms, a reusable button, and a nav component. You already have a button in the POST form, so you can extract it into its own component to use elsewhere. Copy the JSX and move it over to a button component file. You can remove the submit prop from the button because not all buttons will be in a form. You also don't want to hard-code the text of the button because each button will have its own children. Now, create a types file and export the type called props. Props will be a component without ref passing in any. Just like all the other components, you can add an index.tsx file and export the button from there. Now, you can go back to the POST form and use the button that you just created. You will notice that the type prop is on the button. The button isn't passing along any other props explicitly. Let's fix that. Here, you want to make sure that you pass the rest of the props to the button. This will allow the user of your button component to pass any props to the button. When you inspect the button, you can see its type is submit. Another case you need to solve for, what if someone wants to add a className? Currently, they will override all of the default classes. You can use a package called classnames to resolve this issue. I have enjoyed the utilities that classnames provides in the past. It will help you avoid applying undefined as a class and has some other helpful utilities we won't be going over. Back in your code, you can import cx from classnames. Go ahead and pass the Tailwind classes as the first argument and classname as the second. If the user defines a className prop, classnames will add that to the class string, but if the user doesn't, you won't have to worry about an undefined class being added to your button. Back in your POST form, you can add something like a border to the button, and a class will be applied. Now that you've extracted a button to use in the application, it's time to create the signup page. Remix uses file system routing, so any file created in the Routes folder will be added to a path in your application. I'll paste in the signup page code, and you can see it's a simple page with an h1 and a UserForm component. Head on over to the Components folder, and you can create the UserForm. The UserForm has a lot in common with the POST form. You can see that it takes an error and field prop. These will be exactly the same as you saw in POST form except the fields and field errors will be an email and a password. The first difference you'll notice is the useTransition() hook. useTransition() is a hook from Remix that provides the state of the form. The state can be one of three things, idle, submitting, or loading. The form starts in the idle state. When you click Submit, it transitions to submitting. Finally, if you are transitioning to another page that loads data, the form will be in the loading state while this is happening. You will also notice that there is a capital-F form on the page. This is required to get useTransition() to work. You will see that the button text changes based on the transition state. The button will also be disabled if the state is not idle. Everything else in this form is something you've seen before. There's an email and password field. They both conditionally render an error if it is passed through props. You can add the types. These will look very familiar. You have error and fields, which are both similar to the POST form, but now, you also have form props, which are just generic form element props. Next, export the component from the components index file, and when you save, you'll see the form render on the signup page. It looks like there was an error importing the UserForm component. When you fix that, the UserForm will show up. Now, you can use the same component for the login page. When you navigate to login, you can see the same form but with a different h1. Now that the authentication pages are set up, it's time to add a header to the application. You don't want to have to add a nav header to every page in your application. This would get tedious and time consuming. Remix has a feature called Layout Routes that lets you nest routes inside of one another. You don't want to add any path segments to your route, though. You can use a feature called Pathless Layout Routes. These routes are denoted with two underscores. You can create an __app file. With this pasted-in code, you can see the outlet component. Whether you know it or not, you've already been using an outlet component in your root.tsx file. Your whole application renders inside of this outlet component. The outlet will render any matching sub-route. Because this is an application layout, it will be rendered on every page. Then this specific page will render inside of the outlet component. To get this working, you have to add a folder with the same name as __app. Next, move all of your routes into __app. Reload the browser. You'll see a header and a little spacing because of the CSS in the app layout. Now, it's time to create a nav component. Here, I pasted in the nav code. You'll notice that there is a Remix link tag being used. Links have some nice features you can use, such as the ability to prefetch the page that it links to. By default, a link will not prefetch a page. Inside of the nav component, there's the name of the application and buttons to either log in or create an account. Notice that the button is taking in as prop. The as prop lets the user of the component designate what HTML tag the component renders as. This is nice for something like a button because you may want button styles for a link, but you don't want to use a button HTML element for accessibility reasons. Before you go implement the as prop on the button, export the file from the index component file. This hasn't been implemented yet, so when you click the nav buttons, nothing happens. Over in the button component, you can add an as prop. This will default to a button element. You can assign the as prop to a component variable. The capital letter signals the user and to JSX that this is a React component that needs to be rendered. Now, when the nav passes the button component and as equals link, the link component will be rendered, and you can pass whatever props that a link component takes. Go ahead and update the types to accept an as prop. Now, when clicking the nav buttons, they act like an anchor tag. To review, you extracted a button component from the POST form. You then used the button in the UserForm much like the POST form. You created a UserForm with an input of email and password, displaying any errors that may show up. You added the new useTransition() hook from Remix, which gives you the state of the form and allows you to render content based on the state of the form. Next, you created a signup and login page. Both render the UserForm. Then you created a routeless layout component. The layout component wraps your app in a div and gives some padding, renders a nav, and then an outlet renders the content of the

https://app.egghead.io/api/v1/lessons/remix-create-and-use-a-layout-with-remix-pathless-layout-routes/transcript

https://app.egghead.io/api/v1/lessons/remix-validate-user-sign-up-data-in-remix-and-hash-a-password/subtitles

Ian Jones: [0:01] You're going to wire up the signup page.

[0:04] At the end of the lesson, when someone fills out the email and password form, they will create a user in the database and be redirected to the login page.

[0:15] You might remember that you post to a Remix ActionFunction to create entries in the database.

[0:23] Here is the basic structure of the signup action. It grabs the email and password off of the formData from the request. It then calls the signup user function with that data.

[0:36] After that, you redirect to the login page and have the user log in to the application.

[0:43] The user signup function hasn't been created yet, so let's create it. You can add a new file called users.server.ts. Signup user will take an email and a password, both of which are strings.

[1:01] Next, you can pass those fields to db.user.create. You don't ever want to return the hashed password field, so you can pass a select object selecting every field, except the password.

[1:16] Back in the signup page, you can import the function. Ignore the TypeScript errors for now, you can come back and fix them later.

[1:24] Now, you can head over to the browser and create a user. I will type ian@email.com and a password. You will notice that by submitting the form, you are redirected to the login page.

[1:37] To double-check that the user is really created, open up Prisma Studio, and let's inspect the database. Here in the users table, you'll see that you have an email and a password.

[1:49] Obviously, you didn't hash this password. It's important to note that you don't want to store plain text passwords in your database. Because you are iteratively building a system, it's OK to test things out without doing them 100 percent correctly the first time. You just don't want to deploy this to production.

[2:10] Let's go solve this issue. First thing you'll do is run npm install secure-password in your terminal. This package doesn't come with TypeScript types out of the box, so you can run npm install savedev@types/secure-password.

[2:29] Now, back in your code, you will create an AuthUtil server.ts file. The hash password function is relatively simple. It converts a string to a buffer and parses that buffer to the secure_password hash function.

[2:47] Next, you take the hashed buffer and re-encode it into a string, so that you can store it in the database. Now that you're hashing a password, you can update the call to signup users to hash the password that comes in.

[3:02] Now, when you create a user from the signup page and then head over to Prisma Studio, you will see that the password is indeed, hashed.

[3:17] Now, it's time to validate the data that is coming in to the signup action. You want to prevent people from submitting bad emails and passwords. You have already seen how to validate form input before.

[3:31] The first thing you can do is head over to the validations file and create a signup schema. The schema will take an email that's a string and a password that is a minimum of five characters long.

[3:45] Back in the action, here you can see the validation code. You can see you're using this BadRequest helper function.

[3:53] The BadRequest function takes a type of action data. The data is of type action data, which in turn is parsed to the Remix JSON function with the status that defaults to 400, because we're returning a bad request.

[4:09] This action data type will look very familiar to your Post form action data. There's an error key with the form error and field errors for email and password. Action data also returns fields of email and password to keep the state of the signup form, if there's any error.

[4:32] Back in the action. For TypeScript sake, you want to inspect raw email and raw passwords type, so that we know the values are strings. Form data can be anything from a file to a number to a string, so you want to narrow down the possibility to a string.

[4:50] Next, you can create a fields object to parse back to your form, if there is an error.

[4:56] Now you can call signup.safeParse to validate the incoming data, passing in raw email and raw password. If success is false, you know you got an error, so you can flatten the error and return a BadRequest.

[5:13] The ActionFunction is returning JSON, but our page component isn't. You can call useActionData and pull off the error in field, parse those into the userForm.

[5:26] When you head on over to the browser to test your validation, you can see that errors are being parsed back when the input doesn't match what the signup schema requires.

[5:37] When you try to create a user that is already in the database, you will get a Prisma error. You can see that the error says, there's a unique constraint on the user's table. To avoid this error in production, you can check the database before attempting to create the user.

[6:04] Head over to the user.server file. Here's a function that queries the count of users that have a particular email address that's passed in. If the number is greater than zero, you know the user already exists in the database.

[6:20] Back to your ActionFunction, you can call the checkUserExists function and if it's true, you can return a BadRequest with a form error explaining that the user already exists. Notice that the button is hard-coded to say login.

[6:46] You can solve this by replacing the button with children and have the page component parse the submit button. You will also need to move the useTransition hook up to the signup page.

[7:11] Here, you can parse the button as children of the userForm. Add the useTransition hook to the signup page. One last thing, user signup may fail because of some random issue. You want to check if user signup returns a user.

[7:59] If user exists return a redirect, else return a BadRequest saying something bad happened. To review, you created an ActionFunction. You got the values for the user from the userForm. If those values aren't strings, you return a BadRequest.

[8:23] You validated that the input matches your schema. If it doesn't, you pass the field errors back to the user. If it does pass your schema, then you check if the user exists. If they do, you return a BadRequest.

[8:38] If they don't exist, you can call user signup passing email and password. If you successfully created a user, you redirect the login page. If you don't, you sadly say something went wrong.

[8:53] Meanwhile, inside of your user service, you made sure to hash the user password, because you never want to store plain text passwords in the database. Here's what it looks like one last time.

https://app.egghead.io/api/v1/lessons/remix-validate-user-sign-up-data-in-remix-and-hash-a-password/transcript

https://app.egghead.io/api/v1/lessons/remix-implement-user-login-in-remix-with-a-form-strategy-and-session-storage/subtitles

Ian Jones: [0:00] To start off, you can fix the signup form by adding a submit button back. The user form now takes children. You can pass the button in this way.

[0:16] You can use the useTransition hook to adjust the text of the button, based on the state of the form.

[0:27] There are many ways to approach implementing authentication. For this project, you are going to use remix-auth and remix-auth-form. This is a simple way to add authentication without too much headache or signing up for another service.

[0:43] In your terminal, you can run npm install remix-auth and remix-auth-form.

[0:50] Back in your project code, you can add an auth.server.ts file. This file is where all your authentication code will live. This authenticator class comes from Remix Auth.

[1:03] It expects a parameter of session storage. This object will need to implement getSession, commitSession, and destroySession functions. You can implement sessions in a couple of different ways.

[1:18] This project will use HTTP cookies, but you can also create sessions with a database. To implement cookies session storage, head over to the Remix docs. You can see the basic example of how to create a cookie store. Too bad, these cookies aren't quite as tasty.

[1:37] Go ahead and add this code to a file called session.server.ts in your project code. There's a couple things that need to be modified for the cookie session store to work.

[1:54] First, you can update the name to remix social session. You won't be deploying to remix.run, so you need to change the domain the cookies live under.

[2:06] You can check the node mf, and if it's production, use the Vercel URL. If not, don't set a domain. This is important, because the browser won't recognize cookies from other domains.

[2:20] Just for this project, you can bump up expires and max age. For security reasons, you don't always want your cookies to be super long-lived. For this project, it's fine.

[2:33] This HttpOnly flag is important. It tells the browser that JavaScript should have access to this cookie. It's really the only way to keep cookies safe from someone else's JavaScript code.

[2:46] The last update is to make secure true, when you are in production. Secure makes the cookie only work on an HTTPS connection.

[2:56] Back in the auth file, you can import getSession, commitSession, and destroySession. These are the functions your authenticator needs to manage a session. You could implement these functions with the database instead, if you didn't want to use cookies.

[3:11] Now, it's time to dive into the meat of the login process. You will implement a form authentication strategy. There are many different authentication strategies to choose from, for example, an OAuth2 strategy, a magic sign-in link strategy, or even a GitHub login strategy.

[3:35] The form strategy is pretty straightforward. You have seen how to take an email and password to sign up for an account. Now, you're going to take those fields and log the user in. Just like any other form, you can pull the raw fields with form.get.

[3:54] Next, you pass those fields to the login schema. Notice that the parse function is being called. You want Zod to throw an error if the input is invalid, because you are handling the error in the loader function on your page.

[4:10] Finally, if the input is good, you can call the user_login() function.

[4:17] You will notice that the second argument you are parsing to the form strategy is user login. This is naming the form strategy, so that you can look it up later in a Remix action and pass the request to the strategy.

[4:33] Go ahead and create the login schema. The login schema will be exactly the same as the signup one.

[4:51] Now, it's time to create the user_login() function. Everything related to users is in user.server.ts, so you can add the function there. This function is long but don't be intimidated. User_login() takes an email and password.

[5:09] The first thing to do is to check if the email exist in the users table. If the user doesn't exist, you throw an error. If the user does exist, you can call verify_password() parsing in the hashed password from the user, and the plain text password from the form input you just got.

[5:29] The result of verify_password() will either be valid or invalid.

[5:33] If it's invalid, the passwords didn't match or something went wrong, so you throw an error. If it is valid, there's a possibility that the hash should be improved. You can update the hashed password in the database.

[5:49] After all that, you can return the user without a hashed password. Let's take a look at what verify_password() looks like. Again, you have quite a long function. Verify_password() takes a password and a hashed password.

[6:06] The return value of this function is a promise with an object of result that can be invalid or valid. There is optionally an error and optionally an improved hash. You have to convert these strings to a buffer. Remember that the hashed password was Base64 encoded.

[6:27] You have to pass that along to the buffer. Now, you have to handle the result from calling secure_password.verify(). If the result is valid, you return an object with the result being valid. Next, if the result is valid but needs rehashing, you can rehash the password with sp.hash.

[6:50] Finally, if the result is not valid, you can return invalid with an error. If any error was thrown in this process, you want to return invalid with the error to make sure you don't get a bad session. With user_login() and verify_password() implemented, you can wire up the login page.

[7:15] There are two major things you need to add to the login page, the Action for taking user input and calling the form strategy, and the loader for checking if the user is authenticated and grabbing any errors from the session.

[7:31] Inside of the Action, you can call authenticator.authenticate. You can pass the user login name as the first param. Next, the request. Finally, the config object for what you want the authenticator to do on success or failure.

[7:51] Optionally, you can pass throw on error to handle the error in the Action if you want. However, since failureRedirect is present, that will take precedence. The loader will check if the user is already authenticated. You don't want a user signing in again if they are.

[8:12] Next, you can get a reference to the session with getSession passing in the request cookies. Finally, you can see if the Action through an error by checking if the session has the session error key on it, returning a form error if there is.

[8:29] Down in the component, you can get the error with use loader data, and pass the error to the UserForm, and that's it. Now, you can create a user and login. I'll create a user with the email of ian@egghead.io and a password.

[8:48] When you sign in to the newly created user, and open up the developer tools on the application page, you can see that there's a cookie with the name of Remix social session. You just implemented user login with a form strategy. It's time to review.

[9:09] On the sign up page, you added an Action function that uses an authenticator object to login a user with the form strategy. If the user successfully signs in, they're redirected to the index route. If they don't, they're redirected back to the login page.

[9:28] The loader checks if the user is already logged in and directs them to the index page if they are. Next, you look up if there's an error on the session and pass it down to the UserForm if there is. For the authenticator, you're using cookie session storage, which you grab from the Remix Docs.

[9:49] You implemented a form strategy, parsing the raw input to make sure that you're getting good values. Then calling user_login(). Passing in email and password. Inside of user_login(), you check if the user with the email exists in the database. Next, you call verify_password(), passing in the password form value and the user's hashed password. If the result is invalid, you throw an error. If not, you can return the user.

[10:24] Inside of verify_password(), you call secure_password.verify(), converting the strings to a buffer. If the password is valid, you return valid. If it's not, you return invalid with an error.

https://app.egghead.io/api/v1/lessons/remix-implement-user-login-in-remix-with-a-form-strategy-and-session-storage/transcript

https://app.egghead.io/api/v1/lessons/remix-implement-log-out-functionality-and-only-allow-logged-in-users-to-see-posts/subtitles

Instructor: [0:00] The only indication that a user is logged in, is that there is a cookie here in the application panel of the DevTools. The user has no indication that they are logged in. When the user is logged in, they should see their email and a logout button in the nav.

[0:17] Head on over to the app layout component. Here, you can add a LoaderFunction with a call to authenticator.isAuthenticated. This function will return a user, if it's available. You can pass that user back as JSON.

[0:34] Up above the loader, you can add a loader data type with a key of user and a value of session user. Remember that session user has all the fields of a user since the hashed password.

[0:48] Like usual, you can get the user data with the useLoader data hook, and pass the user into the nav component.

[1:02] Inside of the nav, if the user is not present, you can show the Login and Create Account buttons. Now, when you check the app, because there is a user session, you can see the buttons for Login and Create Account have disappeared.

[1:30] If a user is present, you want to display their email. There, now the user will know that they are logged in. Let's split the view, so you can see the UI changes as you make them.

[1:48] Right now, when the user is signed in, they have no way of logging out. Add a logout button to the nav. You will have to add items centered to the unordered list tag to make sure the items lineup.

[2:07] Add a little margin in between the Logout button and the email. Now, you have a logout button, but it doesn't do anything. How do you think you can add functionality to this button to log the user out?

[2:27] You can wrap it in a form. The form will take a post method in an action of log out. The action tells the form where to submit the post. You haven't created a logout route yet. You can add a logout file to your Routes folder.

[2:48] This route won't have any UI, because all it needs to do is sign the user out and redirect them to the login page. Here, you can call authenticator.logout passing a redirect path as an argument.

[3:06] In your browser, when you click Logout, you can see the user is logged out and redirected to the login page again. The user is still able to access the index page and view posts, but they should have to login to view any posts.

[3:24] Hop over to your index page. To protect this page from unauthenticated users, add a call to authenticator.isAuthenticated.

[3:37] You can pass in a failure redirect with the value of login. Now in the browser, you can't access the index page while you're logged out. To prove that logged in users can still access the index page, I'll log in with my account.

[4:02] Now, it's time to review what you've learned. You wanted to give the user a visual cue that they were logged in, so you added their email to the nav and a logout button.

[4:13] You wrapped the logout button with a form that posts to the logout action. The logout route is just an action that calls authenticator.logout, redirecting the user to the login page.

https://app.egghead.io/api/v1/lessons/remix-implement-log-out-functionality-and-only-allow-logged-in-users-to-see-posts/transcript

https://app.egghead.io/api/v1/lessons/remix-add-user-data-to-a-post-creation-in-remix/subtitles

Instructor: [0:00] Here in the Prisma schema, you can see that a post has an authorId. When you created the model, you added this feature, but you haven't been able to add users to the posts until authentication was completed.

[0:14] In the index action, you can see that a bad user ID is being passed. You only want authenticated users to be able to create posts. You can call authenticator.isAuthenticated inside of the action to accomplish this.

[0:31] This will protect the index route, as well as provide the authorId you need for the post. You don't need to validate this piece of data because it is provided by the session and not the user input.

[0:45] Next, you can pass user.id as the authorId when creating a post. Head on over to the browser and you can see, when you create a post, the user information is on it.

[1:05] To review, you pulled the user ID off of the call to authenticator.isAuthenticated. Then, you pass the user ID to the createPost function. You didn't have to validate this data because it is being provided by the session and not the user input.

https://app.egghead.io/api/v1/lessons/remix-add-user-data-to-a-post-creation-in-remix/transcript

Learn Remix by Building a Social Media Platform with TypeScript and Prisma

Ian Jones

You might also like these resources:

Up and Running with Remix

Credits

Course Content

You might also like these resources:

Up and Running with Remix