When building React applications, you'll often work with data that only exists
on the client—such as items users add to a list before saving them to a server.
These objects usually don't have a unique ID yet, but you still need one for
things like React keys, form field associations, or other DOM relationships.

## Why You Need Unique IDs

Unique IDs are essential for:

- Rendering lists with stable React keys
- Associating labels with form fields
- Managing focus or accessibility relationships

If your data comes from a backend, it often already has an ID. But for
client-only data, you need to generate one yourself.

Don't generate a new ID on every render! Instead, generate the ID once—when the
object is created—and store it on the object. This ensures the ID stays stable
and unique. You don't necessarily need to use that ID if you end up saving that
object in a database or something, but to help React keep track of the items in
the list, you need to have a unique ID for each item.

### Using the Web Crypto API

The Web Crypto API provides a simple and reliable way to generate unique IDs:

```js
crypto.randomUUID()
```

This function returns a universally unique identifier (UUID) string, which is
perfect for most use cases.

## Example: Adding Items to a List

Here's a React component that lets users add items to a list. Each item gets a
unique ID when it's created:

```jsx
import React, { useState } from 'react'

function generateId() {
	return crypto.randomUUID()
}

function ItemList() {
	const [items, setItems] = useState([])
	const [input, setInput] = useState('')

	function handleAdd() {
		if (!input.trim()) return
		setItems([...items, { id: generateId(), label: input }])
		setInput('')
	}

	return (
		<div>
			<input
				value={input}
				onChange={(e) => setInput(e.target.value)}
				placeholder="Add an item"
			/>
			<button onClick={handleAdd}>Add</button>
			<ul>
				{items.map((item) => (
					<li key={item.id}>{item.label}</li>
				))}
			</ul>
		</div>
	)
}
```

When working with client-only data, it's important to generate unique IDs at the
time you create your objects, rather than generating them on every render. The
Web Crypto API's `crypto.randomUUID()` function provides a reliable way to
generate these unique identifiers. Make sure to store the ID directly on the
object when you create it - this ensures the ID remains stable and can be safely
used for React keys and DOM relationships.

For more on accessibility and unique IDs, check out the related article on
[generating unique IDs in React](/improving-react-accessibility-with-use-id-knljs).

Also check out [Why React Needs a Key Prop](/why-react-needs-a-key-prop) for
more on why you need to use a key prop.


Learn how to generate unique IDs for client-only data in React using the Web Crypto API, ensuring stable keys and accessible, dynamic UI components.

Generating Unique IDs for Client-Only Data in React

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.

Use CSS Variables instead of React Context

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

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

If you've used React for a while, you've probably run into this before:

```
index.js:1 Warning: Each child in a list should have a unique "key" prop.

Check the render method of `App`. See https://reactjs.org/link/warning-keys for more information.
    at li
    at App (http://localhost:3000/static/js/30.chunk.js:48:75)
```

You probably know the solution as well. Here's the rule:

**Whenever you're rendering an array of React elements, each one must have a unique `key` prop.**

Here's the simplest way to reproduce this problem:

```tsx
const items = [
  {id: 'apple', value: '🍎 apple'},
  {id: 'orange', value: '🍊 orange'},
  {id: 'grape', value: '🍇 grape'},
  {id: 'pear', value: '🍐 pear'},
]

function App() {
  return (
    <ul>
      {items.map((item) => (
        <li>{item.value}</li>
      ))}
    </ul>
  )
}
```

And the solution is pretty simple:

```diff
-         <li>{item.value}</li>
+         <li key={item.id}>{item.value}</li>
```

But like... Why? React doesn't seem to have a problem if I were to write it like this:

```tsx
function App() {
  return (
    <ul>
      <li>🍎 apple</li>
      <li>🍊 orange</li>
      <li>🍇 grape</li>
      <li>🍐 pear</li>
    </ul>
  )
}
```

It's only a problem if I try to pass the elements as an array. So yeah, why does React have such a big problem with arrays anyway?

First, if you want to understand what problems can happen without the `key` prop (and cool things you can do with it), read [Understanding React's key prop](https://kentcdodds.com/blog/understanding-reacts-key-prop). In this post, I just want to explain why React can't just magically make things work without a `key` prop.

I want you to pretend you're React and I'm a React developer building an application. I'm writing a function component called `App`. You don't get to see my implementation, all you get is the function which you can pass arguments to and receive a return value from.

So let's say I give you that function and tell you to render that to the page. So you call `App` and you get the following React elements back ([learn more about React elements](https://kentcdodds.com/blog/what-is-jsx)):

```js
const element = {
  type: 'ul',
  key: null,
  props: {
    children: [
      {type: 'li', key: null, props: {children: '🍎 apple'}},
      {type: 'li', key: null, props: {children: '🍊 orange'}},
      {type: 'li', key: null, props: {children: '🍇 grape'}},
      {type: 'li', key: null, props: {children: '🍐 pear'}},
    ],
  },
}
```

Ok, first, you're going to warn right? Because the `key` is `null` for all of those children. 😉 But really, it's fine. You're React and you know how to take these elements and render them to the page. So you render the `ul` and `li`s to the page. All's good.

Ok, so now my `App` calls a state updater function and so you know you need to re-render. So you call `App` again and this time you get some new React elements:

```javascript
const element = {
  type: 'ul',
  key: null,
  props: {
    children: [
      {type: 'li', key: null, props: {children: '🍎 apple'}},
      {type: 'li', key: null, props: {children: '🍊 orange'}},
      {type: 'li', key: null, props: {children: '🍐 pear'}},
    ],
  },
}
```

Ok, so you do a quick and easy diff here:

```diff
-      {type: 'li', key: null, props: {children: '🍇 grape'}},
```

Oh, cool, so you can just remove the `li` from the page right? Yeah, go ahead and just unmount it. Sure, do that. Easy-peasy.

Ooh! I need another state update, so you get the next set of React elements:

```javascript
const element = {
  type: 'ul',
  key: null,
  props: {
    children: [
      {type: 'li', key: null, props: {children: '🍊 apple'}},
      {type: 'li', key: null, props: {children: '🍐 pear'}},
    ],
  },
}
```

Now do another diff:

```diff
-       {type: 'li', key: null, props: {children: '🍎 apple'}},
-       {type: 'li', key: null, props: {children: '🍊 orange'}},
+       {type: 'li', key: null, props: {children: '🍊 apple'}},
```

Hmm... Ok, so now... Should remove the `🍎 apple` and `🍊 orange` `li`s and create a new one with `🍊 apple`? How certain are you that this is what I meant to do? Maybe what I actually want is to remove the `🍎 apple` and rename `🍊 orange` to `🍊 apple`... Or maybe I want to remove the `🍊 orange` and rename `🍎 apple` to `🍊 apple`. Or maybe I want to remove `🍐 pear`, then rename `🍊 orange` to `🍐 pear`, and then rename `🍎 apple` to `🍊 apple`...

Now you're thinking "Ugh. What the heck? Mr. Dodds. Give me a break."

So, as React, you do your best guess: You pretend the `key` is the `index`. I mean, you gotta do something right? This is what React actually does.

Interestingly, this means that rather than just unmounting the `🍇 grape` `li` on that first state update, you actually unmounted `🍐 pear` and updated `🍇 grape` to say `🍐 pear` 😂. But in a real app, this is no laughing matter. Unmounting and mounting components has implications on the state and side-effects of a component (which I describe in more detail in the aforementioned blog post).

And that also means with this last state update, you unmounted `🍐 pear` again and updated `🍎 apple` to be `🍊 apple` and `🍊 orange` got updated to say `🍐 pear`. What a disaster!

This is definitely not the most optimal, but what are you gonna do? You have no idea what I meant with that element change!

(By the way, I used [this code](https://codesandbox.io/s/romantic-kalam-mliwb?file=/src/index.js) to validate what was going on, if you want to poke around).

## In walks the `key` prop...

Phew... Wouldn't it be nice if I had given you some way to track the React elements from one render to the next so your diff could be more informative. That way you'd know my intent much better right?

Yeah, let's try that last one, only with `key`s this time:

```javascript
const element = {
  type: 'ul',
  key: null,
  props: {
    children: [
      {type: 'li', key: 'apple', props: {children: '🍎 apple'}},
      {type: 'li', key: 'orange', props: {children: '🍊 orange'}},
      {type: 'li', key: 'pear', props: {children: '🍐 pear'}},
    ],
  },
}
```

Ok, nice, so now here comes the update for you:

```javascript
const element = {
  type: 'ul',
  key: null,
  props: {
    children: [
      {type: 'li', key: 'apple', props: {children: '🍊 apple'}},
      {type: 'li', key: 'pear', props: {children: '🍐 pear'}},
    ],
  },
}
```

Ha! Now you know exactly what to do! You can now do a much more granular diff. First you notice that the element with the `key` of `'orange'` is gone, so you know you can remove that from the page. And the element with the `key` of `'apple'` has new `children` so you can simply update it and move on with life without worrying about whether you're doing the right thing.

Oh, and for our very first change when we removed the grape `li`, you can correctly just remove that one now too.

## Conclusion

Now that you've put yourself in React's shoes, hopefully you understand why React can't just magically know what you're doing with your elements and why you need to provide a `key` prop. Frankly, this is a limitation in React. It would be nice to not have this limitation, but not at the expense of React's simplicity (which is [what I love most about React](https://epicreact.dev/why-i-love-react)). I hope this article helped you get an solid understanding of why the `key` prop is needed when rendering arrays.

I'll leave you with one more thought... With your understanding of the `key` prop now, can you think of situations where you could use a `key` prop _outside_ an array? The `key` prop has less to do with arrays, and more to do with controlling when a component is reused or disposed of and created anew. Give that some thought 😄

Why can't React just magically know what to do without a key?

Generating Unique IDs for Client-Only Data in React

Why You Need Unique IDs

Using the Web Crypto API

Example: Adding Items to a List

Get my free 7-part email course on React!

More Articles

Use CSS Variables instead of React Context

My State Management Mistake

Improve the Performance of your React Forms

Why React needs a key prop