Sometimes modules can end up in your client bundle when you don't want them to.

For example, the Zod library isn't needed by the client so there's no reason to ship it.

There are a couple of ways to find out if you're including unnecessary modules in your bundle.

## Using `source-map-explorer`

One of the most popular ways is to use `source-map-explorer`, which generates a visual representation of your build's source maps.

In this case, we can see that Zod is present in the bundle:

![](http://res.cloudinary.com/epic-web/image/upload/v1681513645/epicweb.dev/tips/2023-01-11-14-08-31_5_00-22440-what-is-in-that-source-map.png)

This tool gets the job done, but there's a quicker alternative without going through as much trouble.

## Modifying the Module in `node_modules`

Adding a `console.log()` statement to the specific module you're interested in will let you know if it ends up in the client-side bundle.

Since I'm interested in Zod, I'll open its `package.json` inside of the `node_modules/zod/` directory.

Inside of `package.json`, find the `module` property.

In this case it's pointing to `./lib/index.mjs`.

Remix and most other bundlers reference this file when building the production application, which is often in the `lib` folder with an `.mjs` extension.

Open the `./lib/index.mjs` file from `package.json` (which has a full path of `node_modules/zod/lib/index.mjs`).

At the top of the file, add a long `console.log` that will be noticeable in the console:

```typescript
console.log('zzzzzzzzzzzzzzzoooooooooddddddddddddddd');
```

Save the changes to the `index.mjs` file.

## Check the Console Output

To check your work, trigger a rebuild by saving any file in your project.

When you check the console in your browser, if you see your console log, you know that the module has been included in your client-side bundle.

You can leave the `console.log()` in the module while you work on configuration or other things. When the output is gone, you know the module isn't being included (at least for the page you're currently working on).

As a final step, you can use `source-map-explorer` to confirm that the module is no longer present.

This is a nice quick and easy way to make sure something isn't showing up in your client-side bundle if you don't want it to!

There's a faster alternative to using source-map-explorer to examine your client bundle for unwanted modules.

Quickly Determine Whether a Module is Bundled

Instructor: [0:00] You might know that one of the best ways to find out whether a JavaScript module is showing up in your client bundle is by using source-map-explorer.  
  
[0:08] You generate your build with source maps. Then you pass source-map-explorer to that source map, and then will tell you in a fancy chart like this what is in that source map.  
  
[0:22] Here, we see that we've got zod in there, and that's the thing in particular that I'm worried about showing up in my client bundle.  
  
[0:30] However, if you don't want to go through the trouble of that, you can actually really quickly determine whether a particular module is showing up in your client bundle by just changing that module.  
  
[0:40] We're going to go to our node modules. We'll search through those. I'm going to look at zod, and I will go to the package.json, where we will look for a module property. This is what's going to be built, at least in a Remix application.  
  
[0:54] Most bundlers these days will reference the module property for the client-side bundle. It will reference that file when building for the production application. We're just going to go into lib index.mjs, and at the very top we'll console.log zod.mjs.  
  
[1:18] When my editor finally lets me save, [laughs] then we can go back here, hit save in here to trigger a rebuild. Then we can come over here and we see, "Oh, there's zod right there." We know for sure that this file is showing up in our client-side bundle.  
  
[1:35] We can leave that console log in there and do whatever work we need to to move things around so that it doesn't show up in the client-side bundle anymore. When that console log doesn't show up anymore, you know it's gone, at least from this page.  
  
[1:47] When you're done working through that, you can come back to source-map-explorer to be sure that it doesn't show up in this chart. This is a really nice quick and easy and fast way to make sure that something is not showing up in your client-side bundle if you don't want it to.

Whenever you run into a situation where you're having trouble seeing live updates when making changes, I find it best to try to reproduce the problem in a completely separate environment.

Here's a process you can follow to isolate these types of problems in your own project.

The first thing to do is create a new `test.ignored` directory in your project. Check that your `gitignore` configuration ignores everything with `.ignored` in the name. You don't want this test code ending up in your repo!

Next, create the minimum number of files you need in order to recreate the problem.

The idea is that you want to have enough code to recreate your problem without being overwhelmed by all of the other parts of your project.

Now you can start experimenting and testing potential solutions. This might involve running tests using a watcher for changes, or creating new components.

Once you've found the solution in your test code, bring it back over to your main application code.

After you've verified that your problem is solved in the main app, you're safe to delete your test directory.

Isolating your problem to a small example in a temporary directory is a great way to solve complex problems!

## Minimal MDX Example

In this example, I have a complicated setup involving adding interactive components to an MDX file that is being treated as plain markdown.

Inside of the `test.ignored` directory will be a minimal set of files to reproduce the problem I was seeing in the full project.

Since I'm working with MDX, I'll create a `README.md`, a `test.ts` file, and a `component.tsx` file.

The `component.tsx`  file will import React and export a simple `Counter` component to act as a stand-in for the more complex component that would be used in the real project.

```tsx
export function Counter() {
	const [count, setCount] = React.useState(0);
	const increment = () => setCount((c) => c + 1);
	return <button onClick={increment}>{count}</button>;
}
```

The `README.md` file will import the `Counter` component and use it:

```markdown
import {Counter} from './component'

This is my counter:

<Counter/>
```

Inside of the `test.ts` file, import the necessary modules and bundle the MDX:

```tsx
import path from "path";
import { bundleMDX } from "mdx-bundler";

async function go() {
	const result = await bundleMDX({
		file: path.join(__dirname, "README.md"),
	});
	console.log(result.code);
}

go();
```

On the command line, I'll run the command `tsx watch ./test.ignored/test.ts` and check the output. If the MDX is not processed correctly, make changes to the configuration options.

![](http://res.cloudinary.com/epic-web/image/upload/v1681514520/epicweb.dev/tips/2023-01-25-14-11-53_41_03-36280-oh--ok--thats-interesting.png)

In this case, we need to define `'process.env.NODE_ENV'`

```tsx
process.env.NODE_ENV = "development";
```

![](http://res.cloudinary.com/epic-web/image/upload/v1681514598/epicweb.dev/tips/2023-01-25-14-11-53_47_04-03160-you-dont-see-any-all-caps-exclamation-points.png)

In addition, I need to add `options.mdxExtensions` to the `MDXBundler` to treat `.md `files as `.mdx` files, and add `options.format` to force the format to be `mdx.`  Optionally, `development` can be set to `false` to remove debugging helpers:

```tsx
mdxOptions(options) {
    options.mdxExtensions = ['.mdx', '.md']
    options.format = 'mdx'
    options.development = false
    return options
}
```

By creating a smaller example with less moving pieces, I was able to track down the configuration issues with my MDX processing.

The next time you run into a problem and you have no idea what could be causing it, try moving to a separate environment and slowly add files until you've reproduced the issue.

With fewer moving parts, you can more easily identify and resolve issues much faster than in the complexity of your full project.

When faced with a complex problem, try isolating it by creating a minimal example in a temporary project directory.

Use Isolation to Solve Complex Problems

[0:00] I've got a Markdown file here that I want to treat as MDX so I can have interactive counter components or whatever other components that I want in the instructions for the workshops. As you can see here, that's not being processed as MDX.  
  
[0:16] This is just being treated as Markdown, and if you dive through this, you can see where that is being treated as just like a regular string, rather than being treated as MDX, which I want it to be. I've got this whole, big setup here and this compile-mdx.server with a bunch of plugins and all of this stuff, even caches and stuff.  
  
[0:37] It's really difficult to work in this. Whenever you run into a situation where it's difficult to make changes and see your changes live and everything, I find it's always best to try and reproduce the problem that you're having in a completely separate environment, and then you have fewer moving parts.  
  
[0:58] What we're going to do is, I'm going to come down here. We're going to make a new directory called test.ignored. That's my global gitignore, just ignores everything that has a .ignore in the file name. Inside of this, we're going to make a test.ts, and we're going to also make whatever else we need.  
  
[1:18] In my case, I need a README.md and also, let's see, a component.tsx. I'm going to make a counter component to export that. We'll import React and then in my README, I'm going to import the Counter from the component, and we'll say this is my counter, Counter. All right, great.  
  
[1:53] That should work with what I'm trying to do, and then we'll make our test. We'll say import path from 'path' and bundleMdx. No, that's not it. mdx-bundler, and we'll make a function, because I can't use top-level await because these aren't native ESM. If it was native ESM, you don't need to make this go function. You just do await at the root.  
  
[2:25] Now, I can say bundleMdx. I think bundleMDX in [laughs] all caps, and we'll say file: path.join and I'm going to say _dirname. That will go right there, _dirname. We're actually going to be processing the README.md.  
  
[2:49] You take as few of the pieces of your actual code as possible to reproduce the problem. You narrow the problem down as much as possible. We'll get our result from that await, and then we'll console.log the result.code.  
  
[3:06] You know what, another thing that we'll do is in here, we'll make it obvious when it has been processed properly by adding a bunch of exclamation points. Now, we're going to run tsx watch ./test.ignored/test.ts. Let's move this out of the way and take a look at what we've got here.  
  
[3:32] Expected value for process.env. That's interesting. I could rerun the script with setting the app, but we'll say process.env. NODE_ENV= 'development,' which is what I'm running when I'm running my server.  
  
[3:47] That's kind of weird that it requires that, but that's OK, because I add that additional aspect to my actual environment until I get to the point where I'm reproducing the problem. I am reproducing the problem.  
  
[4:00] You don't see any all caps exclamation points, and in fact, there's the import right there. [laughs] This is not great. Now, we can go through docs and different configuration options, and I'm going to skip all that because I actually did that already.  
  
[4:19] The thing that's going to fix this for us is there's this mdxOptions (options) with mdx-bundler, and options.mdxExtensions. We need to treat our Markdown files as MDX. Actually, one other thing that we could do before we get to this is, let's test a theory that if this were an MDX file, that it would be treated as such. Boom, there it is.  
  
[4:47] All we need to do is tell our mdx-bundler or MDX that we need to treat .md files as .mdx files. Now we can switch this back to an .md. We switch this to .md. Of course, we need to return the options there. Oh no, it's still not giving us all those exclamation points in here.  
  
[5:12] The other thing that we need to add is options.format, and we're going to force it to say, "Hey, I want the format of this thing to be MDX." That's going to force it, and now we are solid.  
  
[5:25] Then the other thing that actually bothered me is I saw this fileName stuff in here. In production mode, that is all going to get removed, because these are debugging helpers and stuff. For my use case, I actually don't want that, and so I also am going to add development is false, and I can very quickly see, those are all gone.  
  
[5:50] I'm able to take this now over to my actual source code and add the pieces that were just the couple of lines that make all of the difference, and now I can come over to my running app, and indeed, it does run, and I can tab over to the button and, boom, boom, boom, boom, boom, boom. The button is totally working, so huzzah.  
  
[6:11] Next time you run into something that is there's so many moving pieces you have no idea what could be causing the problem, try to move to a separate environment and slowly add, add, add until you've reproduced the problem, and then you can work within that environment. It's way, way faster.  
  
[6:28] I hope that helps. Have an awesome day.

If you're not sure if the right font is being applied to your app, here's an easy way to check.

1. With the help of DevTools, inspect the element where the font should be applied.

2. Go to the `font-family` configuration and copy the font you want to use.

3. Create a temporary style element and paste the `font-family` configuration in it.

4. Modify the font name slightly to see if the font changes when applied to the element.

If it doesn't change, it means the custom font is not loading properly. You can quickly check the "Network" tab and see that the font file is not loading.

![](http://res.cloudinary.com/epic-web/image/upload/v1681515386/epicweb.dev/tips/2023-03-02-15-11-03_11_00-59540-this-is-an-easy-fix-we-just-remove-the-end-and-now-we-get-a-refresh-and.png)

To fix this, you can investigate if there are any typos in the font name or other configuration issues.

To confirm that the correct font is being applied, toggle back and forth between the font you want to use and another font. If the font changes when you toggle, then it's working properly.

This technique can help you quickly identify and fix any issues related to loading and applying custom fonts in your app.

Learn how to use DevTools to check if the correct font is being applied to your app and troubleshoot issues related to loading custom fonts.

Check if Custom Fonts are Properly Loaded in Your App

[0:00] Sometimes, the font that you're using doesn't look a whole lot different from the regular font, and so you're not sure whether you're actually loading the fonts that you're supposed to be. For example, I've got a font that I want to have applied to my app. I'm pretty sure that it's not applying, but I'm not positive. To find out, I'm going to select this Starport element, and then I'm going to go to "font family."  
  
[0:24] Here's the configuration for my font family that I've got here, so I'm going to copy this. I'm going to stick it up here in the style element, and then all I need to do is make a change to this. If I remove the "s," then it should actually change the font, because I just changed what that font is. It didn't change. It looks exactly the same either way, so we know that this font is not loaded.  
  
[0:48] We can actually look at that and see the font file itself is not loading properly, but this is an easy fix. We just remove the "n," and now we get a refresh. Now, I'm still not sure. Is that the right font, or is that the old thing? We're going to paste in our fonts here again, and come over here and just change it back and forth. You can see, boom, that is definitely loading the proper font.  
  
[1:16] If you're ever not certain whether the right font is being applied, or something, then you can simply set the font family to what you want it to be, and then toggle back and forth between that being enabled and that not being enabled. You should see that the font should change. If it's not changing, then you've either got a typo in the font name, or something else is misconfigured in your app. There you go. I hope that's helpful.

Sometimes our components need to render something that's only known by the client. For example, what the user's preferred color scheme is or their timezone offset. So when the server wants to render, we're stuck guessing and if we guess wrong the user will wind up with a bad Content Layout Shift which is a bad user experience and reduces their confidence in our app.

[The client hints](https://github.com/epicweb-dev/epic-stack/blob/main/docs/decisions/005-client-pref-cookies.md) feature in [the Epic Stack](https://epicweb.dev/epic-stack) allows you to communicate these values from the client to the server following the pattern established by the (work in progress) standard. By using cookies for storing these values, you can ensure the server will know the proper values at server render time so you can take the user preferences into account.

Even if you're not using the Epic Stack, Remix, or even React, you can apply this same setup to your own Web app.

Learn how to eliminate CLS using client hints in the Epic Stack.

Kent's going to show you how to respect the user's reduced motion preference even on the server render using the client hints feature in the Epic Stack.

Use Client Hints to Eliminate Content Layout Shift

Instructor: [0:00] The Epic Stack just added support for client preference cookies. What is this? Basically, it's an implementation of a new standard that's coming and being worked on for the server to be able to tell the client it needs some additional information before it can render.  
  
[0:18] If you want to make a really awesome user experience, you want to server-render something, and then when the client takes over and adds event listeners and stuff, it doesn't actually need to change anything. If it does, then it's going to result in a really bad content layout shift and it makes for a really poor experience.  
  
[0:35] Examples of this are a flash of the incorrect theme or a time zone problem where it renders some time on the server and then on the client is in a different time zone so it renders a different time. Things like that can be a real problem. The browser can't just send all of the user's information to the server because there could be a lot of things that the server doesn't care about.  
  
[0:59] The way that this standard works is the browser will say, "Hey, I want to get this resource," and then the server will say, "Oh, before you can get that resource, I need a couple extra information." It sends a response back. The browser says, "OK, cool, I'll send you that information," and then the server can send the correct response with the details that now the server needs.  
  
[1:21] This works out really well. We've implemented an inspired feature. It's not exactly the same sort of thing. In fact, when the standard is finished, we'll probably keep our implementation because it does have some benefits on top of that. Just a couple improvements, and so we'll probably keep our thing around. It is definitely inspired by this sort of thing.  
  
[1:46] Let's take a look at an example. Let's say that I'm building something for the Epic Stack and I want to have this cool fade-in transition. This is actually something that I do on my website and I'm using a tool called Framer Motion that allows me to build some really awesome animations that would be extremely difficult to do if I were just using CSS.  
  
[2:08] There are some situations where using regular CSS is just not going to quite do it for you. I need to do this in JavaScript. The nice thing is that there's a useReducedMotion hook with Framer Motion. We can take that reducedMotion and determine whether we want to have the motion props on here at all.  
  
[2:33] If I have prefers-reduced-motion reduce, if I've configured that in my browser, then I navigate over here and it doesn't do that motion. If I turn that off, then it does. We can respect the user's preferences.  
  
[2:51] The problem is that this is only known at the client render time. If I turn this off and then do a refresh, then the server thinks that it's going to animate this in, so it renders it as invisible. The client doesn't animate it because the user says, "I want to prefer reduced motion." This is a bit of a problem. This is what the client hints is supposed to solve. Let's solve this using client hints.  
  
[3:19] We've already implemented the theme using the same sort of thing. We're going to do the same thing for reducedMotion. The cookie name, we're using cookies to manage these values, we'll just call it prefers-reduced-motion. Then here, the value, we're going to say no-preference.  
  
[3:42] If that matches, then we know that we do not want to reduce the motion. If it has no preference, we don't want to reduce the motion. If they do have a preference, then it will be reduced. We do want to reduce the motion. Our fallback here is going to be false. We'll just default to everybody having our animations.  
  
[4:03] For the transform, what this basically means is when we put this true and false value into the cookie, that's going to turn it into a string. In our case, we actually just want it to be a boolean. We're going to say if the value is equal to true, then we know that the value should be the boolean true. This transform just turns it from the string into a value that we can use.  
  
[4:27] With that now, let's go over here, and instead of using this useReducedMotion, we'll use the useHints. useHints will return an object that has reduced motion as a property on it. We'll just destructure that. Now we can come in here and I refresh. I don't get that animation because I have prefers-reduced-motion and I also get to see the actual value itself.  
  
[4:52] If I turn this off and I refresh, then I get that nice fade-in effect that I was going for. We have this really nice capability because the browser is communicating back to the server what its preferences are using cookies. We can see in here we're dark mode and this one is our prefers-reduced-motion and that's set to true currently.  
  
[5:15] That's client hints in the Epic Stack. You can, of course, use this in whatever React or Remix project that you're using. It is a pretty straightforward thing. Feel free to reference the client hints. If you're using the Epic Stack, just stick your client hint config right in here and then you'll be able to use it all over the app with however you need to do.  
  
[5:36] Whatever you're trying to do that's user-specific for something that's only known by the browser, now the server can know all of those things. I hope that helps. Have a good one.

When a user creates a new account with their email address, we want to verify that email address belongs to them. That way if they ever need to change their password or we need to communicate with them about something we know we've got the right address for them.
But to verify the user's information can be tricky. We can send them something and have them send it back to us, but we need to make sure that what we send them is random enough to not be guessed, simple enough to be typed, and only valid for a short period of time.
[The Epic Stack](https://epicweb.dev/epic-stack) used to generate an encrypted token, but there are limitations and vulnerabilities associated with doing this. So now the Epic Stack has adopted a new pattern called "Time-based One Time Passwords."
Learn more about what went into the decision here (along with [the ChatGPT AI conversation](https://chat.openai.com/share/a1bbd00d-c9d7-4846-a9af-12c6a475cd20) that aided in making this decision) by reading the decision documents for the [Email Code](https://github.com/epicweb-dev/epic-stack/blob/main/docs/decisions/013-email-code.md) and the [Time-based One-time Password Algorithm](https://github.com/epicweb-dev/epic-stack/blob/main/docs/decisions/014-totp.md).

Watch Kent show you the improved user experience, security, and the implementation of Time-based One Time Passwords in the Epic Stack.

Learn about the improved user experience, security, and the implementation of Time-based One Time Passwords in the Epic Stack.

Improve UX and Security with Time-based One Time Passwords (TOTPs)

Kent Dodds: [0:00] I had a big long conversation with ChatGPT about the merits of the authentication system in the Epic Stack, and how we validate user emails, and I changed. The way that we used to do it is encrypted payloads, an encrypted token with a magic link. Now, we're using a time-based one-time password.

[0:22] First off, I decided I wanted to make things a little bit easier for users to submit the one-time password thing. We send them a six-digit thing that they can type in instead of a magic link that they have to click. Benefit of that is, they don't have to have two different tabs. One, where they requested the link, and then next, where they clicked and open the link.

[0:47] That's nice. It's also helpful if the device that you're opening the email in is separate from the one that you want to sign in. That was an accepted decision that I decided.

[1:04] In doing that, I decided, I also should probably secure up the way that we do email verification in the first place because we are susceptible to rainbow table attacks and other brute-force related attacks that could potentially leak our encryption secret.

[1:23] Which is unlikely, but could definitely happen. We're also open to disgruntled employee attacks and stuff like that. By switching to a time-based one-time password algorithm, we sidestep those issues.

[1:40] You can read through the decision documents to get a little bit more background on this. Of course, I do link to this entire conversation with ChatGPT where I'm weighing the different trade-offs. I'm really close to saying, "Forget it," and then decide to go back and forth. It's pretty interesting conversation. Feel free to read through that.

[1:59] I want to show you what the user experience looks like now. I go to login. Of course, you have to have the server running, npm run dev. Let's go to the home page again. I go to login. I am an existing user. That flow has been unchanged, still username and password. That's going to be the same.

[2:22] The new flow comes into creating an account and "Forgot Password." Let's create an account first. We're going to say, jenny@example.com. We'll submit. That will send us to this new page. This page did not used to exist, it used to just say, "Check your email and then click on the magic link."

[2:42] Now, we go to a /verify that has the email and the URL. We're supposed to enter the code right here. Then we received an email here. During development, it is marked out, and we just log the email to the console. We have both the text and HTML form.

[2:58] Here in the text, we can see that is our code. We can copy that and paste it right here. Then we go submit and now we can go through the onboarding process. That is unchanged, same thing.

[3:12] If we go to forgot password...Actually, let's do create account again and say, jenny@example.com. We submit. We'll have a new email with a new one-time password. We also have this link. This will pre-fill the code as a URLSearchParam. I'll copy that and paste that in place. That will instantly verify and redirect us.

[3:39] Now, if that one-time password is already been used, then that's not going to work. It will say, "The code is invalid." If it's a completely invalid code, then that will also say, "It's invalid." All of the typical things that you would expect work in the scenario. Trying to use somebody else's code with a different email address is also not going to work all of that stuff.

[4:05] All right, let's take a look also at forgot password flow. If I say, username or email. We say, Kody, that's the username. It's important that we keep the username or email here rather than resolving this to a common thing, like username specifically or just email.

[4:23] The reason for that is if we resolved it to email, for example, then somebody would be able to find a user's email address by typing their username in here. Then vice versa, if you had their email address and want to find out what their username was, you could use this. You don't want to do that. We keep the ambiguity of username or email here.

[4:46] It's nice to be able to provide either username or email because this means we also don't need to have a "Remind me of my username. I forgot my username" thing. You just give us either one of those and we'll send you the email.

[4:59] We will have gotten that email here. Again, we can click on this or we can type this in. We type that in and submit. Now, we can do the password reset. There we go. Now, I can authenticate and we're logged in. That is the user experience for the flow.

[5:24] The way that this works is also interesting. The way that we do that is we have this util here. Let's start from the route. If we go to our auth routes and we go to our signup. Then in the signup, we have...Of course, the UI is just a form. Nothing interesting there. The action we're parsing the form, like we do with our regular conform and Zod schema and stuff.

[5:53] The interesting stuff comes in right here. First of all, we want this OTP, this one-time password to be valid for 30 minutes. That's pretty long for a one-time password, but for this type of experience, I think 30 minutes is perfectly reasonable because this is a generated project for you. If you disagree, you can always just change this. It's very easy to do.

[6:16] 30 minutes is our default here. We generate the TOTP, the time-based one-time password. You can dive into that and look at the implementation. This is all custom implemented based heavily on the NOTP, which was great, but it only supports sha1.

[6:37] That is not great. The maintainer is not actively responding to stuff. Anyone can feel free to make this as an open-source package. I definitely welcome that. This was copy, paste, and modified and improved based on that package.

[6:54] GenerateTOTP, generate an HOTP, an HOTP is a HMAC-based one-time password. For us, we want it to be time-based, because that means that it, by design, will expire after the validSeconds that you provide here. We can even keep it in the database indefinitely and once that validSeconds time has passed, there is no way for that thing to be valid anymore. That's one of the benefits of a TOTP.

[7:29] The TOTP is based on the HOTP. We generate our counter based on the number of seconds we want to be valid for. We generate a random key and then we return that random key, the algorithm that was used, the number of validSeconds, and OTP value itself. We use those to create a verification.

[7:51] First of all, we have a unique constraint, if we look at our schema.prisma. We have a model for verification and we have a unique constraint on the verificationTarget, and the type. That means it's impossible for a user to have two OTPs for the same email, for example, because that wouldn't make any sense and there could be a bit of confusion if they had multiple.

[8:16] That's why we instantly delete many of these. Delete all of the ones that have the same verificationType and the verificationTarget. Our verificationType is onboarding, and the target is their email. The thing we're trying to verify is the email.

[8:35] We create a new one with that type, that target, the algorithm that was used to create the TOTP, and the secret that was generated to create that one-time password, the length of time that it's supposed to be valid, and the one-time password itself.

[8:54] Then we redirect the user to the signup verify page with their email that they typed in. They provided that to us and we send them to the verify page with that prefilled in, because that's one part of the OTP.

[9:13] You can't give a random number and have it signed you in as whatever user-provided or has that OTP number. That doesn't work. You have to have both of them. We prefilled that because you gave that to us. That's what's going to be our redirect URL.

[9:32] Then we add the OTP to the email that we're going to be sending. We give them the OTP directly and then also give them the URL that they can click and have that prefilled in. Now, they have the option. They can do one or the other, and it will work just as well. If it was successful in sending the email, then we redirect them and they can continue on.

[9:55] Now, once they land on the signup verify page, in our loader, we're first going to check if it has the OTP in the query parameters. If it does, then they probably clicked on the magic link and here they are.

[10:09] If it does, we're going to do the regular validation that we'll look at in a second. If it doesn't, then we'll return the form in an empty state so that the user can fill in the missing pieces.

[10:22] The form, there's nothing too interesting about the form here. It's a just regular conform thing going on here. When the form is submitted, that is going to go into our validate logic. We run through that validate logic, when they land on the page, if they have both of the pieces of information. If they don't, we wait for them to submit the form.

[10:45] If they're submitting the form that's coming from formData, if they are landing on the page that's coming from the URLSearchParams. In either case, the logic is the same.

[10:52] Here's regular conform, validation staff. We have a superRefine on our Zod schema that will go check the database for a verification that matches the email and the code.

[11:06] We grab the pieces that we need to verify that code. If there is no verification, maybe the verification was deleted, they're using an old code or something like that, then we'll say, "Invalid code."

[11:18] We're not going to give them any more helpful information there, because why would we? It would probably be useful if we say, "Have a little thing, request another code," or something. As far as the validation is concerned, it's not concerned with that.

[11:34] Assuming there is a verification in the database that matches the OTP that they gave us and their email, then we're going to verify it with the OTP that they gave us, and the secretKey that we stored in the database.

[11:52] We're going to make sure we use the same algorithm and the same valid number of seconds. That's also an important input here. Then we have the window set to 50 because I was testing something. This window should be set to one.

[12:09] OTPs are used for one-time passwords for Google Authenticator or 1Password, wherever the thing you scan the QR code, and you get a new password every 30 seconds.

[12:21] When you have something like that which we will in the future, you can end up with a situation where the clock that...The one-time password depends heavily on the clock. If the clock on the server and the clock on the device is off a little bit, then the one-time password can also be off and that's not great.

[12:43] The window means, "I'm going to be valid for this length of time, but also for the previous length of time as well." That way you can account for that clock drift. You normally don't want to have much more than three in there, but it depends on the situation.

[12:59] In our case, we are both the client and the server. The server is acting both of those roles. We don't need to worry about clock drift. That's why we can say window of one for this specific usage.

[13:13] If there's no results then the code was invalid, it is not verified. We're going to add that issue. Otherwise, we don't add any issues and things are hunky-dory. Awesome. That's the integration with Zod here and all of its type-safe and it's amazing.

[13:30] If we are doing a validation as the user is typing in stuff, that's where this can come in. We handle that case, if there is no value at this point, we know there was an error. We'll send the submission back, which will include all of the errors.

[13:47] If we get past that, then we know that things are valid and we have a value. We're going to delete the verification from the database and then we'll go into the session and add the onboardingEmailSession, so we know which user is being on-boarded in this process. What email it is that they have? They verified this email, this is theirs. Now, we can onboard them with that email.

[14:12] That is the entire process. The forgot password is very similar thing. We create that one-time password right here and send that as part of the email and everything. When they land on this page, we can check it in the loader, as well as in the action, if they manually type it in.

[14:36] You might be looking at this and thinking, "There may be an abstraction there and it's possible." There is a good one. I did play around with it for a second and it didn't feel we're quite there with a nicer abstraction. It's nice to be able to customize this very specifically.

[14:53] That is the one-time password support in the Epic Stack. It is awesome and paving the way for us to do two-factor authentication. I hope that you give this a shot in your own applications. It strikes a great balance of security and ease of use like complexity. I feel confident about it and I hope that it's helpful to you. See you.

More and more people are finding adding additional layers of security for their applications is a must. Two factor authentication is a standard security measure for applications to help users be more secure when logging into your application or when performing important or destructive operations. That said, it's nontrivial to build.
So it's included by default in the Epic Stack! Check out the user workflow for this feature that's increasingly becoming table stakes for modern web applications.

A Two Factor Authentication implementation has been added to the Epic Stack. Check it out!

Kent shows us the workflow for the new two-factor authentication support in the Epic Stack.

Two Factor Auth is Included in the Epic Stack

Kent Dodds: [0:00] The Epic Stack now has two-factor authentication built in. If you create a brand-new Epic Stack project and then go login, we have a seed script that creates a user called, Kody. I'll log in as Kody, Kody loves you.

[0:13] Login and now if we go to Kody's profile and go to edit profile, we can click on Enable 2FA, two-factor authentication. Here we can read about what that is all about. We click on Enable 2FA and now it's going to give us the QR code, it gives us the long passcode that you would expect. Of course, this will be your domain name, it won't be local host, all of that.

[0:37] Here, I've got one password. I'm going to edit this and we'll add a one-time password. With this I can actually just click this to scan the QR code that's on the screen. We'll save that and now I've got a one-time password. I'll copy that and paste it right here, hit confirm and now we have two-factor authentication enabled.

[0:58] Now, if I come out of my user account and log in again, Kody and Kody loves you, it's going to ask me for my two-factor authentication code. Awesome! I'll copy that, paste it over here, confirm and I'm allowed in. Then of course we can always disable it if we decide we don't want to have two-factor authentication anymore.

[1:20] All of this entire workflow is completely tested with an end-to-end test. As you work on the Epic Stack and add features and things, you can know that you're not going to be breaking this important workflow for a super secure Epic Web Application. Hope that helps! See ya!

One of the [guiding principles](https://github.com/epicweb-dev/epic-stack/blob/main/docs/guiding-principles.md) of [the Epic Stack](/epic-stack) is "Include Only Most Common Use Cases" which means we're limited in the amount of things that can be built into the stack. That makes it critically important for examples to be created so people can easily determine what changes are necessary to integrate services and libraries with their Epic Stack applications.
In this tip, Kent will show you the process for adding an example to the Epic Stack so you can both help others learn how to complete the integration and also demonstrate how the integration works to potentially have it included by default. This is the very best way to get something built into the stack.

How to create an Epic Stack example to help others and get new features built into the Epic Stack.

Kent shows how to create an Epic Stack example by adding CSRF protection to the user profile page.

Contribute an Epic Stack Example

Kent C. Dodds: [0:01] You want to get something into the Epic Stack. The best way to do this is by creating an example first. Demonstrate why the change that you want to have happen makes a lot of sense and demonstrate how to make that change happen.

[0:14] The benefit of doing this is that even if it doesn't end up making it into the Epic Stack, at least you'll be able to demonstrate to other people how they can integrate your service or how they can use your library or whatever it is.

[0:27] We're going to do this by adding CSRF protection to our forms in the Epic Stack. Then maybe, eventually, that will land as a built-in part of the stack. I want to show you how to create an example that is really effective at demonstrating to myself and to others why the changes that you want to make are a good idea and how to make those changes.

[0:55] We'll follow the instructions here. We're going to create a new Epic Stack application. By doing this, we'll go into our terminal right here. We'll say create this Epic Stack app. Let's open this up here. Let's call this epic-stack-with-csrf, or you could say, "csrf-example," whatever.

[1:26] There's this "with" prefix that is not important. I don't really care what you call this repo. This is going to be on your own GitHub repository when it's added to this. Have it be whatever you want it to be. It's fine.

[1:41] We'll speed this up here really quick. Because this is just an example and we don't really care to have it deployed -- it doesn't actually need to be deployed to be a useful example -- we're not going to deploy it. I'm just going to say no here.

[1:56] Now, the first thing that we're going to do is we'll say, "cd" into our epic-stack-with-csrf. We'll look at our git status. It's not a git repo. We're going to git init. Now we'll git add everything and commit with init.

[2:14] This part is actually really important because it allows people to see just the changes that you made to the Epic Stack to add your features. We want to make an initial commit right after we've set up the repo.

[2:29] Then we're also going to open up our editor right here. Because we don't actually want to deploy, we're going to turn off the deploys right here. Let's just comment this out. We'll add another commit, git commit disable deploys. You could also do that as part of your init commit if you want to. That's not all that important there.

[2:55] Just the point is that you want to make sure that there are very specific commits that are relevant to the changes that you're making. You could even make multiple commits for each step if you want to, but for this particular example, we'll just make a single commit.

[3:09] As interesting as this is, I'm actually going to skip this for us so that you can skip to the end. At this point, you're just going to make whatever changes you need to make for your example to be working. Then you'll join back up with me when it's time to do your docs.

[3:23] Once you've finished, you want to make sure of two things. One, that you've only changed as much as necessary for your specific example. Don't add a bunch of tangentially related things because it could distract from the main purpose of the example. Try to focus on what the example is actually demonstrating.

[3:40] The second one is make sure that you're actually testing the changes that you're making. If that involves writing automated tests, then that's awesome. If that involves running the automated tests that we have, also awesome. There should be GitHub workflows for running the automated tests as well. That's helpful too.

[4:00] Then, of course, you want to manually test things to make sure that things are working. Once you've verified that everything has changed the way that you want to, you can take a look at the git diff and make sure that you haven't changed more things than you actually expect.

[4:12] Then you can write some documentation, just a little bit of an explanation of what the example is all about. If you take a look at the existing examples that we have, you can see that the documentation does not have to be really well spelled out or anything necessarily.

[4:30] It just needs to be relatively basic on the steps needed to accomplish the task because a lot of the benefit actually comes from people looking at the commit history and saying, "Oh, OK. So here is the commit, and here are the things that they changed to bring Framer into the Epic Stack," for example.

[4:49] For us, we're just going to delete all of this stuff. We'll give this the title of "Epic Stack with CSRF Protection." Then we write out some documentation, which I will do now. Awesome. Now we've got the docs. This is just enough for people to be able to follow along, look at the commit history, and see the changes that were necessary.

[5:11] In some cases, that might be quite a bit, especially if it involves infra stuff so you need to set secrets and stuff. In other cases, it's just a couple simple steps. Whatever it is, you have the documentation that makes it easy for people to integrate and also easy for me to take a look at and determine whether I want to bake that into the Epic Stack as a built-in part of the stack.

[5:32] Now we simply need to create a repo. You can go to repo.new and create the repository here. We're going to call it epic-stack-with-csrf. This will be under myself. An example of the Epic Stack with CSRF protection on forms. Then we create that repository. We follow the instructions for pushing an existing repository.

[6:04] Let's make sure we look at the status, git add everything. We'll commit this as "Add CSRF protection with remix-utils." Then we can copy this and paste that. Now we've got the Epic Stack with CSRF on here.

[6:23] Another thing that you should do is add a topic for the epic-stack and epic-stack-examples, or example, singular. Because what this will do is it will add your example to the topic on GitHub so that people can look at this topic and see all of the examples really easily, in addition to those that are listed in the examples docs on the Epic Stack.

[6:49] The last step is to come into the examples and just hit the little pencil icon. This will fork the repository for you and simply add another line to the bottom of this. Now we'll commit the changes. For you, you're going to be committing to your own repo. I'm going to create a branch to kind of simulate that sort of thing. You can feel free to elaborate here if you like.

[7:15] For examples, I can just kind of look at things and know. No test plan is necessary. The checklist doesn't matter. Screenshots would be useful for different things. In our case, the CSRF thing, there's nothing really to screenshot. Definitely useful if what you're doing involves some sort of UI or some terminal output. Something like that could be very useful here as well.

[7:39] I'm going to just clear all that out. We'll just create the pull request. Then you'll get it merged. Then I'll come in here. I'll merge it. I'll be like, "Thanks. You're awesome."

[7:47] Thank you for taking the time to create an example. It helps a ton, just an enormous amount, for me when evaluating different things that I want to have built in and for other people who want to be able to use those things today without waiting for it to get built in. I hope that helps. Thank you so much. We'll see you later.


Users of your website can customize their device to a dark or light theme. As a web developer you're in control of everything visible within the viewport, but your control outside of that is limited. The favicon for your website should be appropriate for the user's system preference.

Learn how to customize the favicon based on the user's system preference for light mode. This builds on top of the work we have in the Epic Stack for Client Hints (learn more from ["Use Client Hints to Eliminate Content Layout Shift"](/tips/use-client-hints-to-eliminate-content-layout-shift)).

Create a responsive favicon that adapts to the user's system preference for light or dark mode.

Tips

A collection of valuable Web Development tips.