[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)

Let's say we've got a form that allows you to specify a username. When you try to submit an invalid value, it will show an error message and refocus on the input so you can fix your mistake.

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

function UsernameForm({
  initialUsername = '',
  onSubmitUsername,
}: {
  initialUsername?: string
  onSubmitUsername: (username: string) => void
}) {
  const [username, setUsername] = React.useState(initialUsername)
  const [touched, setTouched] = React.useState(false)

  const usernameInputRef = React.useRef<HTMLInputElement>(null)

  const usernameIsLowerCase = username === username.toLowerCase()
  const usernameIsLongEnough = username.length >= 3
  const usernameIsShortEnough = username.length <= 10
  const formIsValid =
    usernameIsShortEnough && usernameIsLongEnough && usernameIsLowerCase

  const displayErrorMessage = touched && !formIsValid

  React.useEffect(() => {
    if (displayErrorMessage) usernameInputRef.current?.focus()
  }, [displayErrorMessage])

  let errorMessage = null
  if (!usernameIsLowerCase) {
    errorMessage = 'Username must be lower case'
  } else if (!usernameIsLongEnough) {
    errorMessage = 'Username must be at least 3 characters long'
  } else if (!usernameIsShortEnough) {
    errorMessage = 'Username must be no longer than 10 characters'
  }

  function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
    event.preventDefault()
    setTouched(true)
    if (!formIsValid) return

    onSubmitUsername(username)
  }

  function handleChange(event: React.ChangeEvent<HTMLInputElement>) {
    setUsername(event.currentTarget.value)
  }

  function handleBlur() {
    setTouched(true)
  }

  return (
    <form name="usernameForm" onSubmit={handleSubmit} noValidate>
      <div>
        <label htmlFor="usernameInput">Username:</label>
        <input
          ref={usernameInputRef}
          id="usernameInput"
          type="text"
          value={username}
          onChange={handleChange}
          onBlur={handleBlur}
          pattern="[a-z]{3,10}"
          required
          aria-describedby={displayErrorMessage ? 'error-message' : undefined}
        />
      </div>
      {displayErrorMessage ? (
        <div role="alert" className="error-message">
          {errorMessage}
        </div>
      ) : null}
      <button type="submit">Submit</button>
    </form>
  )
}
```

There's a bit going on there, but let's zoom in on the `useEffect`. That's responsible for focusing the input when an error is displayed so the user can fix the problem.

```tsx
React.useEffect(() => {
  if (displayErrorMessage) usernameInputRef.current?.focus()
}, [displayErrorMessage])
```

If you know me, you know that [I'm a firm proponent](/myths-about-useeffect) of the `exhaustive-deps` rule from the [`eslint-plugin-react-hooks`](https://www.npmjs.com/package/eslint-plugin-react-hooks) package. So you might wonder why my dependency array doesn't include: `usernameInputRef.current`. Isn't that one of the dependencies of my effect callback? After all, what would happen if that value were to change?

Well, let's try adding it to the array:

```tsx
React.useEffect(() => {
  if (displayErrorMessage) usernameInputRef.current?.focus()
}, [displayErrorMessage, usernameInputRef.current])
```

Ah, we get a lint warning from the `exhuastive-deps` rule:

```
React Hook React.useEffect has an unnecessary dependency: 'usernameInputRef.current'.
Either exclude it or remove the dependency array.
Mutable values like 'usernameInputRef.current' aren't valid dependencies because
mutating them doesn't re-render the component.
eslint(react-hooks/exhaustive-deps)
```

Alright, let's dig into that warning. Remember:

**`useRef` is similar to `useState` except changing the value doesn't trigger a re-render.**

In our example above, we're using `useRef` to keep track of a DOM node, but you can use it to keep track of any value whatsoever, just like `useState` (bet you didn't think about putting a function in `useState` before did you 😉, you totally can though).

The fact that an update the a `ref.current` value doesn't trigger a re-render is an intentional feature. React doesn't keep track of the `current` value of a ref. You're responsible for referencing and mutating that value yourself. Because referencing DOM nodes is such a common use case, React will set the `current` value for you when you pass a `ref` prop to an element. But other than that, all React promises is that it will store your object and associate it to a particular instance of a component for as long as that component exists.

By the way, that's what differentiates a `ref` from just a regular variable outside the component. `useRef` ensures that the value is associated with a particular instance of a component.

Alright, so let's bring this back to the warning. Let's recall the purpose of a dependency array: It's there so React can do something when there are changes in the values provided each time the component renders. And that's the answer right there! React can't know that the value changed if a change doesn't trigger a render! Here's a quick contrived example:

```tsx
function Counter() {
  const countRef = React.useRef(0)

  React.useEffect(() => {
    console.log(countRef.current)
  }, [countRef.current])

  const increment = () => (countRef.current += 1)
  return <button onClick={increment}>Click me</button>
}
```

I can click that button over and over again, but I'm never going to get that `useEffect` callback to run again because there's no re-render associated to the update in the value, I won't get any updated logs!

"_But Kent_" you ask, "_what if I *want* an update to a ref to result in a re-render?_" If that's the case, what you actually want is `useState`/`useReducer`, not `useRef`!

## The rule that governs exceptions to the `exhaustive-deps` rule

So refs are an exception to the `exhaustive-deps` rule, but they're actually not the only exception. The exception itself is general. Here's the general rule for the exception:

**Anything you use in your effect callback that won't trigger a re-render when updated should not go into the dependency array.**

Additionally (and consequentially), you should not expect any change in such values to result in the effect callback getting called. If you _need_ the callback to be called when those things change, then you _need_ to put it in `useState` (or `useReducer`).

This general rule is why if you pass the value of a module-level variable into a dependency array like this you'll get a similar lint warning:

```tsx
let log = console.log

function Comp() {
  React.useEffect(() => {
    log(new Date())
  }, [log]) // <-- 🚨 eslint warning here
  return <div>{/* stuff here */}</div>
}
```

Here's what the linter will tell you about that:

```
React Hook React.useEffect has an unnecessary dependency: 'log'.
Either exclude it or remove the dependency array. Outer scope values like 'log'
aren't valid dependencies because mutating them doesn't re-render the component.
eslint(react-hooks/exhaustive-deps)
```

This is because even if I did reassign that `log` variable to something else at some point, React wouldn't know about it so you'd end up with a stale side-effect anyway. So just don't list it, and if you _do_ want a change to trigger the effect to run, then put it in state!

Same thing happens with imports (with the added benefit of the fact that you can't reassign these values anyway):

```tsx
import log from './logger'

function Comp() {
  React.useEffect(() => {
    log(new Date())
  }, [log]) // <-- 🚨 eslint warning here
  return <div>{/* stuff here */}</div>
}
```

The lint warning for this is actually identical to the variable form.

## Custom hooks and the ref object itself

You won't get a warning with code like this:

```tsx
function Comp() {
  const logRef = React.useRef(console.log)
  React.useEffect(() => {
    logRef.current(new Date())
  }, []) // <-- ✅ No eslint warning here
  return <div>{/* stuff here */}</div>
}
```

That's because you're not using any values in your `useEffect` that the lint plugin knows can change on re-renders.

However, you also won't get a warning with code like this:

```tsx
function Comp() {
  const logRef = React.useRef(console.log)
  React.useEffect(() => {
    logRef.current(new Date())
  }, [logRef]) // <-- ✅ No eslint warning here
  return <div>{/* stuff here */}</div>
}
```

That's because the `logRef` value _can never change_. So it actually makes no difference whether you include it or not and I guess the authors of the lint rule decided to not bother you about something that doesn't matter. Good call.

But here's an interesting case. What about a custom hook that accepts a ref?

```tsx
function useDateCall(cbRef) {
  React.useEffect(() => {
    cbRef.current(new Date())
  }, []) // <-- 🚨 eslint warning here
}

function Comp() {
  const logRef = React.useRef(console.log)
  useDateCall(logRef)
  return <div>{/* stuff here */}</div>
}
```

The warning we get there is:

```
React Hook React.useEffect has a missing dependency: 'cbRef'.
Either include it or remove the dependency array.
eslint(react-hooks/exhaustive-deps)
```

The reason we get the warning there when we didn't get it within the component is because ESLint is pretty limited in its ability to trace what you're doing with your JavaScript. So the React plugin for ESLint can't know that `cbRef` is actually a `ref`. So just to be safe, it warns you.

Luckily, as we just learned, including it in the dependency array doesn't make any difference anyway, so just include it!

```tsx
function useDateCall(cbRef) {
  React.useEffect(() => {
    cbRef.current(new Date())
  }, [cbRef]) // <-- ✅ No eslint warning here
}

function Comp() {
  const logRef = React.useRef(console.log)
  useDateCall(logRef)
  return <div>{/* stuff here */}</div>
}
```

And we're all good.

## Conclusion

So the reason you shouldn't list a ref in your `useEffect` dependency array is because it's an indication that you want the effect callback to re-run when a value is changed, but you're not notifying React when that change happens. So the solution is to either:

1. Not include it in the array 2. Put that value in `useState`/`useReducer` so an update will trigger a render.

Hope that cleared up some confusion for you! Good luck.

If you use a ref in your effect callback, shouldn't it be included in the dependencies? Why refs are a special exception to the rule!

Why you shouldn't put refs in a dependency array

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

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

In my post ["How React Uses Closures to Avoid Bugs"](https://epicreact.dev/how-react-uses-closures-to-avoid-bugs) I explain some of the trade-offs React made when they switched from classes and lifecycles to functions and hooks. I want to dig a little deeper on this topic.

In that post, I share the following example:

```javascript
function useDebounce(callback, delay) {
  const callbackRef = React.useRef(callback)

  React.useLayoutEffect(() => {
    callbackRef.current = callback
  })

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

I want to talk a bit about this pattern that my friend [Yago](https://twitter.com/yagopereiraaz) (who created the original hook) likes to call "The Latest Ref Pattern."

The pattern itself is pretty simple. Here's the part that's the pattern:

```javascript
const callbackRef = React.useRef(callback)

React.useLayoutEffect(() => {
  callbackRef.current = callback
})
```

<small><a href="https://kcd.im/uselayouteffect">Curious about <code>useLayoutEffect</code>?</a></small>

That's it. That's the pattern.

So why would you want to do this? Well, let's think about when you use `useRef`. You use `useRef` whenever you want to keep track of a value, but not trigger a re-render when you update it. So in our case, we're trying to keep track of `callback`. The reason for this, is we want to make sure that we're always calling the latest version of the `callback` rather than one from an old render.

But why don't we use `useState` instead? Could we keep track of this latest callback value in an actual state value? We don't want to use `useState` because we don't need to trigger a component re-render when we update to the latest value. In fact, in our case if we tried, we'd trigger an infinite loop (go ahead, try it 😈).

And because we don't need or want a re-render when we update the `callback` to the latest value, it means we also don't need to (and really shouldn't) include it in a dependency array for `useEffect`, `useCallback`, or in our case `useMemo`. This is an important point, so I want to dive into it a bit.

It's really important that you follow the `eslint-plugin-react-hooks/exhaustive-deps` rule and always include all dependencies. But you _should_ skip the `current` value of a ref. So don't ever do this:

```javascript
// ❌ don't ever do this
React.useEffect(() => {}, [ref.current])
```

This is because updating a ref doesn't trigger a re-render anyway, so React can't call the effect callback or update memoized values when the ref is updated. So if you include `ref.current` in the dependency array, you'll get surprising behavior that's difficult to debug. As a side-note, because the `ref` itself is a stable object, it doesn't make a difference if you include the `ref` object itself in your dependency array:

```javascript
// 🤷‍♂️ doesn't make a difference whether you include the ref or not.
React.useEffect(() => {}, [ref])
```

You can run into some serious bugs if you don't include all your non-ref deps though, so just please, don't ignore [the linting rule](https://www.npmjs.com/package/eslint-plugin-react-hooks) for this.

## Conclusion

Before using "the latest ref pattern" everywhere, I suggest you get a good understanding for what it is you're side-stepping, so if you haven't already, give ["How React Uses Closures to Avoid Bugs"](https://epicreact.dev/how-react-uses-closures-to-avoid-bugs) a read-through. That'll help you get a better idea of when it can be useful to use this particular pattern. I'd love to hear situations when you find this pattern useful. [Tweet @ me](https://twitter.com/intent/tweet?text=Hey%20@kentcdodds,%20I%20read%20https://epicreact.dev/the-latest-ref-pattern-in-react.%20Here%27s%20how%20I%20use%20the%20latest%20ref%20pattern.).

Take care 👍

How to improve your custom hook APIs with a simple pattern.

Render as you fetch (with and without suspense)

Get my free 7-part email course on React!

More Articles

Why you shouldn't put refs in a dependency array

Improve the Performance of your React Forms

Why you've been bad about Profiling React Apps

The Latest Ref Pattern in React