[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

In this post, we’re going to dive deep on how you use modern React APIs for building forms. We will not be using third party libraries or frameworks. Understanding these lower level primitives will unlock them for you when using libraries and frameworks.

I recently heard someone say that web applications are just a skin on top of a database. And that’s actually pretty accurate. Since the beginning of the web, modern web applications have had two sides to them:

1. Users view data
2. Users mutate data

Loading data into a web application is a pretty straightforward proposition. It’s only when we start talking about needing to modify that data and keep things in sync that things get more complicated.

From day 1, HTML supported mechanisms for both of these use cases.

## Viewing Data

This allows the user to navigate to another page to view more data:

```html
<a href="/remix-utah/events/301213597">Remix Meetup June 🏖</a>
```

This *also* allows the user to navigate to another page to view more data, but enables them to control the data that comes back by including the user’s input in the generated URL:

```html
<form action="/remix-utah/events/search">
	<label for="event-search">Query</label>
	<input id="event-search" type="search" name="query" />
	<button type="submit">Search</button>
</form>
```

Let’s say the user types “August” in the input and hits enter. Thanks to the `action` the user would be sent to `/remix-utah/events/search?query=August`. So by default, `<form>` is just like `<a>` with the special ability of allowing the user to provide input.

## Mutating data

For both `<form>` and `<a>`, the navigation is performed via a `GET` request, which makes sense because you’re trying to `GET` data. But what if the user is trying to *modify* the data?

For example, let’s say you want to be able to sign up for an event with `/remix-utah/events/301213597/join`. If we made that endpoint a `GET` then we could do that like so:

```html
<a href="/remix-utah/events/301213597/join">Join Remix Meetup June 🏖</a>
```

This would certainly work (you could even use a `<form>` with a submit button if you wanted. However, this would also open your users up to a potential problem: **accidental or malicious modification of data**. Since `GET` requests are designed to be idempotent (they should be callable repeatedly without observable effects), using them for state-changing actions can lead to unintended consequences.

Additionally, if you made a login form using a `GET` request, then the user submits their password and the URL looks like this: `/login?username=kody&password=kodylovesyou`! The user’s submission is in plain text in plain sight!

This is part of the reason we have `POST` requests and while you can’t make `<a>` use `POST` instead of `GET`, you can do this with `<form>`.

`POST` requests are designed for submitting data to be processed to a specified resource. There’s no feature of HTML that triggers a `POST` request without user interaction, so they can safely be used to change the state of the server, which is perfect for our scenario of joining an event. Here’s how you can use a form to `POST` data:

```html
<form action="/remix-utah/events/301213597/join" method="POST">
	<button type="submit">Join Remix Meetup June 🏖</button>
</form>
```

By using `method="POST"`, we indicate that this form is meant to modify data on the server. The server will then process this request and update its state accordingly, ensuring that the user's intent to join the event is recorded.

### Handling Data Mutations with JavaScript

While traditional form submissions cause a full page reload, modern web applications often use JavaScript to handle these actions asynchronously, providing a smoother user experience.

Here's an example of how you might handle a form submission with JavaScript:

```html
<form id="join-event-form">
	<button type="submit">Join Remix Meetup June 🏖</button>
</form>

<script type="module">
	const form = document.getElementById('join-event-form')
	form.addEventListener('submit', async (event) => {
		event.preventDefault()

		const response = await fetch('/remix-utah/events/301213597/join', {
			method: 'POST',
			headers: { 'Content-Type': 'application/json' },
			body: JSON.stringify({ /* any necessary data can go here */ }),
		})

		if (response.ok) {
			alert('Successfully joined the event!')
		} else {
			alert('Failed to join the event.')
		}
	})
</script>
```

This script intercepts the form submission, prevents the default browser behavior, and instead sends an asynchronous `POST` request to the server. This way, the page does not need to reload, and the user receives immediate feedback on their action.

You may notice the lack of `method="POST"` in this example and that’s because it’s not strictly necessary since we prevent the browser’s default behavior.

While preventing the full page refresh is great, we lose a lot of things the browser does for us automatically when we prevent that default behavior which result in bugs we find in applications all the time.

For example, race conditions and data revalidation. That said, if you have a framework that helps you with those things (like [React Router](https://reactrouter.com/)/[Remix](https://remix.run)), then the effort is worth the improved user experience.

## React Form Actions

Mutations are an important and common part of dynamic web applications. So is linking to different parts of the application. However, mutating data is complicated because as soon as the user has performed the mutation, there are parts of the UI they could be looking at that could be out of date.

Now, to be clear, with a regular browser mutation there isn’t a problem because the full page refresh means the user always sees the latest that the server has to offer. However, if we’re focused on providing the best user experience possible, the full page refresh is unacceptable. But that means we need to update the data on the page after the mutation.

Another thing that complicates both links and forms in client-side applications is managing pending states. By default, the browser will show a spinner (often in place of the favicon), but when we prevent that default behavior we need to think about giving feedback to the user during the transition.

React has a great solution [for transitions](https://react.dev/reference/react/useTransition), but that’s only half of the story for forms. Because of this added complexity, React 19 has a built-in mechanism for handling forms called “actions.”

Just like the action attribute in an HTML form, you use the action prop in a React component. However, in addition to a URL, you can instead provide a function which will be called upon submission of the form.

```tsx
function JoinEventForm() {
	function joinEvent(formData) {
		const response = await fetch('/remix-utah/events/301213597/join', {
			method: 'POST',
			body: formData,
		})

		if (response.ok) {
			alert('Successfully joined the event!')
		} else {
			alert('Failed to join the event.')
		}
	}

	return (
		<form action={joinEvent}>
			<button type="submit">Join Remix Meetup June 🏖</button>
		</form>
	)
}
```

If you’re familiar with React forms using the `onSubmit` prop, I want you to note a few key differences here:

1. There’s no need to add `event.preventDefault` because that’s handled for us by React
2. The `action` is automatically treated as a transition, so anything that happens during the action which trigger components to suspend will be a part of that same transition. More on this in a bit.
3. We can hook into the pending state of this action using `useFormStatus` .
4. React manages errors and race conditions to ensure our form’s state is always correct (no infinite spinners).

## Pending States

There are a couple ways to manage the pending states for this interaction.

### useFormStatus

If you’re familiar with how context works in React apps, think of the `<form>` component as a provider and the `useFormStatus` hook as a function which accesses that provider’s data. Fundamentally, the `<form>` in React manages state of the status of the form and we can access that in any child component of the `<form>` . So to access the pending state of our form (while the submission is in flight) we need to create a child component.

```tsx
function JoinButton({ children }: { children: React.ReactNode }) {
	const { pending } = useFormStatus()

	return (
		<button type="submit">
			{pending ? 'Joining...' : children}
		</button>
	)
}

function JoinEventForm() {
	async function joinEvent(formData) {
		const response = await fetch('/remix-utah/events/301213597/join', {
			method: 'POST',
			body: formData,
		})

		if (response.ok) {
			alert('Successfully joined the event!')
		} else {
			alert('Failed to join the event.')
		}
	}

	return (
		<form action={joinEvent}>
			<JoinButton>Join Remix Meetup June 🏖</JoinButton>
		</form>
	)
}
```

The cool thing about [the `useFormStatus` hook](https://react.dev/reference/react-dom/hooks/useFormStatus) is that it also gives you access to other things about the form (including the submitted data). So if you’re building a login form, you could have the pending state say: `logging you in as {data.get('username')}` .

One thing I don’t love about it though is the requirement to make an entirely new component to consume the form’s state, so let’s look at an alternative approach.

### useActionState

It’s easiest to explain [`useActionState`](https://react.dev/reference/react/useActionState) with an example:

```tsx
const JOIN_URL = '/remix-utah/events/301213597/join'

async function joinEvent(
	previousState: { joined: boolean },
	formData: FormData,
) {
	const response = await fetch(JOIN_URL, {
		method: 'POST',
		body: formData,
	})

	if (response.ok) {
		return { joined: true }
	} else {
		return { joined: false }
	}
}

function JoinEventForm() {
	const [state, formAction, isPending] = useActionState(
		joinEvent,
		{ joined: false },
		JOIN_URL,
	)

	return (
		<div>
			{state.joined ? (
				<p>See you there!</p>
			) : (
				<form action={formAction}>
					<button type="submit">
						{isPending ? 'Joining...' : 'Join Remix Meetup June 🏖'}
					</button>
				</form>
			)}
		</div>
	)
}
```

Alright, so what’s going on here is `useActionState` accepts a function (`joinEvent`), some initial state (`{ joined: false }`), and optionally a permalink URL (`JOIN_URL`). It then returns an array with the current state (`state`), a function you can call to trigger the action (`formAction`), and whether the form submission is pending (`isPending`).

The `joinEvent` function accepts the previous state. In a way you can think of it as a reducer a la `useReducer`. When our form is submitted, it’s `action` is called with the `formData`. Our `action` is the `formAction`. The `formAction` function will call `joinEvent` with the current state followed by any arguments it’s called with. I understand that may be a little confusing, so let me illustrate by being obnoxiously verbose:

```tsx
function JoinEventForm() {
	const [state, formAction, isPending] = useActionState(
		(prevState, ...args) => joinEvent(prevState, ...args),
		{ joined: false },
		JOIN_URL,
	)

	return (
		<div>
			{state.joined ? (
				<p>See you there!</p>
			) : (
				<form
					action={(formData) => {
						const args = [formData]
						formAction(...args)
					}}
				>
					<button type="submit">
						{isPending ? 'Joining...' : 'Join Remix Meetup June 🏖'}
					</button>
				</form>
			)}
		</div>
	)
}
```

The `action` prop is called with the `formData`, we then make an array called `args` with only one element of `formData` which we then spread into a call of `formAction`. `formAction` then calls our inline function with the `prevState` and the rest of the args (in our case that’s just the `formData`, but as far as `useActionState` is concerned, it doesn’t have to be. It just forwards along whatever arguments there are.

From there, our `joinEvent` function performs whatever async stuff it needs to do, and then it returns a value which ends the transition and triggers our form to rerender with the `state` being equal to our returned value.

Of course during the transition, `isPending` will be `true` so we can show our pending state. However, we don’t have access to the `formData` outside our `action` so we wouldn’t be able to use the form submission as part of our pending UI like we could with `useFormStatus`. But there’s even more we can do!

Before we talk about that, I’ll just briefly mention that the third argument to `useActionState` is called a `permalink` and it’s there for server rendering and progressive enhancement. What React does with that is set the `action` to the URL you provide during server rendering. That way if the form is submitted before React has a chance to load on the page, the regular browser behavior will take over and submit the form with the full-page refresh functionality we’re used to (you’ll just want to make sure your server can handle the form submission properly). Hooray for progressive enhancement!

### useOptimistic

Showing the user feedback of pending tasks is important and useful. It’s awesome if the pending state actually looks like the finished state (maybe with a subtle indicator that it’s not actually complete). A good example of this is when you send a Slack/Discord message. The message appears in the messages list, but it’s slightly transparent to give you the sense that it’s an incomplete mutation.

You can do this with [`useOptimistic`](https://react.dev/reference/react/useOptimistic):

```tsx
// ...

function JoinEventForm() {
	const [state, formAction] = useActionState(
		joinEvent,
		{ joined: false },
		JOIN_URL,
	)
	const [optimisticJoined, setOptimisticJoined] = useOptimistic(state.joined)

	return (
		<div>
			{optimisticJoined ? (
				// show faded a bit if we've not yet finished joining...
				<p style={{ opacity: state.joined ? 1 : 0.8 }}>See you there!</p>
			) : (
				<form
					action={(formData) => {
						setOptimisticJoined(true) // Optimistically set the state to joined
						return formAction(formData)
					}}
				>
					<button type="submit">
						Join Remix Meetup June 🏖
					</button>
				</form>
			)}
		</div>
	)
}
```

The `useOptimistic` hook allows you to immediately update the UI to reflect the user's action before the network request completes. If the actual request fails, the state is reverted to the previous state. This provides a smoother user experience by reducing the perceived latency of the action.

We can even remove the pending UI from the button, but we add a little transparency to the success message to give the impression things are not completely settled. You may want to consider the experience for non-seeing users as well. React provides us with all we need to build this kind of experience!

You can even perform multiple steps and keep the user up-to-date with what’s happening with `useOptimistic`. It’s awesome:

```tsx
// ...

function JoinEventForm() {
	const [state, formAction] = useActionState(
		joinEvent,
		{ joined: false },
		JOIN_URL,
	)
	const [optimisticMessage, setOptimisticMessage] = useOptimistic("")

	return (
		<div>
			{state.joined ? (
				<p>See you there!</p>
			) : (
				<form
					action={async (formData) => {
						setOptimisticMessage("Joining meetup...")
						await formAction(formData)
						setOptimisticMessage("Sending notifications...")
						await sendNotification()
					}}
				>
					<p>{optimisticMessage}</p>
					<button type="submit">
						Join Remix Meetup June 🏖
					</button>
				</form>
			)}
		</div>
	)
}
```

In this example, we use the `useOptimistic` hook to provide feedback to the user at multiple stages of the form submission process. Initially, we set the optimistic message to "Joining meetup...", then await the `formAction`. Once that completes, we update the message to "Sending notification..." and await the `sendNotification` function.

## Conclusion

I think it’s awesome that we’ve not needed to reach for any libraries other than React to have all of this functionality. Really, what’s cool is what you *don’t see* but get like declarative management of errors and pending transitions and proper management of race conditions. And a great Optimistic UI story is also awesome. We also didn’t get to talk much about how this integrates with the server via the [`"use server"`](https://react.dev/reference/rsc/use-server) directive, but that’s a huge win as well which we’ll have to explore in the future.

I hope this article helped you get a more clear picture of what’s possible with React 19’s form primitives.

React 19 introduces terrific primitives for building great forms. Let's dive deep on forms for the web with React.

A deep dive on forms with modern React

When was the last time you tried your app out on the kinds of devices your end users are using? If you haven't, have you at least tried to simulate the kind of performance characteristics of your users on low-end devices?

Or are you working on a product that only users with high-end devices use? You've got metrics to prove that only high-end device users are using your app do you? Hmmm... Have you considered that the reason low-end device users aren't using your app because when they show up to your app they never come back because performance is bad? That might make an impact on your metrics a bit 😅

If you _have_ profiled your app, are you sure you're doing it correctly?

## The example

Check this out:

![DevTools flamegraph with a few red spots](/articles-images/why-youve-been-bad-about-profiling-react-apps/dev-no-throttle.png)

If you don't recognize where that's coming from, it's a screenshot of [the Chrome DevTool's Performance tab](https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/reference).

Here's the interaction that I'm doing that's creating that flamegraph:

![A form with the label "Find a city" and the word "salt" is typed into an input with cities being filtered in a combobox below](/articles-images/why-youve-been-bad-about-profiling-react-apps/typing-salt.gif)

From that flamegraph, we can see that there are maybe two spots that could use some optimization. But oh, what's that? It says "CPU: No throttling." Remember that our users might not have the high speed devices that we use to create our applications. If we want to make sure our apps work for users with less powerful machines, then we should at least simulate those kinds of machines. So let's change that to throttle our CPU by 6x:

![DevTools flamegraph with solid red spots](/articles-images/why-youve-been-bad-about-profiling-react-apps/dev-throttle.png)

Yikes!!! Look at those red lines! That's some slow janky stuff there folks. How in the world could users possibly use this app with anything but a souped up beast of a machine! React must be SO SLOW!

No hold on. Take a step back. Take a deep breath. Step away from the window and put your laptop down. It's really important that I tell you something about React performance.

You know all those helpful warnings that React gives you when you do something wrong? Stuff like:

```
Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined.
```

This is one of the things that I loved about React when I started using it. I was so used to things silently failing and having to dig around to figure out what I did wrong.

Turns out, React has to do quite a bit of extra work to make that magic happen. That doesn't come for free. In fact, it's actually pretty impactful. But we don't need these in production, so our end-user should never run that extra code. Luckily, React has been built with this in mind and the process to get rid of this extra code is [well documented](https://reactjs.org/docs/optimizing-performance.html).

So let's try that:

![Flamegraph with only one red line](/articles-images/why-youve-been-bad-about-profiling-react-apps/prod-no-throttle.png)

Phew! That's much better! We have a much better idea of what is actually slow. But oh, let's not forget to throttle things to simulate our lower-end device user's experience:

![Flamegraph with a few red lines](/articles-images/why-youve-been-bad-about-profiling-react-apps/prod-throttle.png)

Ok, so it looks like we've got a few things to improve for our lower-end device users.

## Profile the user's actual experience

If you're not measuring what your user's actual experience is like, then you could spend all your time chasing the optimization of red herring distractions and miss the actual interactions that cause your users grief.

Actually profiling your app's performance is just a first step, properly profiling it is the next. But hold up... I'm just simulating the user's experience on my own device. So I'm only _close_ to the user's experience, but do I really know for sure what it's like for users? And what about regressions? Do you expect me to do that every time I make a code change? No thank you.

This is why production performance monitoring is so important. We should keep track of how things are performing for users. Luckily React also exposes the ability to do this, so we can batch up information about every mount and update of components as the user's using them and we can send that information off to our backend, like this:

![A request payload showing component mounts and updates](/articles-images/why-youve-been-bad-about-profiling-react-apps/profile.png)

Then we can store that in a time-series database, and get alerts and graphs based on that. Companies like Facebook enable this for a fraction of their users and they can automatically rollback changes if they result in performance problems.

## Conclusion

Buttery-smooth performance is one of the things users expect from our apps and if we don't have that, they lose trust in our app. They may endure the janky experience, or they may abandon it altogether. It's often not the kind of thing user's will complain about, so if you're not testing and monitoring it, then you may never know that you're missing out on making your app available to those users at all. And if you don't do that properly, then you can spend your days optimizing the wrong things and in the wrong ways.

And yes, I've got lots to teach you about in [EpicReact.Dev](https://epicreact.dev).

P.S. Have you ever tried to pop open the React Profiler tab in production and seen this:

![React DevTools with the message: Profiling not supported.](/articles-images/why-youve-been-bad-about-profiling-react-apps/profile-missing-prod.png)

In EpicReact.Dev, I'll show you how to use the Profiler tab in production:

![React DevTools Profiler tab with a component graph](/articles-images/why-youve-been-bad-about-profiling-react-apps/profile-present-prod.png)

Is your app as fast as you think it is for your users?

Why you've been bad about Profiling React Apps

React server components have been stirring up the developer community, and I've noticed a mix of excitement and concern. Some folks are uneasy about the blurred lines between server and client, and the implementation challenges, especially with Next.js. But despite these bumps in the road, I want to tell you why I continue to be optimistic about the future of React Server Components.

## Why React Server Components Matter

For decades, we've grappled with integrating backend logic and front-end interactivity in a seamless way. React server components step in as a remarkable solution to this age-old problem. They allow us to compose server and client code without the usual hassle of switching between models.

The network is what makes web development so tough for the majority of web applications. Remix and other frameworks have done a great job of bridging the network chasm and I've really enjoyed using Remix for the last few years. It completely changed what it felt like to build web apps for me and enabled me to handle more and more use cases on my own with a better user experience.

But bridging the network chasm isn't enough. Ryan Florence's talk ["Mind the Gap"](https://www.youtube.com/watch?v=zqhE-CepH2g) at Big Sky Dev Con last month was a real eye-opener. If you haven't seen it yet, do yourself a favor and [watch it](https://www.youtube.com/watch?v=zqhE-CepH2g). He perfectly illustrates the power of React server components in not only bridging the gap between the backend and the frontend, but **making the network completely disappear**.

## Addressing the Pain Points

It's true that React server components introduce new challenges. These fresh pain points can seem daunting because we're not used to them. But let's not forget that all innovations in software come with their own set of hurdles. What's important to remember is that these pain points won't always be there. With any new technology, this is as tough as it gets, and it can only improve from here.

I have high hopes for Remix and its potential to implement React server components in a way that will alleviate many of the current pain points. The team behind Remix is poised to deliver an exceptional developer and user experience (as they have consistently done over the last decade of development with React).

Yes, there are complexities, especially for framework authors grappling with React server components. It's a tough time to be in their shoes, with all the abstractions that need to be figured out. But for the benefit of framework users, the effort is worthwhile. The goal is clear: to build better user experiences with an amazing developer experience. I'm confident the juice is worth the squeeze.

## The Promise of React Server Components

What stands out with React server components is their ability to seamlessly compose interactions between the client and the server. This is what Ryan described as the elimination of the "network chasm" in both directions. I'm confident that React server components are the future, and we'll look back at these times as the necessary growing pains that led to better solutions.

### Looking Ahead with Optimism

Folks who are using React Server Components right now (most of them are working in Next.js apps) are in the midst of uncertainty, dealing with boilerplate and annoyances. But once we develop the right level of abstractions, we'll be able to create user experiences that are not only better but also easier to build.

I'm super bullish on what Remix is doing. They're on track to do an amazing job, and I can't wait to see it unfold. So, to those of you who are worried about React server components and their impact on the React developer's future, I urge you to share my optimism. Things are only going to get better from here.

## What to do now?

Personally, I think it's worthwhile to learn about React Server Components. There are framework implementations of RSCs currently in frameworks that don't match my sensibilities so I'm not actively using them yet. For now, I'm sticking with Remix/React Router as a phenomenal way to build excellent user experiences on the Web. There are shortcomings with Remix for now for sure, but those will be largely solved by RSCs.

If you've not watched Ryan's other talk at React Conf titled ["Vanilla React"](https://www.youtube.com/live/T8TZQ6k4SLE?si=9-31tLaqqIarAO3K&t=5533), then you should definitely watch that to see what the RSC experience with React Router v7 will be like (it'll be amazing). So stick with Remix/React Router and you'll be well situated to take advantage of RSCs when they're ready. And it'll enable you to build better experiences faster.

Have a nice day, and stay optimistic about the future of web development!

React Server Components are going to improve the way we build web applications in a huge way... Once we nail the abstractions...

React Server Components: The Future of UI

If you've been building for the web for a while, you probably remember the days
when making a page interactive meant sprinkling `<script>` tags throughout your
HTML, hoping everything loaded in the right order, and wrestling with global
variables. If you wanted a dynamic search box or a fancy dropdown, you'd either
write a bunch of jQuery or wire up some custom JavaScript, and then cross your
fingers that it played nicely with your backend-rendered HTML.

Fast forward to today, and React's new Server Components model takes a
completely different approach. Now, you can compose your UI out of both server
and client components, letting each do what it does best. And the best part? You
get to include interactive client components _right in your server-rendered
UI_—no script tag gymnastics required.

Let's dig into why this is such a big deal, and how it works in practice.

## The Old Way: Script Tag Soup

Back in the day, if you wanted a page that showed a list of products (rendered
on the server) and let users filter them with a search box (handled on the
client), you'd end up with something like this:

```html

<input type="search" id="search" />
<ul id="products">
	<li>Product 1</li>
	<li>Product 2</li>
	
</ul>


<script src="/static/search.js"></script>
<script>
	window.initSearch({ selector: 'ul' })
</script>
```

You had to make sure your scripts loaded after the HTML, and that your
JavaScript could find and hook into the right DOM nodes. If you wanted to pass
data from the server to the client, you'd often have to serialize it into a
`<script>` tag or a `data-*` attribute. It worked, but it was fragile and hard
to scale.

## The React Server Components Way: Seamless Composition

With React Server Components (RSCs), you can build your UI as a tree of
components, some of which run on the server (fetching data, rendering markup),
and some of which run on the client (handling interactivity, managing state).
The magic is that you can _compose_ these together—server components can render
client components as children, and everything just works.

Here's what that looks like in practice:

```jsx
// Server component
import { SearchBox } from './search-box.js' // a client component

export default async function ProductList() {
	const products = await fetchProductsFromDatabase()
	return (
		<div>
			<SearchBox>
				<ul>
					{products.map((product) => (
						<li key={product.id}>{product.name}</li>
					))}
				</ul>
			</SearchBox>
		</div>
	)
}
```

The `SearchBox` is a client component—maybe it uses state, effects, or context.
But you can include it directly in your server-rendered UI. No need to wire up
script tags or global variables. React takes care of sending just the code
needed for `SearchBox` to the client, and hydrates it so it's fully interactive.

## Why This Is Awesome

- **No More Script Tag Indirection:** You don't have to manually connect your
  server-rendered HTML to your client-side code. Just compose components.
- **Encapsulation:** Each component (server or client) owns its own data
  fetching, state, and logic. No more prop drilling or global variables just to
  get data where it needs to go.
- **Performance:** Only the interactive bits get sent to the client as
  JavaScript. The rest is just HTML, streamed from the server. Less JS = faster
  loads.
- **Streaming and Suspense:** You can use React's streaming and Suspense
  features to show loading states for slow data, and have parts of your UI load
  in as they're ready. This used to be a nightmare with traditional server
  rendering.

## A Real Example: Ships, Search, and Streaming

In the
[EpicReact.dev Server Components workshop](https://www.epicreact.dev/workshops/react-server-components/intro-to-server-components),
we build a UI that lets users search for spaceships and view details. Here's how
the composition works:

- The **server component** fetches the list of ships and renders the overall
  layout.
- The **client component** handles the search box, managing its own state and
  updating the UI as the user types.
- When the user searches, the server streams back the updated list, and the
  client component stays interactive the whole time.

No script tags. No manual hydration. Just components.

## Juxtaposition: How Far We've Come

Let's compare the two approaches:

| Old Way (Backend Framework)            | React Server Components                  |
| -------------------------------------- | ---------------------------------------- |
| Server renders HTML                    | Server renders UI (as React elements)    |
| Client JS finds DOM nodes              | Client components are included directly  |
| Data passed via script tags or data-\* | Data fetched where it's needed           |
| Manual hydration                       | Automatic hydration of client components |
| Hard to scale, fragile                 | Encapsulated, composable, robust         |

## Bonus: No More Prop Drilling

One of the biggest pain points in React apps has always been prop
drilling—passing data through layers of components just to get it where it's
needed. With RSCs, you can fetch data _right where you need it_ (thanks to async
server components), and you can use platform features like Node's
`AsyncLocalStorage` to avoid prop drilling for global values. (Check out the
[workshop exercise on this](https://www.epicreact.dev/workshops/react-server-components/server-context)
for more.)

## Conclusion

Composing server and client components together is the modern React's
superpower. You get the best of both worlds: fast, data-rich UIs from the
server, and rich interactivity from the client—without the pain of the old days.
If you haven't tried building with React Server Components yet, now's the time.
Your future self (and your users) will thank you.

---

_Want to learn more? Check out the
[EpicReact.dev Server Components workshop](https://www.epicreact.dev/workshops/react-server-components)
for hands-on exercises and deep dives into these concepts._

How React's new model lets you build interactive, data-rich UIs without the pain of old-school script tags and prop drilling.

Preserving and Resetting State in React

Spoiler Alert: How to Fix It

Get my free 7-part email course on React!

More Articles

A deep dive on forms with modern React

Why you've been bad about Profiling React Apps

React Server Components: The Future of UI

Composing Server and Client Components: The Modern React's Superpower