[00:00] All right, let's get some good dad jokes in here. Come on. Let's get some really good ones new joke You can't run through a campsite. You can only ran because it's past tense Yeah, yeah, I'm good with that. That one's good.

[00:15] What do you call a pig with three eyes? Pig. These are hilarious. Why can't a bicycle stand on its own? It's too tired.

[00:24] Oh, that's good. That's good. I should submit a joke. You know, you can submit jokes. That's pretty cool.

[00:30] Let's get one more. How much does a hipster weigh? An Instagram, oh my gosh. That's great, yeah, that one's good. Right, Cody?

[00:38] Yeah, that's hilarious. Good stuff. I hope that Cody's been fun and helpful to you as you've been working through this material. And Cody's a little hand-holding, he likes to be hand-holding, but you are learning stuff as you're going through, even though Cody is telling you where and what to do. I definitely, if you're doing that elaboration and feedback section of each one of these exercises then you will remember this stuff and that's what's really important.

[01:08] So hopefully this gave you a little bit of a laugh, a chuckle to carry you on into the rest of the exercises. So keep it up, you're doing great, and we'll see you around on Epic React.



Test Post With Video

> "Why can't I just use try/catch in my React components?" If you've ever asked
> this, you're not alone! Let's dig into why React error boundaries exist, how
> they work, and why they're not just a fancy try/catch block for your UI.

## The Problem: Errors Happen (and try/catch Isn't Enough)

No matter how careful you are, things will go wrong in your app. Maybe a network
request fails, a typo sneaks in, or a third-party library throws a fit. In plain
JavaScript, you might reach for `try/catch`:

```js
try {
	// Something that could error
	doSomethingDangerous()
} catch (error) {
	// Handle the error
	showErrorToUser(error)
}
```

But in React, things are a bit different. When you write JSX like this:

```jsx
const element = (
	<div>
		<h1>Calculator</h1>
		<Calculator left={1} operator="+" right={2} />
		<Calculator left={1} operator="-" right={2} />
	</div>
)
```

React doesn't actually _call_ your `Calculator` function when it creates this
element. It just creates a description of what should be rendered. The real work
happens later, when React walks the tree and calls your components. That's why
you can't just do this:

```jsx
try {
	const element = (
		<div>
			<h1>Calculator</h1>
			<Calculator left={1} operator="+" right={2} />
			<Calculator left={1} operator="-" right={2} />
		</div>
	)
} catch (error) {
	// This won't catch anything!
}
```

If you try to wrap your JSX in a `try/catch`, you'll only catch errors that
happen during the creation of those elements—not when React actually renders
them. The real errors happen _inside_ your components, during rendering,
effects, or event handlers.

You _could_ do this:

```jsx
function Calculator(props) {
	try {
		// ...render logic
	} catch (error) {
		return <div>Oh no! An error occurred!</div>
	}
}
```

But that's a nightmare to maintain. Imagine adding this boilerplate to every
single component! Plus, it doesn't help with errors that happen deeper in the
tree, or in lifecycle methods, or async code.

## Enter: Error Boundaries

React introduced
[error boundaries](https://react.dev/reference/react/Component#catching-rendering-errors-with-an-error-boundary)
to solve this. An error boundary is a special kind of component that _catches_
errors anywhere in its child component tree, logs those errors, and displays a
fallback UI instead of crashing the whole app.

Here's a minimal error boundary:

```jsx
class ErrorBoundary extends React.Component {
	state = { error: null }
	static getDerivedStateFromError(error) {
		return { error }
	}
	render() {
		if (this.state.error) {
			return this.props.fallback
		}
		return this.props.children
	}
}
```

And you use it like this:

```jsx
<ErrorBoundary fallback={<div>Something went wrong!</div>}>
	<MyComponent />
</ErrorBoundary>
```

Now, if `MyComponent` or anything it renders throws during rendering, React will
show your fallback UI instead of a blank screen.

Right now, only class components can be true error boundaries because they use
the special static method `getDerivedStateFromError`. There's no direct
equivalent in function components (yet!). That's why libraries like
[`react-error-boundary`](https://github.com/bvaughn/react-error-boundary)
exist—they give you a nice API and let you use hooks to interact with error
boundaries.

## But Wait! What About Async Errors?

Error boundaries only catch errors during rendering, (legacy) lifecycle methods,
and constructors. They _don't_ catch errors in event handlers, async code, or
effects. For those, you need to surface the error to React yourself.

Here's how you might do it with
[`react-error-boundary`](https://github.com/bvaughn/react-error-boundary):

```jsx
import { useErrorBoundary } from 'react-error-boundary'

function MyComponent() {
	const { showBoundary } = useErrorBoundary()

	async function handleClick() {
		try {
			await doSomethingAsync()
		} catch (error) {
			showBoundary(error)
		}
	}

	return <button onClick={handleClick}>Do something</button>
}
```

## Localized Error Handling: Like try/catch, But Declarative

You can nest error boundaries anywhere in your component tree, just like you'd
nest try/catch blocks in code. This lets you show different fallback UIs for
different parts of your app:

```jsx
function App() {
	return (
		<div>
			<ErrorBoundary fallback={<div>Something went wrong with the list.</div>}>
				<List />
			</ErrorBoundary>
			<ErrorBoundary
				fallback={<div>Something went wrong with the details.</div>}
			>
				<Details />
			</ErrorBoundary>
		</div>
	)
}
```

## Resetting and Recovering from Errors

Sometimes, errors are temporary. Maybe the user lost their internet connection,
or a form submission failed. With `react-error-boundary`, your fallback
component can offer a "Try again" button:

```jsx
function ErrorFallback({ error, resetErrorBoundary }) {
	return (
		<div role="alert">
			<p>Something went wrong:</p>
			<pre>{error.message}</pre>
			<button onClick={resetErrorBoundary}>Try again</button>
		</div>
	)
}

const element = (
	<ErrorBoundary FallbackComponent={ErrorFallback}>
		<MyComponent />
	</ErrorBoundary>
)
```

## Logging and Analytics

Error boundaries can also help you log errors for analytics or debugging. Use
the `onError` prop with `react-error-boundary`:

```jsx
<ErrorBoundary
	FallbackComponent={ErrorFallback}
	onError={(error, info) => {
		// Send error to your logging service
		logErrorToService(error, info)
	}}
>
	<MyComponent />
</ErrorBoundary>
```

## Conclusion

- Error boundaries are _not_ just try/catch for React—they're a declarative,
  component-based way to handle errors in the UI.
- They only catch errors during rendering, lifecycle methods, and
  constructors—not in event handlers or async code.
- Use libraries like
  [`react-error-boundary`](https://github.com/bvaughn/react-error-boundary) for
  a modern, ergonomic API.
- Place error boundaries thoughtfully to give users the best possible experience
  when things go wrong.

---

Want to learn more? Check out the
[Epic React Fundamentals workshop](https://www.epicreact.dev/workshops/react-fundamentals/intro-to-error-boundaries)
and the
[react-error-boundary docs](https://github.com/bvaughn/react-error-boundary) for
deeper dives and more examples.


A deep dive into how React error boundaries work, why they're different from try/catch, and how to use them effectively in your apps.

Why React Error Boundaries Aren't Just Try/Catch for Components

Did you know React Router is adding React Server Components support? It's still
experimental, but it's very close to landing, and I think React Router's take on
RSC is really great. Here's what you need to know.

## Enabling React Server Components

The first step is to enable RSC in your React Router app. You'll need to install
two plugins:

1. The React Router RSC plugin from `@react-router/dev/vite`
2. The RSC plugin from `@vitejs/plugin-rsc`

Here's how to update your `vite.config.ts`:

```tsx
import {
	reactRouter,
	// unstable_reactRouterRSC as reactRouterRSC,
} from '@react-router/dev/vite'
import tailwindcss from '@tailwindcss/vite'
// import rsc from '@vitejs/plugin-rsc'
import { defineConfig } from 'vite'
import devtoolsJson from 'vite-plugin-devtools-json'
import tsconfigPaths from 'vite-tsconfig-paths'

export default defineConfig({
	server: {
		port: process.env.PORT ? Number(process.env.PORT) : undefined,
	},
	plugins: [
		tailwindcss(),
		tsconfigPaths(),
		// Replace reactRouter() with:
		// reactRouterRSC(),
		// rsc(),
		devtoolsJson(),
	],
})
```

So much of what makes RSC work is the integration with the bundler. A lot of the
heavy lifting comes from the Vite team, with significant contributions from the
React Router team.

Once you've enabled RSC, you'll also need to remove the `Scripts` component from
your root layout. With RSC, those scripts are included as part of the RSC
payload automatically:

```tsx
import {
	isRouteErrorResponse,
	Links,
	Meta,
	Outlet,
	// Remove this Scripts import
	// Scripts,
	ScrollRestoration,
} from 'react-router'

// ... other code ...

export function Layout({ children }: { children: React.ReactNode }) {
	return (
		<html lang="en">
			<head>
				<meta charSet="utf-8" />
				<meta name="viewport" content="width=device-width, initial-scale=1" />
				<Meta />
				<Links />
			</head>
			<body>
				{children}
				<ScrollRestoration />
				{/* Remove this Scripts element */}
				{/* <Scripts /> */}
			</body>
		</html>
	)
}
```

## RSC in Loaders

Now that RSC is enabled, what can you do with it? One powerful pattern is
returning UI from your loaders instead of just data.

Here's a traditional loader that returns data:

```tsx
export async function loader() {
	const movies = await getMovies()
	return { movies }
}

export default function MoviesPage({ loaderData }: Route.ComponentProps) {
	const { movies } = loaderData

	const moviesUI = movies.map((movie) => (
		<MovieCard key={movie.id} movie={movie} />
	))

	return (
		<main>
			{/* ... */}
			<div className="grid grid-cols-1 gap-6 md:grid-cols-2 lg:grid-cols-3">
				{moviesUI}
			</div>
		</main>
	)
}
```

The problem with this approach is that we're sending data to the client that we
don't actually need once it's been rendered. We're hydrating data unnecessarily.

With RSC, you can return the completed UI from your loader:

```tsx
export async function loader() {
	const movies = await getMovies()

	const moviesUI = movies.map((movie) => (
		<MovieCard key={movie.id} movie={movie} />
	))

	return { moviesUI }
}

export default function MoviesPage({ loaderData }: Route.ComponentProps) {
	const { moviesUI } = loaderData

	return (
		<main>
			{/* ... */}
			<div className="grid grid-cols-1 gap-6 md:grid-cols-2 lg:grid-cols-3">
				{moviesUI}
			</div>
		</main>
	)
}
```

Now you're just serving UI from the server without sending any of the underlying
data. This is especially powerful if you're pulling data from a CMS where you
don't know what UI you need to render before you have the data. Instead of
dynamically loading components (leading to spinners) or loading all possible
components upfront, you can make that determination in the loader and send the
resulting UI, making your payload way smaller.

## RSC Routes

But wait—if the entire page could be a server component, why use a loader at
all? You can make the entire route a server component:

```tsx
import { MovieCard } from '#app/movie-card.tsx'
import { getMovies } from '#app/movies-data.ts'

export async function ServerComponent() {
	const movies = await getMovies()

	const moviesUI = movies.map((movie) => (
		<MovieCard key={movie.id} movie={movie} />
	))

	return (
		<main className="bg-background min-h-screen">
			{/* ... */}
			<div className="grid grid-cols-1 gap-6 md:grid-cols-2 lg:grid-cols-3">
				{moviesUI}
			</div>
		</main>
	)
}
```

Notice that we're exporting a named `ServerComponent` function instead of a
default export. This means we don't need the loader at all—we can directly get
the data inside the component itself because it's a server component.

The entire UI is rendered on the server, sent to the client, and not hydrated
because there's no interactivity. This makes types simpler too—no need for
loader data types.

## Incremental Migration

One of the most powerful aspects of React Router's RSC implementation is that
you can migrate incrementally. If you have nested routes, a child route can be a
client route, and that can have a child that's a server route. They don't have
to know about each other.

This means if you're working on a big application with different teams in charge
of different routes, one team can decide to make their portion an RSC route
without the rest of the app having to change. This makes incremental migration
really possible and really powerful.

## Server Functions

React Router has always had actions, but React now has form actions as a
primitive. With RSC, you can use React's form actions directly with server
functions.

Here's how you can create a server function:

```tsx
'use server'

export async function setIsFavorite(formData: FormData) {
	// Simulate API call delay
	await new Promise((resolve) => setTimeout(resolve, 50))

	const movieId = Number(formData.get('id'))
	const isFavorite = formData.get('isFavorite') === 'true'
	// Update the movie's favorite status
	const movie = movies.find((m) => m.id === movieId)
	if (movie) {
		movie.isFavorite = isFavorite
	}
}
```

The `'use server'` directive says that the things exported from this module can
be referenced in the client. When the form action is called, it makes an RPC
call to the server to actually call this function.

Then you can use it directly in your form:

```tsx
<form action={setIsFavorite}>
	<input type="hidden" name="id" value={movie.id} />
	<input
		type="hidden"
		name="isFavorite"
		value={String(!movie.isFavorite)}
	/>
	<button type="submit">
		{movie.isFavorite ? 'Favorite' : 'Not Favorite'}
	</button>
</form>
```

Why is this cool? With React Router, all actions and loaders are tied to a
route. But if you use React's form actions with server functions, they can be
tied to a component. You could take this form, make it a component all by
itself, and reuse it all over the place—on the details page, on cards, in a chat
feature, anywhere.

The status quo for doing this with React Router before RSC was having to find
the closest route for all of those and have an action on every one of those
routes. With RSC, you don't have to do that. A component can manage its own data
loading and data mutations. You could even publish it on npm, and anybody who
supports RSC would be able to use your component.

## Client Components

Of course, sometimes you need interactivity. That's where client components come
in. If you're using hooks like `useState` or `useEffect`, you need to mark that
component as a client component:

```tsx
'use client'

import { Activity, useEffect, useState } from 'react'
import { type Movie } from '#app/movies-data.ts'

export function MovieTrailer({ movie }: { movie: Movie }) {
	const [showTrailer, setShowTrailer] = useState(false)
	// ... rest of the component
}
```

The `'use client'` directive says that this code needs to go to the browser
because it has state or other client-side logic. It still server renders, but it
also sends that code to the client to make it interactive.

The really cool thing is that you can use client components inside server
components without changing anything about the server component. The server
component doesn't need to know that the client component exists—it just works.

## Who Does This Help?

RSCs in loaders are really helpful if you're building something like a big
timeline that has many, many combinations of different components that could
possibly be used, and you don't know which one until you have the data. That's
perfect for RSCs in loaders and RSC routes.

For everybody else, it's a nice handy thing. I should call out that sometimes
the combination between data and template together will actually be bigger than
just data and template separate—it kind of depends on the scenario. But for most
people, just using RSCs and RSC routes makes a lot of sense.

The cool thing about React Router is that you don't have to completely switch
over. You can migrate incrementally as you see that being a really beneficial
thing. Aside from the fact that you can also do your data loading right in the
components, so types are a lot better, and you can use Suspense boundaries and
all of that stuff as well.

Server functions are super useful for those of you who have components that need
to have data loading and data mutation associated to them. And now you can just
put those all over the place.

Client components, of course, are only really useful if you are using server
components. If you're not turning your routes or different components into
server components, you're not going to be using client components. Your entire
app is still client components. But if you decide RSC is really the way that you
want to go, then client components are the way you want to go.

## Static Builds

One more thing I should mention: you can actually still do a static build of a
React Router app with Server Components. That is part of the design of React
Server Components. You should be able to still get some of the benefits of RSC
with being able to deploy this to a static environment. You don't necessarily
need a server to use React Server Components—the server can be the build server.

## Summary

React Router's implementation of React Server Components is really well done. It
supports:

- **RSC in the bundler** - Enable RSC with Vite plugins
- **RSCs in loaders** - Return UI from loaders instead of data
- **RSC routes** - Make entire routes server components
- **Server functions** - Use React's form actions with `'use server'`
- **Client components** - Mark components that need interactivity with
  `'use client'`

All of these are supported in React Router, and the incremental migration path
makes it really powerful for teams working on large applications. For the use
cases that React Server Components serves really well, I think this is really
good.


React Router is adding React Server Components support! Learn how to enable RSC, use server components in routes and loaders, and leverage server functions.

[00:00] Hey, my name is Kent C. Dodds, and I want to talk about React Router's take on React Server Components. This is going up on EpicReact.dev, and that's where we teach you all about React, and we really hyper-focus on React over there, so you can get really, really good at React. But React Router is the most popular React framework around and React Router is finally adding React server component support. It is still technically an experimental feature, but we're very, very close to this actually landing, and by the time you watch this video, it's very possible that this has already landed in React Router, and I think that it's a really great take.

[00:41] So if you are convinced that React Server components are something that your app needs, This talk is for you. So let's jump into the demo right from the get-go. So our demo is actually a pretty simple movie collection app. You can click on these different things. We've got these nice view transitions and stuff for things moving around, and you can watch the trailer.

[01:03] And man, these movies are so good. But that's pretty much it. That's the entire app, the entire demo. But it is a React Router app, so we got routing going on in here. And it is using Vite, which is the latest recommendation from the React router team.

[01:23] So let's see what it would take to take this traditional React router application and make it work with React server components. First thing we need to do after installing the proper versions and everything is bring in the currently unstable React Router RSC plugin from React Router Dev Vite. And we also need to bring in the RSC plugin from Vite.js slash plugin dash RSC. And honestly, so much of what makes RSC RSC is the integration with the bundler. And so a lot of the work and a lot of the thanks needs to go to, of course, the React Router team who contributed a lot to Vite, but also really the Vite team, because that's where a lot of the heavy lifting from this is coming from.

[02:11] But of course, there is the React Router direct integration. So that's why we need both plugins. And then we're going to replace the React Router plugin with the React Router RSC plugin, and we're going to bring in the RSC plugin from Vite. And with that now, we can save that, and Vite automatically restarts because it detects that change in our Vite config. And we are now running RSC on this page.

[02:35] Actually, if you take a look at the console here, we'll see the scripts element is a no-op when using RSE and can be safely removed. So, let's go ahead and we'll do that as well. We'll go to our root TSX. We're going to remove the scripts import, and we're going to come down here to our scripts element. We're going to get rid of that.

[02:53] That's a standard thing you need in React Router applications, that scripts that includes all of the JavaScript to get that onto the page and things. We don't need that with RSC because those scripts are going to be included as a part of the RSC payload. And so we don't need to worry about including those manually. So with that, now I can open up the console And yep, we're all set. No errors here.

[03:19] And so now that we have RSC on this page, what can we do with that? Well, let's go to the index right here. And we've got this movies UI right here that doesn't have any interactivity. There's nothing going on in this page. And we're going through all of the trouble of getting the data in our server.

[03:36] The loader only runs on the server. We go get the data, and then we send it to the client. And of course, we're server rendering, so we hydrate and everything. We're sending that data to the client, but we don't actually need that data once it's been rendered. And so hydrating it is completely unnecessary.

[03:52] So really, I want to take this UI. I want to move it to the server. And so how do we do that? Well, we literally move it to the server. That's it.

[04:01] We've just moved our UI into our loader and now instead of returning the data we're going to return the completed UI and then we can come here and say our movies UI comes from the loader data. We don't need to send the data at all. We just send the completed UI and boom, I don't know how to prove it to you more that this is just a UI, but now it's just serving UI from the server and it doesn't send any of the data. That can be really, really useful for you. And again, I don't want to spend a whole lot of time talking about why RSCs are so great.

[04:36] I'm assuming that you already kind of believe that. But just as an example, if you're pulling this data from a CMS and you don't know what UI you need to render before you have the data, then you only have a couple of options. You can either dynamically load the UI based off of the data, which is going to lead to a whole bunch of spinners, or you can just load all thousands and thousands of components that could possibly maybe be used up front so you don't have to load them on demand. Both of those are not optimal. But with RSC now you can make that determination in the loader and then just send the resulting UI, making your payload way smaller and even the logic for that is way simpler.

[05:19] So this is a huge win for anybody in that scenario. Now, here's the interesting thing. If we look at the rest of the UI, well, there's not really all that much going on in here at all. So in fact, this entire page could be a server component. And so that's what we're going to do, actually.

[05:39] Let's move this right back. We're going to get rid of the loader entirely, and we're going to say this is an async function called server component. So we're no longer doing the default. We're going to export a named function called server component. This means we don't need the loader data because we can directly get the movies ourselves inside of the component itself, because this is a server component.

[06:05] And with that now, the entire route is a server component. We don't need the loader. Of course, we don't need these types anymore. So types get a little bit easier. The entire UI is going to be rendered on the server, sent to the client, and not hydrated because there's no interactivity going on here.

[06:22] Now, I know we're going to talk about how to make some things interactive here in a second, but this is a really powerful thing as well. This demo doesn't fully demonstrate the power here because we're not using really anything by way of nested routing. But if we had an outlet in here, the child component or the child route could actually be a client route. And then that could have a child that is a server route. And so because you can nest these things however you like, and they don't have to know about each other, this means that if you're working on a big application and you've got one team that's in charge of the root route and other teams that are in charge of different portions of the application, different routes themselves, well, now you can actually just decide, okay, for our team, for our part of the application, we're going to make this an RSE because we're ready, we're using the latest of whatever and everything is working great for us.

[07:16] So we're just going to turn our portion into RSE, and the rest of the app doesn't have to change for that. This makes the incremental migration path really possible and really powerful. So I'm very excited about what the React router team did to make that possible. And making an entire route a server component, I think, is super powerful. So, let's go on.

[07:38] Let's see. A lot of these movies are just fantastic movies. K-pop Demon Hunters, particularly, that's pretty cool. So, let's dive into this one. We're going to go to our movie details route here.

[07:52] And here's our movie details page. I've got an action right here. And React actually now has a feature specifically for actions. And that is form actions. So before React Writer or Remix version 1 came with this idea of actions, and we're using that here in React Writer version 7, but React since then has introduced the idea of actions as a part of their primitive for forms.

[08:24] And so this set is favorite, all it does is take some form data and it performs a mutation and all of this is, you know, smoke and mirrors, whatever. But this is basically a React action, and so we can just set isFavorite directly on our form. So what if we say lowercase form, Instead of a method post, because React will handle that for us, we're going to say our action is set as favorite. And then we can completely get rid of this action and get rid of this uppercase form thing. We'll save this.

[08:57] We'll refresh. And we'll click on or unclick favorite. And that's not working. And the reason it's not working is because we need to mark our module here as being server. So use server, user server.

[09:13] What this does is it says, hey, the things that are exported from this module can be used in the client or referenced in the client. And so they will create a reference to this function for us and then reference that in the client. And so when the form action is called, it will then make effectively an RPC call to the server to actually call this function. And if you go through the React server components workshop on epicreact.dev, you'll understand how all of that wiring works. But this is all we need to do to be able to toggle the favorite state.

[09:48] And we don't have to use a React router-specific primitive for this. We can rely on React. Why is this cool? Well, with React router, all of the actions and loaders, those are all going to be tied to a route. But if you just use React, then it can be tied to a component.

[10:08] And so where's my form? There we go. We could take this form, we can make it a component all by itself, and then we could reuse that all over the place. So now you can have a Favorite button next to, or on the details, you could have it on the cards, on this one other page. You could have even like a Favorite if you have a chat feature and you have a little card, you could put a Favorite in there.

[10:30] You can put it anywhere. And the status quo for doing this with React Router before RSC was having to find the closest route for all of those and have an action on every one of those routes. Or you can follow the full stack component pattern that I made or popularized or came up with where you have a component that is actually a route and you export that component, then you can use it everywhere. But that suffers from a number of problems, One of them being the initial state. How do you get whether it's initially favorited or not?

[11:05] Well, with that, you have to find the nearest loader, which again is the route boundary. With RSC, you don't have to do that. You could turn this into a component. It can manage its own data loading and its own data mutations. That's really powerful.

[11:17] And then let's take it even further. You could publish it on NPM, and anybody who supports RSC would be able to use your favorite button. I think that is a really powerful pattern. Very excited about React Router supporting that portion of React server components or form actions. Okay, great.

[11:37] So, you know what? We actually also have the loader thing in here. I think it makes sense for us to put the entire movie details page and everything as a server component. So let's follow the same pattern. We're going to exportAsync function called server component.

[11:53] We'll get rid of the loader data. We'll move this movie thing down here, get rid of our loader. We do still need our params from the prompts there, so that's fine. And yeah, let's save that. Ooh, uh-oh, useState is not a function or its return value is not iterable.

[12:12] Now, if you've gone through the workshop, through the React router or the React server components workshop, you'll know exactly what's going on here. What that is, is that during the RSC payload generation phase, in that bundle, there's a special version of React that doesn't support useState and useEffect and various other hooks because those don't make sense in that environment. And so we need to have some mechanism to say, hey, no, this portion, this actually only needs to be a client route. It needs to only support the client version of React because we're using useState. So that's coming from our movie trailer right here.

[12:51] This is using useState. So we need to say, hey, I need this code to go to the browser because we actually have some state going on here with our toggle between whether the trailer's being shown or not. So let's add use client, user client. I do that every time, use client. There we go, save that.

[13:08] And now if we watch the trailer. Oh snap, I got you, ha ha. All right, so that is working now. And here's the really cool thing about this, is that I'm able to create this as a server component. And there's our movie details.

[13:27] And it supports server actions. So it actually can be interactive in such a way that it is performing mutations. And it can be interactive in such a way that it's doing client-side interactions as well. And I didn't have to change anything about the server component or how it's using the movie trailer for this to work. I simply changed the movie trailer to say, hey, this has code in it that needs to run in the client.

[13:52] Please send this code to the client. And it's still able to server render, so the use client isn't specifically about that. But it also sends that code to the client. It makes it interactive so that we can have this portion of the code be interactive inside of our client. So that's it.

[14:12] That is React Server Components working in React Router. So let's talk about the last couple of things. We talked about enabling RSE in the bundler, RSEs in loaders, RSE in routes, server functions, and client components. All of these are supported in React Router and it's phenomenal For the use cases that React server components serves really well, I think that this is really good. So who does this really help?

[14:38] I think RSCs and loaders, really, really helpful if you're building a big timeline that has many, many combinations of different components that could possibly be used, and you don't know which one until you have the data. That is perfect for RSCs in loaders and RSC routes. And then for everybody else, it's just kind of like a nice little handy thing. I should call out specifically, though, that sometimes the combination between data and template, you stick those together, that payload will actually be bigger than just data and template separate. It kind of depends on the scenario.

[15:18] I would say, though, for most people, just using RSCs and RSC routes makes a lot of sense. So probably default to that. The cool thing about React Router is that you don't have to completely switch over. You can migrate incrementally as you see that being a really beneficial thing. Aside from the fact that you can also now do your data loading right in the components, so types are a lot better, everything, it's quite nice.

[15:43] And you can use suspense boundaries and all of that stuff as well. Server functions, that is super, super useful for those of you who have components that need to have data loading and data mutation associated to them. And now you can just put those all over the place. Really, really powerful right there. And then client components, of course, are only really useful if you are using server components.

[16:06] And so if you're not turning your routes or different components into server components, you're not going to be using client components. Your entire app is still client component. But if you decide, OK, no, RSC is really the way that we want to go, then yeah, Client Components are the way you want to go. The other thing I should mention here too is you can actually still do a static build of React Router app with Server Components. That is part of the design of React server components.

[16:34] And then you should be able to still get some of the benefits of RSC with being able to deploy this to a static environment. So if that's you, then don't tune all of this stuff out. Go look into how you can make that work because it's definitely a design feature of RSC. You don't necessarily need a server to use React server components. The server can be the build server.

[16:57] Okay, with that, I just want to say that you're splendid. Thank you so much for joining me, and definitely take a look at Epic React if you want to get really good at React. Also Epic AI Pro if you want to get really good at AI and MCP, which is I think the future of user interaction. And if you want to go full stack, epicweb.dev is your place. And we're going to be doing a bunch of stuff in React Router over there as well.

[17:21] And everything that's Remix version 2 is all on there already, and so much of that is React Router version 7. So take a look at those things. Thank you so much for watching and we'll see you around on the internet.



React Router's take on React Server Components

[Ricky Hanlon posted on Bluesky](https://bsky.app/profile/ricky.fm/post/3lpi3jj3jqc2s):

> what's wrong with this code:
>
> ```jsx
> if (props.wrap) {
> 	return <Wrapper>{children}</Wrapper>
> }
>
> return children
> ```

A lot of people didn't get it right away. In fact, it took me a moment thinking
about it as well, but then
[I replied](https://bsky.app/profile/kentcdodds.com/post/3lpi4rbteqs2g):

> Does it have to do with what happens when the wrap prop changes?

He said "Yes" and I knew for sure what he was talking about.

Have you ever wondered why your React component's state sometimes disappears or
resets unexpectedly? Or why two identical components don't share state? React's
approach to state is all about _where_ a component sits in the UI tree, not just
what it is. This means that state is preserved as long as the same component is
rendered at the same position—but if you swap components, change their keys, or
move them around, React may reset their state.

A common pitfall: toggling between two components (like two players in a
scoreboard) using different keys or types will reset their state every time you
switch. This is often _not_ what you want, especially if you expect the UI to
"remember" previous input or progress. The React docs show how this can trip you
up, and why relying on position and keys for state can be sub-optimal if you're
not careful.

If you've ever been surprised by disappearing form input or state that doesn't
persist the way you expect, this article is for you. It covers:

- How React decides when to preserve or reset state
- The role of keys and component types
- Practical tips for controlling state resets (and when you might want them!)

Curious to learn more and see code examples? Check out the full article:
[Preserving and Resetting State – React Docs](https://react.dev/learn/preserving-and-resetting-state)

### Spoiler Alert: How to Fix It

For Ricky's example specifically, if you want to preserve state while toggling
the wrapper, you need to ensure the component tree structure remains stable. One
way is to always render the `Wrapper`, but conditionally apply styling or
behavior:

```jsx
return (
	<Wrapper style={props.wrap ? {} : { display: 'contents' }}>
		{children}
	</Wrapper>
)
```

Or, if you want to avoid an extra DOM node when not wrapping, you can use a key
to intentionally reset state, or lift state up to a parent component so it isn't
lost when the tree changes. The key is to avoid swapping between two different
component trees at the same position if you want to preserve state.

But really, you should just read
[the whole article](https://react.dev/learn/preserving-and-resetting-state).


How React preserves or resets state depends on component position and keys. Learn why state disappears and how to fix it as well as links to more resources!

Preserving and Resetting State in React

When the world moved from React class components and lifecycle methods to React function components and hooks, we left behind a bug that many of us didn't even know was plaguing our class-based codebases. This bug was sneaky, hard to identify and reproduce, and it would pop up in places due to seemingly harmless changes over time. To make matters worse, the situations where it pops up are not always bugs, sometimes it's an intended behavior. So you can't even lint against it.

The bug has to do with the mutability of `this.props`. I'm not talking about _you_ the developer mutating `this.props` (you shouldn't do that). I'm talking about when the parent component re-renders and passes new props, `this.props` suddenly points to completely new values. This is by design. I mean, when your `render` method re-runs due to an update in the props, you don't want to render the old props. You want the latest values so the React elements you return shows the right information.

The problem is actually pretty simple. It typically crops up when you have an event handler or lifecycle method that does something asynchronous. Imagine, you start the async thing, then props change while that is in flight, when your code continues `this.props` has the latest values rather than the values that existed at the time the function started running.

Let's add some clarity to this. I've put together [a little demo](https://react-and-stale-closures.netlify.app) which you can play with below. When you click on the ❤️ button, that'll toggle the liked state, but it has to do an async check to determine whether you're permitted to like/unlike the post. That's hard-coded to take 3 seconds to give you time to experience the problem. The specific use case is irrelevant. What matters more is the fact that `this.props` gets changed from beneath you during that async operation.

So, in the demo below, try this:

1. Click the ❤️ button 2. Before the 3 seconds time is up, change the post selection 3. Observe differences

<ReactAndStaleClosuresDemo />

You should observe that with the broken examples (like "The Old Default with Classes"), the post that's updated is the currently active post.

Here's the code for that post (structured to optimize for minimizing distraction):

```javascript
import * as React from 'react'
import {AppContext} from './provider'
import {canLike} from './utils'
import {PostView} from './post-view'

class Post extends React.Component {
  static contextType = AppContext
  handleLikeClick = async () => {
    if (!(await canLike(this.props.post, this.context.user))) return

    this.context.toggleLike(this.props.post)
  }
  render() {
    return (
      <PostView post={this.props.post} onLikeClick={this.handleLikeClick} />
    )
  }
}

export {Post}
```

The important bit here is the `canLike` utility that takes a while to run. So when you click on ❤️, the code execution "pauses" for a little while before continuing to the `this.context.toggleLike(this.props.post)` call. This means that when you change the active post, `this.props.post` is pointing to the wrong thing and the `toggleLike` call goes to the new post, not the one we were trying to like.

This is easily solved, as demonstrated in the "Simulating The New Default with Classes" example:

```javascript
handleLikeClick = async () => {
  const {post} = this.props
  const {user, toggleLike} = this.context
  if (!(await canLike(post, user))) return

  toggleLike(post)
}
```

Basically, we create a variable for everything our function is going to need before we call the async `canLike` function. That way it doesn't matter what happens with `this.props`, we're always referencing what `this.props.post` was at the time ❤️ was clicked, which is what the user intended.

Oh, and did you notice the other potential bug that the refactor avoided? No? Well you may have noticed that I _also_ destructure `user` and `toggleLike` from `this.context`. This isn't just because I like the convention of destructuring things at the top of the function. It's because if the `toggleLike` function were to change on us during that async call then we may be calling a new version of that function which references a different `user` resulting in that _new_ user liking the post instead of the one who clicked the button.

This bug bit me a few times with class components, so much that I created a convention for myself to always destructure everything I needed from `this.` in a function at the top of the function (like in the solution above).

But wouldn't it be better if we just changed the default? Yup! And that's what hooks did for us!

Here's the code for "The New Default with Hooks" example:

```javascript
import * as React from 'react'
import {useApp} from './provider'
import {canLike} from './utils'
import {PostView} from './post-view'

function Post(props) {
  const {user, toggleLike} = useApp()

  async function handleLikeClick() {
    if (!(await canLike(props.post, user))) return

    toggleLike(props.post)
  }

  return <PostView post={props.post} onLikeClick={handleLikeClick} />
}

export {Post}
```

In this case, we don't need to worry because the `props` our component is called with each render will _never_ change for all functions in the component. This is because each render, all functions are created as brand-new functions. And when a function is created, it grabs a reference to all variables outside of itself and hangs onto it for as long as that function exists.

When a re-render is triggered, a new `props` object is created and passed to our function component. At that time a _brand new_ `handleLikeClick` is created which has reference to the latest version of `props`. But if an old version of that function is still running, it's fine because it still has access to the version of props it was called with to begin with. (If this concept is not sinking in, you can learn more about [how closures work here](https://whatthefork.is/closure)).

One interesting observation is that this example actually has nothing to do with classes vs hooks, but really classes vs function components. But the same could be said of `componentDidMount` vs `useEffect`.

Function components flip the default, and I would argue that it's a good trade that helps us avoid that surreptitious bug.

## Simulate the old default

Just like it's possible to simulate the hooks default behavior with class components, it's possible to simulate the classes default behavior with function components. Here's the code for that example:

```javascript
import * as React from 'react'
import {useApp} from './provider'
import {canLike} from './utils'
import {PostView} from './post-view'

function Post(props) {
  const {user, toggleLike} = useApp()

  const postRef = React.useRef(props.post)
  React.useEffect(() => {
    postRef.current = props.post
  })

  async function handleLikeClick() {
    if (!(await canLike(postRef.current, user))) return

    toggleLike(postRef.current)
  }

  return <PostView post={props.post} onLikeClick={handleLikeClick} />
}

export {Post}
```

Refs allow you to update a value without trigger re-renders. It gives you a similar mutable API to `this.` (when refactoring class components, `useRef` is my go-to for any instance values if I can't simplify things as variables within a single `useEffect`).

Of course, the above example is buggy, so you wouldn't do that. But are there situations where the old default was a good idea? Most certainly! A good example of such a case is a `debounce` function like this one [Yago](https://twitter.com/yagopereiraaz) shared with me during my office hours recently.

Here's a naive implementation of `debounce`:

```javascript
function debounce(fn, delay) {
  let timer
  return (...args) => {
    clearTimeout(timer)
    timer = setTimeout(() => {
      fn(...args)
    }, delay)
  }
}
```

And here's a naive implementation of a `useDebounce` hook:

```javascript
function useDebounce(callback, delay) {
  return debounce(callback, delay)
}
```

Unfortunately, that won't work because you be creating a brand new `debounce`ed version of your function every render which results in the `debounce` `timer` variable being different for each one so the debounce is actually just a `delay` and doesn't actually debounce anything. So let's memoize that:

```javascript
function useDebounce(callback, delay) {
  return React.useMemo(() => debounce(callback, delay), [callback, delay])
}
```

The `callback` and `delay` are required, otherwise you'd end up with a debounce function that can't react to changes in the `delay` and it would always call an old version of the `callback` which would have access to old variables and likely result in bugs.

However, this API means that someone would have to memoize the `callback` otherwise you'd get a new debounce function every render which brings us back to the problem that lead to use memoizing this in the first place:

```javascript
const myFn = React.useCallback(() => {
  // do debounced stuff
}, [vars, i, need])
const debouncedMyFn = useDebounce(myFn, 500)
```

But that's not a great API. This is one situation where the new default as described above doesn't work very well. But we can use refs to get around the problem!

```javascript
function useDebounce(callback, delay) {
  const callbackRef = React.useRef(callback)
  // Why useLayoutEffect? -> https://kcd.im/uselayouteffect
  React.useLayoutEffect(() => {
    callbackRef.current = callback
  })

  return React.useMemo(
    () => debounce((...args) => callbackRef.current(...args), delay),
    [delay],
  )
}
```

Sweet, so now people don't need to worry about memoizing their callback:

```javascript
const myFn = () => {
  // do debounced stuff
}
const debouncedMyFn = useDebounce(myFn, 500)
```

For this kind of use case, we should be safe from the aforementioned bug _and_ we have a nice API to boot. I'm satisfied.

If you're curious of real-world scenarios where people have done this to simulate the old default, we actually build something like this in [EpicReact.Dev's Advanced React Hooks Workshop](https://epicreact.dev/modules/advanced-react-hooks/usecallback-custom-hooks-intro) with a custom `useAsync` hook. Dan Abramov's [`useInterval` blog post](https://overreacted.io/making-setinterval-declarative-with-react-hooks/) does this as well. And [`react-query`](https://react-query.tanstack.com/) does this for your `queryFn`s.

## Conclusion

React made the decision to flip the default from things changing out from under you to relying on closures to preserve the value of variables at the time a function is defined. This helps us avoid non-obvious bugs and instead forces us to confront issues before we ship to production. It can definitely be a little confusing until you have a solid grasp on how closures work. Despite that, this is a good change, and our apps are more bug-free thanks to it. 🚫🐛🚫

The sneaky, surreptitious bug that React saved us from by using closures.

Test Post With Video

Get my free 7-part email course on React!

More Articles

Why React Error Boundaries Aren't Just Try/Catch for Components

React Router's take on React Server Components

Preserving and Resetting State in React

How React Uses Closures to Avoid Bugs