When I started at PayPal, the app I started with used Redux for its state management (like pretty much every other React app at the time). This was the first React product I'd ever worked on and I was excited to use the latest and greatest tools for state management. Unfortunately it wasn't long before I realized that Redux had some serious shortcomings and I haven't used it since.

However, this blog post isn't about Redux.

After working on that app, I had the privilege to work on the team that would rewrite [paypal.me](https://paypal.me/kentcdodds/💰) (🤑) from the ground up. As a team we knew we didn't want to use Redux, but we automatically assumed we would need _something_ to manage state, so we began the search. We eventually found a library that we thought would work out pretty well.

It did not.

I mean, it wasn't a disaster or anything, but unfortunately after a while, it was difficult for any of us to make sense of the app state. And it wasn't the fault of the library we chose. Frankly, what happened was we decided to avoid Redux, but then grabbed another library and made the same mistakes that made Redux such a problem: **Almost all state was globally managed by the library.**

So what should we have done? If I could go back in time and could only say one thing, here's what I would say:

> Server cache is not the same as UI state, and should be handled differently.

What happened to me for pretty much every app I wrote up until even this year was that I would take the data I got from the server and treat it like it was UI state. I would mix it in with the actual UI state (stuff that's not persisted. You know, the stuff that goes away when you refresh the page), and this resulted in making _both_ more complex. I would try and fail at state synchronization. Found myself in "impossible" states that were difficult to debug.

## So what now?

Honestly, if I really could go back in time and meet myself, in addition to the one thing I said, I would hand myself a flash drive with a copy of https://github.com/tannerlinsley/react-query on it (with instructions to give it to [Tanner](https://twitter.com/tannerlinsley) along with a thank you note). [React Query](https://react-query.tanstack.com/) is simply the perfect abstraction that can handle the server cache for me. It gives me all the right knobs to twist to set my caching strategy up just right.

And once my server cache is handled so perfectly by react-query, I don't have enough state left to feel like I need a library for the rest of it. React is a state management solution and it's a really good one when you componentize your state like you do your UI.

Honestly, paypal.me was a small enough app that I wish we had embraced that (given react-query didn't exist). I think the state would have been easier to maintain had we colocated our state a little better.

Luckily, now we have react-query, React hooks, and a brilliant context API and that's all most applications will ever need for server cache and UI state management. I love it. And I'll teach you all about it on [EpicReact.Dev](https://epicreact.dev) 🚀 

It wasn't a library. It was the way I was thinking about and defining state.

My State Management Mistake

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

How to type a React form onSubmit handler

Forms are a huge part of the web. Literally every interaction the user takes to make changes to backend data should use a `form`. Some forms are pretty simple, but in a real world scenario they get complicated quickly. You need to submit the form data the user entered, respond to server errors, validate the user input as they're typing (but not before they've blurred the input please), and sometimes you even need to build custom-made UI elements for form input types that aren't supported (styleable selects, date pickers, etc.).

All this extra stuff your forms need to do is just more JavaScript the browser has to execute while the user is interacting with your form. This often leads to performance problems that are tricky. Sometimes there's a particular component that's the obvious problem and optimizing that one component will fix things and you can go on your merry way.

But often there's not a single bottleneck. Often the problem is that every user interaction triggers every component to re-render which is the performance bottleneck. I've had countless people ask me about this problem. Memoization won't help them because these form field components accept props that are indeed changing.

The easiest way to fix this is to just not react to every user interaction (don't use `onChange`). Unfortunately, this isn't really practical for many use cases. We want to display feedback to the user as they're interacting with our form, not just once they've hit the submit button.

So, assuming we _do_ need to react to a user's interaction, what's the best way to do that without suffering from "perf death by a thousand cuts?" The solution? [State colocation](https://kcd.im/colocate-state)!

## The demo

Allow me to demonstrate the problem and solution for you with a contrived example. Anyone who has experienced the problem above should hopefully be able to translate this contrived example to a real experience of their past. And if you haven't experienced this problem yet, hopefully you'll trust me when I say the problem is real and the solution works for most use cases.

You'll find the full demo in [this codesandbox](https://codesandbox.io/s/form-perf-demo-240ho). Here's a screenshot of what it is:

![Overview of the app showing two sections with ten fields and a submit button](https://res.cloudinary.com/kentcdodds-com/image/upload/f_auto,q_auto,dpr_2.0/v1622084161/epicreact.dev/articles/improve-the-performance-of-your-react-forms/app-overview_wwy6ds.png)

This is rendered by the following `<App />` component:

```tsx
function App() {
  return (
    <div>
      <h1>Slow Form</h1>
      <SlowForm />
      <hr />
      <h1>Fast Form</h1>
      <FastForm />
    </div>
  )
}
```

Each of the forms function exactly the same, but if you try it out the `<SlowForm />` is observably slower (try typing into any field quickly). What they each render is a list of fields which all have the same validation logic applied:

- You can only enter lower-case characters - The text length must be between 3 and 10 characters - Only display an error message if the field has been "touched" or if the form   has been submitted. - When the form is submitted, all the data for the fields is logged to the   console.

At the top of the file you get a few knobs to test things out:

```tsx
window.PENALTY = 150_000
const FIELDS_COUNT = 10
```

The `FIELDS_COUNT` controls how many fields are rendered.

The `PENALTY` is used in our `<Penalty />` component which each of the fields renders to simulate a component that takes a bit of extra time to render:

```tsx
let currentPenaltyValue = 2
function PenaltyComp() {
  for (let index = 2; index < window.PENALTY; index++) {
    currentPenaltyValue = currentPenaltyValue ** index
  }
  return null
}
```

Effectively `PENALTY` just controls how many times the loop runs to make the exponentiation operator run for each field. Note, because `PENALTY` is on `window` you can change it while the app is running to test out different penalties. This is useful to adjust it for the speed of your own device. Your computer and my computer have different performance characteristics so some of your measurements may be a bit different from mine. It's all relative.

All right, with that explanation out of the way, let's look at the `<SlowForm />` first.

### `<SlowForm />`

```tsx
/**
 * When managing the state higher in the tree you also have prop drilling to
 * deal with. Compare these props to the FastInput component
 */
function SlowInput({
  name,
  fieldValues,
  touchedFields,
  wasSubmitted,
  handleChange,
  handleBlur,
}: {
  name: string
  fieldValues: Record<string, string>
  touchedFields: Record<string, boolean>
  wasSubmitted: boolean
  handleChange: (event: React.ChangeEvent<HTMLInputElement>) => void
  handleBlur: (event: React.FocusEvent<HTMLInputElement>) => void
}) {
  const value = fieldValues[name]
  const touched = touchedFields[name]
  const errorMessage = getFieldError(value)
  const displayErrorMessage = (wasSubmitted || touched) && errorMessage

  return (
    <div key={name}>
      <PenaltyComp />
      <label htmlFor={`${name}-input`}>{name}:</label> <input
        id={`${name}-input`}
        name={name}
        type="text"
        onChange={handleChange}
        onBlur={handleBlur}
        pattern="[a-z]{3,10}"
        required
        aria-describedby={displayErrorMessage ? `${name}-error` : undefined}
      />
      {displayErrorMessage ? (
        <span role="alert" id={`${name}-error`} className="error-message">
          {errorMessage}
        </span>
      ) : null}
    </div>
  )
}

/**
 * The SlowForm component takes the approach that's most common: control all
 * fields and manage the state higher up in the React tree. This means that
 * EVERY field will be re-rendered on every keystroke. Normally this is no
 * big deal. But if you have some components that are even a little expensive
 * to re-render, add them all up together and you're toast!
 */
function SlowForm() {
  const [fieldValues, setFieldValues] = React.useReducer(
    (s: typeof initialFieldValues, a: typeof initialFieldValues) => ({
      ...s,
      ...a,
    }),
    initialFieldValues,
  )
  const [touchedFields, setTouchedFields] = React.useReducer(
    (s: typeof initialTouchedFields, a: typeof initialTouchedFields) => ({
      ...s,
      ...a,
    }),
    initialTouchedFields,
  )
  const [wasSubmitted, setWasSubmitted] = React.useState(false)

  function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
    event.preventDefault()
    const formIsValid = fieldNames.every(
      (name) => !getFieldError(fieldValues[name]),
    )

    setWasSubmitted(true)
    if (formIsValid) {
      console.log(`Slow Form Submitted`, fieldValues)
    }
  }

  function handleChange(event: React.ChangeEvent<HTMLInputElement>) {
    setFieldValues({[event.currentTarget.name]: event.currentTarget.value})
  }

  function handleBlur(event: React.FocusEvent<HTMLInputElement>) {
    setTouchedFields({[event.currentTarget.name]: true})
  }

  return (
    <form noValidate onSubmit={handleSubmit}>
      {fieldNames.map((name) => (
        <SlowInput
          key={name}
          name={name}
          fieldValues={fieldValues}
          touchedFields={touchedFields}
          wasSubmitted={wasSubmitted}
          handleChange={handleChange}
          handleBlur={handleBlur}
        />
      ))}
      <button type="submit">Submit</button>
    </form>
  )
}
```

I know there's a lot going on there. Feel free to take your time to get an idea of how it works. The key thing to keep in mind is that all the state is managed in the `<SlowForm />` component and the state is passed as props to the underlying fields.

Alright, so let's profile an interaction with this form. I've built this for production ([with profiling enabled](https://kentcdodds.com/blog/profile-a-react-app-for-performance)). To keep our testing consistent, the interaction I'll do is focus on the first input, type the character "a" and then "blur" (click out of) that input.

I'll start a [Performance profiling session with the Browser DevTools](https://developer.chrome.com/docs/devtools/evaluate-performance/reference/) with a 6x slowdown to simulate a slower mobile device. Here's what the profile looks like:

![Chrome DevTools Performance Tab showing 97 milliseconds on a keypress event](https://res.cloudinary.com/kentcdodds-com/image/upload/f_auto,q_auto,dpr_2.0/v1622131136/epicreact.dev/articles/improve-the-performance-of-your-react-forms/slow-performance-tab_odesxq.png)

Wowza. Check that out! 97 milliseconds on that keypress event. Remember that we only have ~16 milliseconds to do our JavaScript magic. Any longer than that and things start feeling really janky. And at the bottom there it's telling us we've blocked the main thread for 112 milliseconds just by typing a single character and blurring that input. Yikes.

Don't forget this _is_ a 6x slowdown, so it won't be quite that bad for many users, but it's still an indication of a severe performance issue.

Let's try the React DevTools profiler and observe what React is doing when we interact with one of the form fields like that.

![The React DevTools profiler tab showing all children of the SlowForm component are re-rendering](https://res.cloudinary.com/kentcdodds-com/image/upload/f_auto,q_auto,dpr_2.0/v1622131136/epicreact.dev/articles/improve-the-performance-of-your-react-forms/slow-react-profiler_vyumda.png)

Huh, so it appears that every field is re-rendering. But they don't need to! Only the one I'm interacting with does!

Your first instinct to fix this might be to memoize each of your field components. The problem is you'd have to make sure you memoize all the props that are passed which can really spider out to the rest of the codebase quickly. On top of that, we'd have to restructure our props so we only pass primitive or memoizeable values. I try to avoid memoizing if I can for these reasons. And I can! Let's try state colocation instead!

### `<FastForm />`

Here's the exact same experience, restructured to put the state within the individual fields. Again, take your time to read and understand what's going on here:

```tsx
/**
 * Not much we need to pass here. The `name` is important because that's how
 * we retrieve the field's value from the form.elements when the form's
 * submitted. The wasSubmitted is useful to know whether we should display
 * all the error message even if this field hasn't been touched. But everything
 * else is managed internally which means this field doesn't experience
 * unnecessary re-renders like the SlowInput component.
 */
function FastInput({
  name,
  wasSubmitted,
}: {
  name: string
  wasSubmitted: boolean
}) {
  const [value, setValue] = React.useState('')
  const [touched, setTouched] = React.useState(false)
  const errorMessage = getFieldError(value)
  const displayErrorMessage = (wasSubmitted || touched) && errorMessage

  return (
    <div key={name}>
      <PenaltyComp />
      <label htmlFor={`${name}-input`}>{name}:</label> <input
        id={`${name}-input`}
        name={name}
        type="text"
        onChange={(event) => setValue(event.currentTarget.value)}
        onBlur={() => setTouched(true)}
        pattern="[a-z]{3,10}"
        required
        aria-describedby={displayErrorMessage ? `${name}-error` : undefined}
      />
      {displayErrorMessage ? (
        <span role="alert" id={`${name}-error`} className="error-message">
          {errorMessage}
        </span>
      ) : null}
    </div>
  )
}

/**
 * The FastForm component takes the uncontrolled approach. Rather than keeping
 * track of all the values and passing the values to each field, we let the
 * fields keep track of things themselves and we retrieve the values from the
 * form.elements when it's submitted.
 */
function FastForm() {
  const [wasSubmitted, setWasSubmitted] = React.useState(false)

  function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
    event.preventDefault()
    const formData = new FormData(event.currentTarget)
    const fieldValues = Object.fromEntries(formData.entries())

    const formIsValid = Object.values(fieldValues).every(
      (value: string) => !getFieldError(value),
    )

    setWasSubmitted(true)
    if (formIsValid) {
      console.log(`Fast Form Submitted`, fieldValues)
    }
  }

  return (
    <form noValidate onSubmit={handleSubmit}>
      {fieldNames.map((name) => (
        <FastInput key={name} name={name} wasSubmitted={wasSubmitted} />
      ))}
      <button type="submit">Submit</button>
    </form>
  )
}
```

Got it? Again, lots happening, but the most important thing to know there is the state is being managed within the form fields themselves rather than in the parent. Let's try out the performance profiler on this now:

![Chrome DevTools Performance Tab showing 15.33 milliseconds on a keypress event](https://res.cloudinary.com/kentcdodds-com/image/upload/f_auto,q_auto,dpr_2.0/v1622131136/epicreact.dev/articles/improve-the-performance-of-your-react-forms/fast-performance-tab_vnefkb.png)

NICE! Not only are we within the 16 millisecond budget, but you might have noticed it says we had a total blocking time of 0 milliseconds! That's a lot better than 112 milliseconds 😅 And remember, that we're on a 6x slowdown so for many users it will be even better.

Let's pop open the React DevTools and make sure we're only rendering the component that needs to be rendered with this interaction:

![The React DevTools profiler tab showing the only component that re-rendered was the FastField component and it's children](https://res.cloudinary.com/kentcdodds-com/image/upload/f_auto,q_auto,dpr_2.0/v1622131136/epicreact.dev/articles/improve-the-performance-of-your-react-forms/fast-react-profiler_u9arcy.png)

Sweet! The only component that re-rendered was the one that needed to. In fact, the `<FastForm />` component didn't re-render, so as a result none of the other children needed to either so we didn't need to muck around with memoization at all.

## Nuance...

Now, sometimes you have fields that need to know one another's value for their own validation (for example, a "confirm password" field needs to know the value of the "password" field to validate it is the same). In that case, you have a few options. You could hoist the state to the least common parent which is not ideal because it means every component will re-render when that state changes and then you may need to start worrying about memoization (nice that React gives us the option!).

Another option is to put it into context local to your component so only the context provider and consumers re-render when it's changed. Just make sure you structure things so you can take advantage of [this optimization](https://kentcdodds.com/blog/optimize-react-re-renders) or it won't be much better.

A third option is to step outside of React and reference the DOM directly. The concerned component(s) could attach their own `change` event listener to their parent form and check whether the changed value is the one they need to validate against.

[Brooks Lybrand](https://twitter.com/BrooksLybrand) created an example of both of two of these alternatives you can check out if you'd like to get a better idea of what I mean:

- [Context Provider](https://codesandbox.io/s/form-perf-demo-context-pmhnp) - [Reference the DOM](https://codesandbox.io/s/form-perf-demo-forked-rblg5)

The nice thing is that you can try each of these approaches and choose the one you like best (or the one you dislike the least 😅).

## Conclusion

You can try the demo yourself here:

<iframe src="https://codesandbox.io/embed/240ho?view=Editor+%2B+Preview&module=%2Fsrc%2Findex.tsx"   style={{     width: '100%',     height: '500px',     border: 0,     borderRadius: '5px',     overflow: 'hidden',   }}   title="form-perf-demo"   allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"   sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts" />

Remember if you want to try profiling with the Chrome DevTools Performance tab, make sure you have built it for production and play around with the throttle and the `PENALTY` value.

At the end of the day, what matters most is _your_ application code. So I suggest you try some of these profiling strategies on your app and then try state colocation to improve the performance of your components.

Good luck!

Forms can get slow pretty fast. Let's explore how state colocation can keep our React forms fast.

Improve the Performance of your React Forms

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

I've been riding the CSS-in-JS train for years (I was even a significant contributor to the "movement"). It's awesome. I've never been so productive working with CSS than when I added the power of JavaScript to it.

I'm still a fan of CSS-in-JS, and in recent years, the CSS spec has evolved and improved a lot and modern browsers have too (unfortunately, Internet Explorer is NOT a modern browser in this or any context). Often I'd use a `ThemeProvider` (like those found in emotion), but turns out there aren't a whole lot of advantages to that kind of component for many use cases and there are several disadvantages.

Let's look at a simple example of "Dark Mode" and compare differences in API (developer experience) and performance (user experience). We'll keep the example simple, and in both the before/after, we'll be using emotion's `styled` utility. Keep in mind that with the `ThemeProvider` you can consume the values using the `useTheme` hook, with a styled component, or with the `css` prop. With CSS Variables, you can get the values in your CSS with `var(--css-variable-name)` and in your JavaScript using `getComputedStyle(element).getPropertyValue('--css-variable-name')` (which you really don't need to do...)

Ok, let's look at some code. Here's an approach to using emotion's `ThemeProvider`:

```javascript
import * as React from 'react'
import styled from '@emotion/styled'
import {ThemeProvider} from 'emotion-theming'

const themes = {
  light: {
    colors: {
      primary: 'deeppink',
      background: 'white',
    },
  },
  dark: {
    colors: {
      primary: 'lightpink',
      background: 'black',
    },
  },
}

const PrimaryText = styled.div(({theme}) => ({
  padding: 20,
  color: theme.colors.primary,
  backgroundColor: theme.colors.background,
}))

function ThemeToggler({theme, onClick}) {
  const nextTheme = theme === 'light' ? 'dark' : 'light'

  return (
    <button onClick={() => onClick(nextTheme)}>
      Change to {nextTheme} mode
    </button>
  )
}

function App() {
  const [theme, setTheme] = React.useState('light')
  return (
    <ThemeProvider theme={themes[theme]}>
      <PrimaryText>This text is the primary color</PrimaryText>
      <ThemeToggler
        theme={theme}
        onClick={(nextTheme) => setTheme(nextTheme)}
      />
    </ThemeProvider>
  )
}

export default App
```

What's cool about this is it's "just JavaScript" so you get all the benefits of variables etc. But we're not really doing all that much with this other than passing it around through the ThemeProvider. (To be clear, the way the ThemeProvider works is it uses React's Context API to make the theme accessible to all emotion components without having to pass props all over the place).

Let's compare this with the CSS Variables approach. But before we get to that, I need to mention that there's no "ThemeProvider" for this. Instead, we define the variables in regular CSS that will get applied based on a `data` attribute we apply to the `body`. So here's that css file:

```css
body[data-theme='light'] {
  --colors-primary: deeppink;
  --colors-background: white;
}

body[data-theme='dark'] {
  --colors-primary: lightpink;
  --colors-background: black;
}
```

Alright, so with that, here's the implementation of the exact same UI:

```javascript
import * as React from 'react'
import './css-vars.css'
import styled from '@emotion/styled'

const PrimaryText = styled.div({
  padding: 20,
  color: 'var(--colors-primary)',
  backgroundColor: 'var(--colors-background)',
})

function ThemeToggler() {
  const [theme, setTheme] = React.useState('light')
  const nextTheme = theme === 'light' ? 'dark' : 'light'

  React.useEffect(() => {
    document.body.dataset.theme = theme
  }, [theme])

  return (
    <button onClick={() => setTheme(nextTheme)}>
      Change to {nextTheme} mode
    </button>
  )
}

function App() {
  return (
    <div>
      <PrimaryText>This text is the primary color</PrimaryText>
      <ThemeToggler />
    </div>
  )
}

export default App
```

Let's first compare what it's like to _use_ these values:

```javascript
// ThemeProvider:
const PrimaryText = styled.div(({theme}) => ({
  padding: 20,
  color: theme.colors.primary,
  backgroundColor: theme.colors.background,
}))

// CSS Variables:
const PrimaryText = styled.div({
  padding: 20,
  color: 'var(--colors-primary)',
  backgroundColor: 'var(--colors-background)',
})
```

There's not really much of a difference from a DX (development experience) standpoint here. One point for the CSS Variables approach is not having to create a function that accepts the theme and returning styles (and no need to even learn about that API).

One point for the `ThemeProvider` approach is if you're using TypeScript you could get type safety on your theme... But ummm... [Check this out](https://twitter.com/chochihim/status/1324182272304537600):

```javascript
// src/theme.js
const theme = {
  colors: {
    primary: 'var(--colors-primary)',
    background: 'var(--colors-background)',
  },
}
export {theme}

// anywhere-else.js
import {theme} from 'theme'

const PrimaryText = styled.div({
  padding: 20,
  color: theme.colors.primary,
  backgroundColor: theme.colors.background,
})
```

BOOM. Static typing-friendly.

Either way, that's really the only significant DX difference. Let's consider the UX (user experience) difference. Why don't you play around with it:

<iframe   src="https://codesandbox.io/embed/df90h?view=Editor+%2B+Preview&module=%2Fsrc%2Findex.js"   style={{     width: '100%',     height: '500px',     border: 0,     borderRadius: '5px',     overflow: 'hidden',   }}   title="CSS Variables vs ThemeProvider"   allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"   sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts" ></iframe>

You'll notice there's not really any observable UX difference, and there's not for this simple example. But why don't you try this with me:

1. pop open the React DevTools Profiler 2. Start a profiling session (click the little circle) 3. Click the toggle button for each 4. Stop the profiling session 5. Compare the two commits

Here's what I see:

**ThemeProvider:**

![Profiling session showing everything rendered](/articles-images/css-variables/theme-provider.png)

**CSS Variables:**

![Profiling session showing only one component rendered](/articles-images/css-variables/css-vars.png)

I don't want you to get hung up on the number of milliseconds to rerender. This isn't a controlled benchmark (we're in React's dev mode for one thing). The thing I want you to consider is how many components needed to re-render for this change. Let's consider the `ThemeProvider` approach first. The main reason for this is the way we've structured our state ([we could restructure things](https://kentcdodds.com/blog/optimize-react-re-renders) and improve it a little bit). But even if we restructured things, when the theme changes, _every_ emotion component needs to be re-rendered to account for the theme change.

Turning to the CSS Variables approach, you'll notice the only component that re-rendered was our `ThemeToggler` component responsible for updating the `body`. And yet the user experience works perfectly! This is the magic behind CSS variables. With the `ThemeProvider` approach, we have to update the styles of every component, and then the browser paints those updates. But with the CSS Variables approach, we update the styles to a single component (the `body`) and then the browser paints those updates. The browser paint should theoretically take the same amount of work on the part of the browser, so the only difference is how much work we're making the browser do to have React re-render all our components and get emotion to update the styles of every component.

This _can_ have negative performance implications as your app grows. Considering the DX isn't objectively better or worse either way, but the UX is quite possibly better with CSS Variables, I feel comfortable recommending CSS Variables over using Context to share a theme like this.

Oh, and consider also that CSS Variables are part of the browser spec and the ThemeProvider isn't. That's another solid point for CSS Variables 😉

This is one standard I'd suggest you embrace.

One last piece of nuance here. What if you not only want to change styles but _also_ want to change component implementations based on the theme? In this case... [YOU CAN DO BOTH](https://twitter.com/sebmarkbage/status/1324097255557767173)! The benefit of doing this is the only components that need to consume the context value are those that need to render differently based on the theme (which is likely a small subset). Most components can use the css variables for styling purposes only, so you'll still get the aforementioned benefits. If you don't _need_ components to render differently based on the theme then I wouldn't bother with this, but if you do, then it's pretty simple to do. There are several ways to accomplish this, I've done one implementation in [the codesandbox](https://codesandbox.io/s/css-variables-vs-themeprovider-df90h?file=/src/both/index.js). Enjoy exploring that.

CSS variables (custom properties) are awesome. Give them a look. Good luck!

How and why you should use CSS variables (custom properties) for theming instead of React context.

My State Management Mistake

So what now?

Get my free 7-part email course on React!

More Articles

How to type a React form onSubmit handler

Improve the Performance of your React Forms

The Big "Server Waterfall Problem" with RSCs

Use CSS Variables instead of React Context