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

What is Remix?

> Remix is a seamless server and browser runtime that provides snappy page loads and instant transitions by leveraging distributed systems and native browser features instead of clunky static builds. 
>
 -- <cite>[remix.run](https://remix.run/)</cite>

But that summary only scratches the surface. Remix has great mental models, is extremely fast, and has a plethora of components and features that will make your life easier and web apps perform better. 

And in this course, you'll be learning how to take full advantage of what Remix has to offer. You will learn by building a full-featured blog with a database, authentication, CRUD operations, user roles, and more!

If you want to read more about why should give Remix a chance, give Kent's blog post, [Why I Love Remix](https://kentcdodds.com/blog/why-i-love-remix), a read!

[Check out this repo to see the project code for this course](https://github.com/kentcdodds/onewheel-blog/tree/main)

Kamil Khadeyev

Remix has so many awesome features that you’ll be learning from this course! You will be building a full-featured blog with a database, authentication, CRUD operations, user roles, and more! 

While work through this course make sure to not only pay attention to what you’re learning, but to the things that you’re not having to worry about such as state management, race conditions, and repeat submissions. Remix has you covered!

Intro: Up and Running with Remix

New Remix projects can easily be created using the `create-remix` CLI. In this lesson, you’ll run the following script in your terminal window `npx create-remix@1.17.0 --template remix-run/indie-stack onewheel-blog`. 

Once that is ran it’ll create the project and automatically run the dev server on port 3000.

Create a New Remix Project Using the remix-create CLI

The routes in your Remix app are based on the file structure within your `routes` folder. You can create a new route by making a new folder under `routes` and creating an `index.tsx` inside of it. 

Then in the index file you can make a new default export that returns a React component. Once that is saved, whatever you have in your component will render to the page.

Create Your First Remix Route

Loaders are used to get data into your components from the server. We can set up a loader by defining an async function named `loader` outside of our route component. That function will return a new `Response`, with some JSON in the case of this lesson. 

Then to use the data in our component, we’ll use the nice `useLoaderData` hook that Remix gives us, which gets the data returned from your loader. 

What’s extra cool is that in Remix your loaders will *only* run on the server. They won’t even be included in the browser bundle!

Fetch Data in Remix Using a Basic Loader

While you technically can have server functions in your route files, it’s not always the best choice. 

For code that you **never ever** want in your client, it’s a best practice to move them into separate files, and name with the `.server` convention. For example: `posts.server.ts`

Remix Server Code Filename Convention

We can take advantage of TypeScript by setting our `loader` function to the `LoaderFunction` type from `@remix-run/node`

Then we can ensure that our loader is returning the type that we want by creating a custom type called `LoaderData` with a property of `posts`. 

We’ll also do a cool trick where we get the awaited return type of our `getPosts` async function. This is done like this `posts: Awaited<ReturnType<typeof getPosts>>`

Integrate TypeScript Into a Remix Loader Function

Let’s move away from hardcoded JSON and use our own database. In this course, we’ll be using Prisma as our database but Remix *doesn’t actually care* about what database you’re using!

To model Posts in our Prisma database we can edit the `schema.prisma` file under the prisma directory. Changes can be pushed to the db by running `npx prism db push` in your terminal. 

We’ll also be seeding the database with data using a seed file in this lesson. Data in your seed file can be pushed running `npx prisma db seed`. Once you have data it can be accessed directly in your components!

Model Data in the Prisma Schema for a Remix App

You don’t have to worry about over-fetching when using Prisma. Just use the `.findMany` method from Prisma and pass it an object with a `select` property. In the `select` you can choose exactly what properties that you want off of objects fetched from the database. 

We’ll continue following the .server file pattern we established in an earlier lesson and create an async function in `post.server.ts` that fetches posts with only their slugs and titles. We can then use this function in our components.

Avoid Over-Fetching in Prisma by Using findMany

It’s not feasible to create a new route file for every single blog post we want to publish! Instead we can use the `$slug.tsx` filename convention with the dollar sign prefix to create a **dynamic segment**. Whatever you name the file is what the param will be called in your component. 

Then there are a couple steps to take to get posts from your db based on the url param. First you’ll write a `getPost` method in your `post.server.ts` file that finds a unique post based on the slug. Then write a loader function that calls your `getPost` method and returns JSON with your post.

Create a Dynamic Segment in Remix

We’d like to use markdown to format our blog posts. Markdown isn’t getting rendered by default but we can install the `marked` library to take care of that for us. 

The awesome thing about remix is that we can use `marked` to compile are markdown server-side in a `loader` function so we don’t have to bundle this hefty library and process markdown in our user’s browsers.

Process Markdown on the Server Using a Remix Loader

TypeScript is giving us a bunch of warnings. Let’s go through and correct some of those and get some type safety. 

For `marked` we’ll just install `@types/marked` as a dev dependency. But, with our dynamic parameter `slug` it’ll be a bit trickier since if we rename the file it’ll change the param name and references to `slug` will become invalid. 

To solve this issue we can use the library `invariant`, which we can use to check if something exists, and then throw an error if it doesn’t. This way TypeScript is happy since it knows that it’s impossible for `slug` to be null or undefined. 

Then lastly we just define a `LoaderData` type for the data that our loader returns.

Get TypeScript Coverage for Dynamic Parameters in Remix with Invariant

We need to create an admin route where we can create and edit our blog posts. 

First we’ll make a `/admin` route that has some JSX and a loader that returns all of the posts. But how do we create different pages for admin actions without repeating all this code? This answer is to use Remix’s nested routing feature!

Start by following a convention of naming a folder identically to your route, and having sub files that correspond to different sub pages such as index, new, and so on. Then in your `AdminRoute`, render the `<Outlet />` component. This tells Remix to render nested routes in its place!

The `index.tsx` nested route will be the one that is rendered by default. In the index you can link to the other nested routes using Remix’s `Link` component.

Render Nested Routes in Remix

Let’s make forms for those nested admin routes. We can accomplish this using Remix’s handy `Form` component. But, we also need to actually handle the form submission. We’ll do *that* using a Remix **action.** 

In Remix you perform all your GETs with loaders, but everything else is going to use an **action**. Our action in this case will take a request, parse the form data, use Prisma to create a new post with the form data, and then redirect the user to the admin index. 

Remember to also write a new function in a `.server` file that handles creating the post in Prisma!

**Note:** Fetch implementation has changed, to log request payload, you need to use Object.fromEntries(). e.g. `console.log(Object.fromEntries(await request.formData()))`

Use Remix Actions to Handle Form Submission POST Requests

Our posts form needs some kind of validation to prevent bad submissions from going through. We’ll want to start be validation sever-side since that is essential, and only do front-end validations as enhancement later. 

We can do a validation in our **action** by creating an errors object that has three ternaries that check if any field is empty. Then we check if there are errors, and if there are, we return the errors as JSON instead of submitting the form and redirecting. 

Then in our component we can use the errors data to display messages to the user.

Validate Form Fields in a Remix Action

Our `title`, `slug`, and `markdown` currently have a TypeScript warning on them because they can be of the value `FormDataEntryValue` or `null`. 

To handle this error, we are going to be using `invariant` from [tiny-invariant](https://github.com/alexreardon/tiny-invariant) to throw warnings if the data being passed isn't a string. 

We are also going to type our `errors` down in our JSX so they aren't just of type `any`. 

To do this, we type the `errors` variable as `ActionData` which will take the `title`, `slug`, and `markdown` as types. 

Typing Form Submission Values with tiny-invariant

Slow networks can be debilitating to your applications. Right now, our application doesn't handle slow networks at all. To help with this, Remix has the `transition` state to show the user that we are making network requests and working on things. 

In this application, we are going to use `useTransition` to check if we are currently submitting a request, like making a new post. 



Handle Loading State with Remix useTransition

When trying to load data on slow networks, it can get aggravating for your users. On our posts page, we have several links to each of our posts. Because Remix knows all of the CSS, JavaScript, and data that is needed by just looking at the URL, we can tell Remix to start fetching that when someone hovers over one of the links. 

`Link`, from Remix, has a special prop on it called `prefetch`. It has three different options on it. We are going to utilize `intent` for when the user shows intent to navigate to a page. 

Pre-emptively Load Links with Remix prefetch

We want to make it so that only admins can access the admin routes. To do that, we need to add support for environment variables. Using Remix, we can choose which environment variables to expose to our front or backend. 

Using an `env.server` file, we can create a function that returns an admin email address that we can use for accessing those admin routes. This will allow the front-end access to an env variable. You can still use regular env variables for server-side. 



Expose Specific Environmental Variables to The Client Using Remix

We have an admin button but we really only want to show that if the user is logged in as an admin. Using our env variable from the last lesson, we can check to see if the user is an admin or not to be able to display that button. 

Create an Admin User Hook using Remix to Verify Admin Users

Now that we have a conditional in for the admin button, we need to do the same for all of the admin routes because currently, they are still accessible to everyone. 

We will set up a function to check if the user is an admin when accessing a route. If they are an admin, they will be able to proceed. If they are not, it will force a logout request which will redirect them. 

Hide Admin Routes from Non-Admin Users in a Remix App

We can create a new post but we can't edit existing posts. To start we want the admin to click on a post and have it fill out the `new` form so that we can edit it. 

We will do this by listening for the slug. If it is new, then give us an empty form. If the slug is from one of our posts, then fill in the data of the post. 

In the next lesson, we will take that data and fill out our form with it. 

Allow Admins to Edit Existing Posts on Remix Applications

Now that we have our data from our posts, we need to populate out our form with it in order to be able to properly edit the data. 

By using our `getPost` utility to get our posts and send that along to our json. We use `useLoaderData` to get our data and use that to set the `key` on our `Form`.  

Populate Remix Edit Form with Existing Post Data

Now we just need to add in the functionality to edit our posts. 

We will duplicate `createPost` since it has most of what we need already and use Prisma to `update` our post. 

We will also add in the conditional for our button to know if we are creating a new post or updating an existing one. 

Add Update Functionality to an Edit Post Page in Remix

We've added in creating and editing posts. Now it's time to be able to delete them. 

We will use the create button that we already have to create our delete button. Just need to adding in the conditional for only being able to delete existing posts, create an `isDeleting` variable, and replace the `isUpdating` variables with `isDeleting`. 

Add Delete Functionality to Posts Page in Remix

All of our Admin routes and slugs don't have the safety of TypeScript so we are going to type them in this lesson. 

Add TypeScript Typing to Admin Routes in a Remix App

Currently, if we try to navigate to a post that doesn't exist, we just stay on the New page. We need to a way to catch those and tell our users that they are access in a route that doesn't exist. 

We will create a simple function that returns a div saying `Uh oh!` and have that get rendered when a user navigates to a page that doesn't exist. 

Handle 404s in Remix with CatchBoundaries

We are handling expected errors, but what about unexpected errors? 

We'll start by creating a function we'll call `ErrorBoundary` to return our error message. What's great about that is we can move `ErrorBoundary` to the parent and it will cover all of the children inside of it. 

We want it to cover the `posts` as well but to do that, we will need to create a parent for it as well using Remix's `Outlet`. 

Handle Unexpected Errors With Error Boundaries in Remix

You can deploy Remix to pretty much anywhere and the Remix Indie Stack is preconfigured to deploy to [Fly](https://fly.io) with [Docker](https://www.docker.com/). This is where we are going to deploy to. 

If you created your app using the Remix launcher, all the instructions should be in the README. 

Deploy a Remix Application to Fly.io

Thank you for making it through my course on Remix! There is a ton more in Remix but is too much to get to in a single course so look forward to more in the future!  

Outro: Up and Running with Remix

Learn Remix by building a social media platform powered with TypeScript and Prisma.

Up and Running with Remix

Kent C. Dodds

Free Community Resource

You might also like these resources:

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

Credits

Free Community Resource

Course Content

You might also like these resources:

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