[React Suspense for Data Fetching](https://reactjs.org/docs/concurrent-mode-suspense.html) is an **experimental** feature in React that opens the doors to a lot of really awesome performance improvements as well as developer experience improvements thanks to the declarative APIs given around asynchrony.

A read-through of the docs is suggested because it's interesting. One of the things that I find of particular interest in the docs is the section titled "Approach 3: Render-as-You-Fetch (using Suspense)." The arguments for this approach is the performance improvement opportunity which I tried to sum up in this tweet:

https://twitter.com/kentcdodds/status/1191922859762843649

To boil it down, we're talking about what happens when the user performs an action that results in loading some code that's been [code-split](https://reactjs.org/docs/code-splitting.html) (like navigating to a route).

So, here's the user interaction we're going to use for our example:

![User clicks "pikachu" and after a loading delay, pikachu's data and photo is displayed](/articles-images/render-as-you-fetch/interaction.gif)

So here's what most of us do (no shame, it's just natural):

1. Load, parse, run the code and request the loading spinner assets 2. Load the data the code needs 3. Load the assets based on the data

Here's what that might look like in the network tab:

![A DevTools Screenshot showing a waterfall of requests](/articles-images/render-as-you-fetch/bad.png)

This is what we call a "waterfall" effect. Because the lazily-loaded code is the code that requests the data, we have to wait until it's loaded before we can actually request the data and assets it needs.

In project management terms, this waterfall effect is what we call the "critical path":

> In project management, a critical path is the sequence of project network > activities which add up to the longest overall duration, regardless if that > longest duration has float or not. This determines the shortest time possible > to complete the project. There can be 'total float' (unused time) within the > critical path. – > [Wikipedia](https://en.wikipedia.org/wiki/Critical_path_method)

But here's the important aspect of the critical path: it's all about dependencies. And successful project managers know how to reduce dependencies so we can take advantage of parallization and hopefully reduce the time it takes to complete the project.

So, in our case, what if there's a way for us to start loading the data and assets as well as the code all at the same time? Would that not speed things up? You bet it would! Check this out:

![A DevTools Screenshot showing all the same requests from the previous image except they all start at the same time](/articles-images/render-as-you-fetch/good.png)

Because we already have all the information we need to start pre-loading the code, data, and assets, we simply fire off those requests all at the same time.

But this begs the question: "Why do we have those dependencies in the first place? Why don't we always trigger these requests right away?" The answer is because it's easier to maintain code where the data requirements are colocated with the code that requires the data.

But in [EpicReact.Dev](https://epicreact.dev), you'll learn how you can get the benefits of data colocation as well as pre-loading of code, data, and assets and how to do that both with "suspense for data fetching" as well as without.

Speed up your app's loading of code/data/assets with "render as you fetch" with and without React Suspense for Data Fetching

Render as you fetch (with and without suspense)

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

One thing that I like about React is that it allows me to write my components like little black boxes of abstraction. I can look at a design and draw lines around the UI elements and I know the components that I'm going to be making:

For example, here's my GitHub home page:

![GitHub homepage UI](/articles-images/one-react-mistake-thats-slowing-you-down/before.png)

Can you identify the different components you might create out of this design? Here's how I look at it:

![The same UI with boxes around different UI elements](/articles-images/one-react-mistake-thats-slowing-you-down/marked-up.png)

Now, you might not need an individual component for all of these things, or you may want _more_ components. It really depends on a variety of factors we won't get into here. The mistake I want to point out is that the way we compose these UI elements together in our code often makes a drastic difference on how maintainable it is (as well as how often we feel "prop-drilling" pains).

Let's imagine how we might structure some of the components for this page:

```javascript
function App() {
  return (
    <div>
      <MainNav />
      <Homepage />
    </div>
  )
}

function MainNav() {
  return (
    <div>
      <GitHubLogo />
      <SiteSearch />
      <NavLinks />
      <NotificationBell />
      <CreateDropdown />
      <ProfileDropdown />
    </div>
  )
}

function Homepage() {
  return (
    <div>
      <LeftNav />
      <CenterContent />
      <RightContent />
    </div>
  )
}

function LeftNav() {
  return (
    <div>
      <DashboardDropdown />
      <Repositories />
      <Teams />
    </div>
  )
}

function CenterContent() {
  return (
    <div>
      <RecentActivity />
      <AllActivity />
    </div>
  )
}

function RightContent() {
  return (
    <div>
      <Notices />
      <ExploreRepos />
    </div>
  )
}
```

We could keep going, but I think that's sufficient. You may have structured this differently (or come up with a better name than `RightContent` 🤦‍♂️), but based on apps that I've built in the past as well as apps I've seen others build, this is a pretty typical structure. Before I talk about some potential issues, let me show you an alternative structure that takes advantage of React's brilliant composition model. Then we can talk about the improvements and trade-offs.

```javascript
function App() {
  return (
    <div>
      <MainNav>
        <GitHubLogo />
        <SiteSearch />
        <NavLinks />
        <NotificationBell />
        <CreateDropdown />
        <ProfileDropdown />
      </MainNav>
      <Homepage
        leftNav={
          <LeftNav>
            <DashboardDropdown />
            <Repositories />
            <Teams />
          </LeftNav>
        }
        centerContent={
          <CenterContent>
            <RecentActivity />
            <AllActivity />
          </CenterContent>
        }
        rightContent={
          <RightContent>
            <Notices />
            <ExploreRepos />
          </RightContent>
        }
      />
    </div>
  )
}

function MainNav({children}) {
  return <div>{children}</div>
}

function Homepage({leftNav, centerContent, rightContent}) {
  return (
    <div>
      {leftNav}
      {centerContent}
      {rightContent}
    </div>
  )
}

function LeftNav({children}) {
  return <div>{children}</div>
}

function CenterContent({children}) {
  return <div>{children}</div>
}

function RightContent({children}) {
  return <div>{children}</div>
}
```

What's your initial reaction to this? Shock? Awe? Curiosity? Confusion? Disgust? Is your initial reaction based on the fact that this is unfamiliar to you and therefore should be shunned? If that's the case, then I invite you to pause and consider this for a moment.

First, let me be clear that this use of React's composition capabilities can probably be taken too far. Everything with moderation. The idea here is that our structural components are responsible for layout. They likely won't do much to manage state themselves (though they certainly could). They simply accept the different stateful elements and then lay them out onto the page in the places where they're supposed to appear. Most of the time, the `children` prop is sufficient (in the Angular.js world, we call this "transclusion"), but sometimes you might have several elements that you need to lay out, so you can use specific and named props like our `Homepage` component (in the Vue.js world, we call this "slots").

## But... Why?

So, why would we do this? The biggest and best reason to do this is for state management. We're not showing any state use here, but let's imagine for a moment that we needed to pass the user around. Consider the first example. Where would you store the user's information? You'd probably store it in the `App` component because that's the "lowest common parent" of the components that require that state. From there you'd have to pass the `user`'s information (and potentially mechanisms to update the user's information) as props.

This results in "prop-drilling". For example: `<App /> -> <Homepage /> -> <CenterContent /> -> <AllActivity />` (and potentially further). People have a pretty low tolerance for this, so you're probably think that you'd use React's `context` API to solve this instead (so would I).

But consider what this would look like for our second, more composed example. You'd still need to store the `user` state in the `App` component, but what does it look like to get the user's info to the `AllActivity` component now? `<App /> -> <AllActivity />`. Boom. That's it.

## Conclusion

I think too many people go from "passing props" -> "context" too quickly. If we structure our components with more composition in mind, then I think our codebase will be more maintainable (you'll likely not need to open so many files when you make changes) and we'll have fewer performance and state management problems.

I'm excited to show you more on [EpicReact.Dev](https://epicreact.dev)!

Simplify and speed up your app development using React composition

One React mistake that's slowing you down

Let's analyze this React tree structure:

```tsx
<App>
	<ShipSearch />
	<ShipDetails />
</App>
```

Let's assume that `App` renders the `ShipSearch` and `ShipDetails` components,
passing props as needed.

`ShipSearch` is a server component which takes a `search` and uses that to
perform a database query:

```ts
async function ShipSearch({ search }) {
	const shipResults = await searchShips({ search })
	// ... render stuff
}
```

The `ShipDetails` component is also a server component which takes a `shipId`
and uses that to perform a database query:

```ts
async function ShipDetails({ shipId }) {
	const ship = await getShip({ shipId })
	// ... render stuff
}
```

Because these are sibling components, both queries will run at the same time.

```
searchShips query  ---->  searchShips result
getShip query      ---->  getShip result
```

## Server Waterfalls

That's all fine. But let's say the `App` component needs to resolve a logged in
user:

```ts
async function App() {
	const user = await getLoggedInUser()
	// ... render stuff
}
```

Uh oh, now we have a waterfall:

```
getLoggedInUser query ---->  getLoggedInUser result
                             searchShips query      ---->  searchShips result
                             getShip query          ---->  getShip result
```

The issue here is now `App` is waiting for `getLoggedInUser` to resolve before
it can render anything. This means both `searchShips` and `getShip` won't be
executed until _after_ `getLoggedInUser` resolves, even though those don't
directly depend on the user.

This is a problem generally for React Suspense as well and I dive deep into that
in the
[React Suspense workshop exercise 6](https://suspense.epicreact.dev/exercise/06).

There are a few ways to think about this problem:

Maybe it's not a problem if `getLoggedInUser` is fast 🤷‍♂️ But that's not always a
sure thing, and even if it's fast today doesn't mean someone won't add something
else that will be slow tomorrow. Still, it's always good to think about how bad
ignoring the problem would actually be since there could be bigger fish to fry.

Alternatively, we can lift `searchShips` and `getShip` into `App` and pass the
results down to `ShipSearch` and `ShipDetails`. Then we could use `Promise.all`
to make sure they run concurrently. But passing props can get annoying pretty
fast. We can use a library like
[`@epic-web/cachified`](https://github.com/epicweb-dev/cachified) to dedupe the
queries and then `App` simply kicks off the query earlier which would at least
be better.

Unfortunately, another issue though is this can get unweildy pretty fast,
especially if there's logic around which queries should run based on other
props. You'd have to move all that logic until your entire app lives in `App`
😱.

The next solution I can come up with is to use or build a compiler which can
find all queries and preload them automatically. This is what Relay is. There
are quite a few things I don't like about this approach though:

1. If you have logic around which queries should run based on other props, this
   approach doesn't work.
2. It adds a lot of complexity to your build process.
3. When you're working in product code, it's not obvious what's happening.

So I guess what I'm saying is I don't like any of these solutions. But I'd like
to reframe the problem with more context.

## The status quo

Let's say we live in a world where we don't have RSCs or Suspense. You're just
building an app with components that fetch data and render stuff.

In that world you've got three options:

1. Group together (colocate) your queries with the components that need them.
2. Lift all your queries into a single component and pass the results down.
3. Use a compiler to find all your queries and preload them automatically.

Sound familiar? It's exactly the same problem we've always had with components
and data. There's always been this tension between colocating and passing down
data (prop drilling).

One of the nice things about Remix is that it gives you a fourth option:

4. Decouple your data fetching from your components.

This allows Remix to load data as soon as the request comes in regardless of
whether the component has rendered.

This is what I've been doing for years and it's been awesome.

## So, why RSCs?

This blog post isn't really about why I think RSCs are awesome. You can read
[React Server Components: The Future of UI](https://www.epicreact.dev/react-server-components-the-future-of-ui)
for that. Just know that composition at route boundaries is not as good as
composition at component boundaries and I want React-level composition badly.

What I want to do is show how RSCs fit into the same tension between colocating
and prop drilling that we've always had with components and data. There's no new
problems here.

But what I find interesting is how a server-side waterfall is probably better
than a client-side waterfall primarily because you get to control the network.
The connection between your server rendering server and your database is
probably stronger, faster, more reliable, and closer. Or maybe it's not, but the
point is _you_ are in control there and can make improvements to that if it's
important to you. You also have more fine-grained control over caching (requests
from separate clients can share a cache for common data).

When you have a client-side waterfall, you're dealing with the user's device and
their network connection which may be great or may be terrible but you
definitely have no control over.

So shifting this problem from the client to the server sounds like a net gain
for many scenarios.

## Conclusion

The "waterfall" problem of RSCs is not a new problem. It's the same tension
between colocating and prop drilling that we've always had with components and
data. Maybe there's a new solution we can look forward to in the future. I
welcome ideas (preferrably something that doesn't require a special compiler)!
Until then, I'm actually pretty happy with just making things fast enough that the
problem isn't a problem.


Understanding server-side waterfalls with RSCs and client-side waterfalls we're familiar with and why server-side waterfalls are probably better.

The Big "Server Waterfall Problem" with RSCs

Here's a form in `JSX`:

```jsx
function UsernameForm({onSubmitUsername}) {
  function handleSubmit(event) {
    event.preventDefault()
    onSubmitUsername(event.currentTarget.elements.usernameInput.value)
  }

  return (
    <form onSubmit={handleSubmit}>
      <div>
        <label htmlFor="usernameInput">Username:</label>
        <input id="usernameInput" type="text" />
      </div>
      <button type="submit">Submit</button>
    </form>
  )
}
```

Let's type that `handleSubmit` function. Here's how some people do it (copying this approach from some blog posts and "semi-official guides" I've seen):

```tsx
function handleSubmit(event: React.SyntheticEvent<HTMLFormElement>) {
  event.preventDefault()
  const form = event.currentTarget
  const formElements = form.elements as typeof form.elements & {
    usernameInput: {value: string}
  }
  onSubmitUsername(formElements.usernameInput.value)
}
```

The reason we have to have the `as` there is because TypeScript isn't quite smart enough to know what elements we're rendering in our form, so we have to use the type cast which I'm not a fan of, but you gotta ship right?

My first improvement to this is to change that `usernameInput` type:

```diff
-     usernameInput: {value: string}
+     usernameInput: HTMLInputElement
```

Definitely take advantage of the type it actually is rather than just cherry-picking the values you need.

The second improvement is:

```diff
- function handleSubmit(event: React.SyntheticEvent<HTMLFormElement>) {
+ function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
```

Incidentally, at the time of this writing, there's no substantive difference in those types, but I prefer to be more clear and accurate with the name of the type, so that's what we're going to go with.

So here we are now:

```tsx
function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
  event.preventDefault()
  const form = event.currentTarget
  const formElements = form.elements as typeof form.elements & {
    usernameInput: HTMLInputElement
  }
  onSubmitUsername(formElements.usernameInput.value)
}
```

But even with those changes, I'm not a fan of this for three reasons:

1. It's a bit verbose and distracts from the main purpose of the function 2. If I need to use that `form` anywhere else, I'll either have to duplicate the    code or extract the type and cast it everywhere I use the form. 3. I don't like seeing `as` in my code because it is a signal that I'm telling    the TypeScript compiler to pipe down (be less helpful). So I try to avoid it    when possible. And it is possible!

Keep in mind that _we're_ the ones telling TypeScript what that `event.currentTarget` type is. We tell TypeScript when we specify the type for our `event`. Right now that's set to `React.FormEvent<HTMLFormElement>`. So we're telling TypeScript that `event.currentTarget` is an `HTMLFormElement` but then we immediately tell TypeScript that this isn't quite right by using `as`. What if instead we just tell TypeScript more accurately what it is at the start? Yeah, let's do that.

```tsx
interface FormElements extends HTMLFormControlsCollection {
  usernameInput: HTMLInputElement
}
interface UsernameFormElement extends HTMLFormElement {
  // now we can override the elements type to be an HTMLFormControlsCollection
  // of our own design...
  readonly elements: FormElements
}
```

So in reality, our `form` is an `HTMLFormElement` with some known `elements`. So we extend `HTMLFormElement` and override the `elements` to have the elements we want it to. The `HTMLFormElement['elements']` type is a `HTMLFormControlsCollection`, so make our own version of that interface as well.

With that, now we can update our type and get rid of all the type casting!

Here's the whole thing altogether:

```tsx
import * as React from 'react'

interface FormElements extends HTMLFormControlsCollection {
  usernameInput: HTMLInputElement
}
interface UsernameFormElement extends HTMLFormElement {
  readonly elements: FormElements
}

function UsernameForm({
  onSubmitUsername,
}: {
  onSubmitUsername: (username: string) => void
}) {
  function handleSubmit(event: React.FormEvent<UsernameFormElement>) {
    event.preventDefault()
    onSubmitUsername(event.currentTarget.elements.usernameInput.value)
  }

  return (
    <form onSubmit={handleSubmit}>
      <div>
        <label htmlFor="usernameInput">Username:</label>
        <input id="usernameInput" type="text" />
      </div>
      <button type="submit">Submit</button>
    </form>
  )
}
```

So now:

1. the type information is removed from the `handleSubmit` code, allowing us to    focus on what the function is doing. 2. If we need to use this `form` somewhere else, we can give it the    `UsernameFormElement` type and get all the type help we need. 3. We don't have to use a type cast, so TypeScript can be more useful for us.

I hope that's helpful to you!

Excellent TypeScript definitions for your React forms

Render as you fetch (with and without suspense)

Get my free 7-part email course on React!

More Articles

A deep dive on forms with modern React

One React mistake that's slowing you down

The Big "Server Waterfall Problem" with RSCs

How to type a React form onSubmit handler