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

## Why React Server Components Matter

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

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

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

## Addressing the Pain Points

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

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

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

## The Promise of React Server Components

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

### Looking Ahead with Optimism

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

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

## What to do now?

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

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

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

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

React Server Components: The Future of UI

Here’s a simple React component:

```tsx
type User = { firstName: string; lastName: string }

function UserCard(props: { user: User }) {
	return (
		<div className="user-card">
			<h2>
				{props.user.firstName} {props.user.lastName}
			</h2>
		</div>
	)
}
```

Now, let’s say the boss asks you to please lowercase the user’s name. There are a few ways we could go about doing this, but it begs the question, could we just modify the props?

```tsx
type User = { firstName: string; lastName: string }

function UserCard(props: { user: User }) {
	props.user.firstName = props.user.firstName.toLowerCase()
	props.user.lastName = props.user.lastName.toLowerCase()

	return (
		<div className="user-card">
			<h2>
				{props.user.firstName} {props.user.lastName}
			</h2>
		</div>
	)
}
```

Technically, yes, this will correctly lowercase the user’s first and last name, however, we need to talk about encapsulation.

Encapsulation is a very important concept in programming. It is the idea that separate components are isolated from one another. In React, this allows the components to be reusable. The parent component doesn't need to understand the implementation details of the component it renders because of this isolation. And the component itself doesn't need to know about the parent component.

However, if the props passed down to the parent component are modified, this breaks that encapsulation and can present surprises. For example:

```tsx
type User = { firstName: string; lastName: string }

function UserCard(props: { user: User }) {
	props.user.firstName = props.user.firstName.toLowerCase()
	props.user.lastName = props.user.lastName.toLowerCase()

	return (
		<div className="user-card">
			<h2>
				{props.user.firstName} {props.user.lastName}
			</h2>
		</div>
	)
}

function App() {
	const user = { firstName: 'Bob', lastName: 'Jones' }

	return (
		<div>
			<UserCard user={user} />
			<button onClick={() => alert(`Hello, ${user.firstName}!`)}>Greet</button>
		</div>
	)
}
```

When you click the button, you’ll get `Hello, bob`. This is surprising behavior if you don’t know what the `UserCard` component is doing.

Now, we could avoid this if we do things a little differently here. How about instead of passing the user object, we pass the `firstName` and `lastName` properties directly? We could do `<UserCard firstName={user.firstName} lastName={user.lastName} />` or even just `{...user}` which is effectively the same thing.

```tsx
function UserCard(props: { firstName: string; lastName: string }) {
	props.firstName = props.firstName.toLowerCase()
	props.lastName = props.lastName.toLowerCase()

	return (
		<div className="user-card">
			<h2>
				{props.firstName} {props.lastName}
			</h2>
		</div>
	)
}

function App() {
	const user = { firstName: 'Bob', lastName: 'Jones' }

	return (
		<div>
			<UserCard {...user} />
			<button onClick={() => alert(`Hello, ${user.firstName}!`)}>Greet</button>
		</div>
	)
}
```

This will not suffer from the same issue, but we’ll get an error from React:

```
TypeError: Cannot assign to read only property 'firstName' of object '#<Object>'
```

This is because the props object React passes to your component has read only properties (using [Object.defineProperties](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperties)). This is React helping us avoid breaking encapsulation. By modifying props it reduces our confidence in the one-way data flow. It’s not a big issue with the way we’re doing things here, but what if we did something like this:

```tsx
function UserCard(props: { firstName: string; lastName: string }) {
	return (
		<div className="user-card">
			<h2>
				{props.firstName} {props.lastName}
			</h2>
			<button
				onClick={() => {
					props.firstName = props.firstName.toLowerCase()
					props.lastName = props.lastName.toLowerCase()
				}}
			>
				lowercase them
			</button>
		</div>
	)
}
```

What’s supposed to happen in the `onClick`? Presumably we want the UI to show the names as lower cased, but that wouldn’t happen because in React mutation is not a mechanism for re-rendering. This is one of my favorite parts of React honestly, but I digress.

So, React isn’t allowing us to modify the props, and modifying properties of an object passed through props can lead to issues as well. So what can we do? Well, here’s something we could do:

```tsx
function UserCard(props: { firstName: string; lastName: string }) {
	const lowerFirstName = props.firstName.toLowerCase()
	const lowerLastName = props.lastName.toLowerCase()

	return (
		<div className="user-card">
			<h2>
				{lowerFirstName} {lowerLastName}
			</h2>
		</div>
	)
}
```

That works fine. Or you could also just inline it:

```tsx
function UserCard(props: { firstName: string; lastName: string }) {
	return (
		<div className="user-card">
			<h2>
				{props.firstName.toLowerCase()} {props.lastName.toLowerCase()}
			</h2>
		</div>
	)
}
```

Or, you could even do this:

```tsx

function UserCard({
	firstName,
	lastName,
}: {
	firstName: string
	lastName: string
}) {
	firstName = firstName.toLowerCase()
	lastName = lastName.toLowerCase()

	return (
		<div className="user-card">
			<h2>
				{firstName} {lastName}
			</h2>
		</div>
	)
}
```

Now this last one might have you surprised a bit. We’re destructuring the props, but then we’re reassigning them. How is this different from modifying props? It’s different because we’re not actually changing the values on the props object, we’re simply reassigning the variables we made in the process of destructuring.

I find myself doing this occasionally if I don’t want to bother creating and naming a separate variable and I have no need of the original value. And because it’s a variable reassignment rather than an object mutation, it doesn’t suffer from the problem React is trying to protect us against.

So there you are. This is why React doesn’t allow you to mutate props and why you should try. In general, there are only a few situations where you would consider mutation in a React application (I’m looking at you `useRef` 👀). For the most part, rely on React’s single-way data flow and explicit state updates through `setState` via `useState` and `dispatch` via `useReducer` and you’ll find the data flow in your application is much simpler to follow.

Cheers!

Why encapsulation is important and how handle props so your components remain reusable and your application's data flow stays predictable.

React components should not modify props directly. Learn why encapsulation is important and explore different approaches to handle props correctly in React, ensuring your components remain reusable and your application's data flow stays predictable.

Can you modify React Props?

React is a JavaScript library for creating user interfaces and managing user interactions. React is used primarily for building web applications in browsers, but the component model is so powerful that it can be used to create native mobile and desktop applications, images, PDFs, terminal applications, and much more.

As a result of React’s success with the component-based model of interface composition, many other UI libraries and frameworks have adopted this approach with their own flare. However, React has been *(by a large margin)* **the dominant way** to build user interfaces for many years now and will likely remain that way as long as you or I continue to develop software on the web.

Let’s go a little deeper and look at the pieces that make up React.

## React’s core building block

The foundational component of user interfaces built with React are elements:

```tsx
import { createElement } from 'react'

const element = createElement('button', { onClick: () => console.log('clicked!') }, 'Click me!')
```

If we inspect the element that React’s created, it looks like this:

```tsx
{
  "$$typeof": Symbol(react.element),
  "type": "button",
  "key": null,
  "ref": null,
  "props": {
    "onClick": () => console.log('clicked!'),
    "children": "Click me!"
  },
  "_owner": null,
  "_store": {}
}
```

This object (which I call a “UI descriptor”) is used to generated UI that’s native to the environment it’s rendered in. In our case we want to generate UI for the browser, so we use the React DOM package to convert this UI into DOM nodes that the browser can understand.

This separation between React elements and DOM elements is part of what makes your React knowledge (or even code) portable to environments other than the browser.

## JSX

Using the `createElement` API directly is not very ergonomic, so when React was initially announced it came with a special lightweight syntax addition to JavaScript to make it easier to create elements. With that syntax, you can create that same button like this

```tsx
const element = <button onClick={() => console.log('clicked!')}>Click me!</button>
```

Because this is a syntax addition that browsers don’t natively run, you need to compile your code before the browser can interpret it. You can technically do this right in the browser (I built an app I used daily for years that did things this way actually), but it’s not optimal.

In most apps, you’ll be using a tool to convert your JavaScript anyway. You’ll at least want a minifier to reduce the amount of text you send over the network and likely a bundler to reduce the number of files the browser has to load. On top of this, especially in anything serious, you’ll want to use TypeScript which supports JSX natively.

Writing UI in this way is delightful. It takes most developers just a few hours of study and practice to understand how JSX translates to regular JavaScript, then you can be highly effective working in the syntax because it’s basically just JavaScript anyway.

## Reusable elements: Components

As React is written in JavaScript, you can of course create parameterized functions which return React elements. React has formalized this in something called a component and it’s how you can create custom React elements. To top it off, you can parameterize these components using something called “props” which is an object received by your component:

```tsx
function ClickMeButton(props) {
  return <button onClick={props.onClick}>Click me!</button>
}
```

You can then create that element like other elements:

```tsx
const element = <ClickMeButton onClick={() => console.log('clicked!')} />
```

Here’s what that element object looks like:

```tsx
{
  "$$typeof": Symbol(react.element),
  "type": ClickMeButton,
  "key": null,
  "ref": null,
  "props": {
    "onClick": () => console.log('clicked!')
  },
  "_owner": null,
  "_store": {}
}
```

When React is ready to render this UI, it will call your function with the props to retrieve the other elements it needs to render.

This API enables React components to compose together in beautifully powerful ways that a decade later we’re still benefitting from. It enables us to build highly reusable abstractions. For example, you could package up all the accessibility requirements for a tabs UI in a couple components that work together and offer something like this:

```tsx
<Tabs defaultValue="account">
  <TabsList>
    <TabsTrigger value="account">Account</TabsTrigger>
    <TabsTrigger value="password">Password</TabsTrigger>
  </TabsList>
  <TabsContent value="account">Make changes to your account here.</TabsContent>
  <TabsContent value="password">Change your password here.</TabsContent>
</Tabs>
```

Composition is the name of the game when it comes to React, even between server-only code which generates the UI and client-side code which makes the UI interactive. Speaking of making the UI interactive…

## Updating UIs with React

React not only helps you generate the initial UI, but also manage changes to that UI over time. Whether you’re building an interactive experience for users, or a dashboard that updates in the background, React will help you keep your UI up-to-date.

Data is used to generate the UI. When that data can change over time, we call it state. In React, you can manage this state a number of ways, but the primary mechanism is via a function called `useState` . This function can only be used within custom components so React knows what UI to update when the state changes:

```tsx
function Counter() {
  const [count, setCount] = useState(0)
  const increment = () => setCount((c) => c + 1)
  return <button onClick={increment}>Current Count: {count}</button>
}
```

Whenever the user clicks the button, `setCount` is called which notifies React that the state value needs to be changed and React needs to retrieve the new elements based on that new value.

As mentioned, there are several ways to manage state built-into React, but the basic idea is always the same: an update happens, React calls the component again with the updated value, React compares what you return this time with what was returned last time and updates the DOM accordingly. In our case the `textContent` of the `button` will be updated each time the button is clicked.

## So, what is React?

Like I said at the start, React is a JavaScript library for creating user interfaces and managing user interactions. There are of course more things to talk about when it comes to building web applications with the most widely used tool in the business with the biggest ecosystem, but this is as far as we’ll take it today.

I’m going to be publishing a lot of articles diving deeper in these aspects and others (so sign up to be notified when they become available!).

React has evolved over the last more than decade since its original release, but the core concept of composability has remained and been pushed further and further over the years. I’ve never been more excited about building applications with React and it just keeps getting better. Thanks for joining me for the ride!

Let's contextualize the most widely used UI framework in the world: React.

Whether you're brand new to building dynamic web applications or you've been working with React for a long time, let's contextualize the most widely used UI framework in the world: React.

What is React?

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

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?

Why React needs a key prop

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

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.

The Latest Ref Pattern in React

So, you've got some code in `React.useEffect` and you want to know how to test it. This is a pretty common question. The answer is kinda anti-climatic and general. Here's how you think about testing _anything_:

> How does the user make that code run? Make your test do that.

That's it. That's the secret. The trick is discovering what constitutes a "user." Your React components actually have 2 users: the developer who renders it and the end-user who interacts with it. Generally, your tests should do no more or less than what these users do. For more on this, read [Avoid the Test User](https://kentcdodds.com/blog/avoid-the-test-user).

So, let's take a look at an example. I'll grab some code from one of the exercises in [EpicReact.dev/app](https://epicreact.dev/app) (it's a pretty long example, feel free to scan it quickly):

```javascript
/** @jsx jsx */
import {jsx} from '@emotion/core'

import * as React from 'react'
import Tooltip from '@reach/tooltip'
import {FaSearch, FaTimes} from 'react-icons/fa'
import {Input, BookListUL, Spinner} from './components/lib'
import {BookRow} from './components/book-row'
import {client} from './utils/api-client'
import * as colors from './styles/colors'

function DiscoverBooksScreen() {
  const [status, setStatus] = React.useState('idle')
  const [data, setData] = React.useState()
  const [error, setError] = React.useState()
  const [query, setQuery] = React.useState()
  const [queried, setQueried] = React.useState(false)

  const isLoading = status === 'loading'
  const isSuccess = status === 'success'
  const isError = status === 'error'

  React.useEffect(() => {
    if (!queried) {
      return
    }
    setStatus('loading')
    client(`books?query=${encodeURIComponent(query)}`).then(
      (responseData) => {
        setData(responseData)
        setStatus('success')
      },
      (errorData) => {
        setError(errorData)
        setStatus('error')
      },
    )
  }, [query, queried])

  function handleSearchSubmit(event) {
    event.preventDefault()
    setQueried(true)
    setQuery(event.target.elements.search.value)
  }

  return (
    <div
      css={{maxWidth: 800, margin: 'auto', width: '90vw', padding: '40px 0'}}
    >
      <form onSubmit={handleSearchSubmit}>
        <Input
          placeholder="Search books..."
          id="search"
          css={{width: '100%'}}
        />
        <Tooltip label="Search Books">
          <label htmlFor="search">
            <button
              type="submit"
              css={{
                border: '0',
                position: 'relative',
                marginLeft: '-35px',
                background: 'transparent',
              }}
            >
              {isLoading ? (
                <Spinner />
              ) : isError ? (
                <FaTimes aria-label="error" css={{color: colors.danger}} />
              ) : (
                <FaSearch aria-label="search" />
              )}
            </button>
          </label>
        </Tooltip>
      </form>

      {isError ? (
        <div css={{color: colors.danger}}>
          <p>There was an error:</p>
          <pre>{error.message}</pre>
        </div>
      ) : null}

      {isSuccess ? (
        data?.books?.length ? (
          <BookListUL css={{marginTop: 20}}>
            {data.books.map((book) => (
              <li key={book.id} aria-label={book.title}>
                <BookRow key={book.id} book={book} />
              </li>
            ))}
          </BookListUL>
        ) : (
          <p>No books found. Try another search.</p>
        )
      ) : null}
    </div>
  )
}

export {DiscoverBooksScreen}
```

> Keep in mind that the above example would be better with `useReducer` and we > get to improving this later in the workshop exercises.

Let's look at this bit specifically:

```javascript
React.useEffect(() => {
  if (!queried) {
    return
  }
  setStatus('loading')
  client(`books?query=${encodeURIComponent(query)}`).then(
    (responseData) => {
      setData(responseData)
      setStatus('success')
    },
    (errorData) => {
      setError(errorData)
      setStatus('error')
    },
  )
}, [query, queried])

function handleSearchSubmit(event) {
  event.preventDefault()
  setQueried(true)
  setQuery(event.target.elements.search.value)
}
```

Because we've properly mocked our backend using [MSW](https://mswjs.io/) (learn more about that in [Stop Mocking Fetch](https://kentcdodds.com/blog/stop-mocking-fetch)), we can actually make that request and get results. So let's interact with this component just the same way the end user would. Here's a test that actually works with this code:

```javascript
import * as React from 'react'
import {
  render,
  screen,
  waitForElementToBeRemoved,
  within,
} from '@testing-library/react'
import userEvent from '@testing-library/user-event'
import {DiscoverBooksScreen} from '../discover.extra-1'

// Learn more: https://kentcdodds.com/blog/stop-mocking-fetch
import {server} from 'test/server'
beforeAll(() => server.listen())
afterAll(() => server.close())
afterEach(() => server.resetHandlers())

test('queries for books', async () => {
  // 🤓 this is what developer users do
  render(<DiscoverBooksScreen />)

  // 🤠 this is what end users do
  userEvent.type(
    screen.getByRole('textbox', {name: /search/i}),
    'Sanderson{enter}',
  )
  // 🤠 end users will also note the presence of the loading indicator
  // and wait until it's gone before making som assertions
  await waitForElementToBeRemoved(() => screen.getByLabelText(/loading/i))

  // 🤠 end users will look at all the items in the list to see the book titles
  // Also, assistive technologies will take advantage of the implicit "listitem"
  // ARIA role of our `li` elements.
  const results = screen.getAllByRole('listitem').map((listItem) => {
    return within(listItem).getByRole('heading', {level: 2}).textContent
  })
  // I rarely use snapshots, but this seemed like a pretty good application:
  // https://kcd.im/snapshots
  expect(results).toMatchInlineSnapshot(`
    Array [
      "The Way of Kings (Book 1 of the Stormlight Archive)",
      "Words of Radiance (Book 2 of the Stormlight Archive)",
      "Oathbringer (Book 3 of the Stormlight Archive)",
    ]
  `)
})
```

There are other ways I could write this test (there are some important things that happen in that `test/server` module that we don't have time to cover in this post), but the principles are all the same:

> How does the user make that code run? Make your test do that.

Stated differently:

> The more your tests resemble the way your software is used, the more > confidence they can give you. > [– me](https://twitter.com/kentcdodds/status/977018512689455106)

So don't try mocking `useEffect` or `useState` or whatever. Stay away from that third user (the dreaded test user). The only thing that user is good for is turning you into a glorified test babysitter. And I don't know about you, but I'd rather ship awesome stuff to real people.

Testing React.useEffect is much simpler than you think it is.

How to Test React.useEffect

When the world moved from React class components and lifecycle methods to React function components and hooks, we left behind a bug that many of us didn't even know was plaguing our class-based codebases. This bug was sneaky, hard to identify and reproduce, and it would pop up in places due to seemingly harmless changes over time. To make matters worse, the situations where it pops up are not always bugs, sometimes it's an intended behavior. So you can't even lint against it.

The bug has to do with the mutability of `this.props`. I'm not talking about _you_ the developer mutating `this.props` (you shouldn't do that). I'm talking about when the parent component re-renders and passes new props, `this.props` suddenly points to completely new values. This is by design. I mean, when your `render` method re-runs due to an update in the props, you don't want to render the old props. You want the latest values so the React elements you return shows the right information.

The problem is actually pretty simple. It typically crops up when you have an event handler or lifecycle method that does something asynchronous. Imagine, you start the async thing, then props change while that is in flight, when your code continues `this.props` has the latest values rather than the values that existed at the time the function started running.

Let's add some clarity to this. I've put together [a little demo](https://react-and-stale-closures.netlify.app) which you can play with below. When you click on the ❤️ button, that'll toggle the liked state, but it has to do an async check to determine whether you're permitted to like/unlike the post. That's hard-coded to take 3 seconds to give you time to experience the problem. The specific use case is irrelevant. What matters more is the fact that `this.props` gets changed from beneath you during that async operation.

So, in the demo below, try this:

1. Click the ❤️ button 2. Before the 3 seconds time is up, change the post selection 3. Observe differences

<ReactAndStaleClosuresDemo />

You should observe that with the broken examples (like "The Old Default with Classes"), the post that's updated is the currently active post.

Here's the code for that post (structured to optimize for minimizing distraction):

```javascript
import * as React from 'react'
import {AppContext} from './provider'
import {canLike} from './utils'
import {PostView} from './post-view'

class Post extends React.Component {
  static contextType = AppContext
  handleLikeClick = async () => {
    if (!(await canLike(this.props.post, this.context.user))) return

    this.context.toggleLike(this.props.post)
  }
  render() {
    return (
      <PostView post={this.props.post} onLikeClick={this.handleLikeClick} />
    )
  }
}

export {Post}
```

The important bit here is the `canLike` utility that takes a while to run. So when you click on ❤️, the code execution "pauses" for a little while before continuing to the `this.context.toggleLike(this.props.post)` call. This means that when you change the active post, `this.props.post` is pointing to the wrong thing and the `toggleLike` call goes to the new post, not the one we were trying to like.

This is easily solved, as demonstrated in the "Simulating The New Default with Classes" example:

```javascript
handleLikeClick = async () => {
  const {post} = this.props
  const {user, toggleLike} = this.context
  if (!(await canLike(post, user))) return

  toggleLike(post)
}
```

Basically, we create a variable for everything our function is going to need before we call the async `canLike` function. That way it doesn't matter what happens with `this.props`, we're always referencing what `this.props.post` was at the time ❤️ was clicked, which is what the user intended.

Oh, and did you notice the other potential bug that the refactor avoided? No? Well you may have noticed that I _also_ destructure `user` and `toggleLike` from `this.context`. This isn't just because I like the convention of destructuring things at the top of the function. It's because if the `toggleLike` function were to change on us during that async call then we may be calling a new version of that function which references a different `user` resulting in that _new_ user liking the post instead of the one who clicked the button.

This bug bit me a few times with class components, so much that I created a convention for myself to always destructure everything I needed from `this.` in a function at the top of the function (like in the solution above).

But wouldn't it be better if we just changed the default? Yup! And that's what hooks did for us!

Here's the code for "The New Default with Hooks" example:

```javascript
import * as React from 'react'
import {useApp} from './provider'
import {canLike} from './utils'
import {PostView} from './post-view'

function Post(props) {
  const {user, toggleLike} = useApp()

  async function handleLikeClick() {
    if (!(await canLike(props.post, user))) return

    toggleLike(props.post)
  }

  return <PostView post={props.post} onLikeClick={handleLikeClick} />
}

export {Post}
```

In this case, we don't need to worry because the `props` our component is called with each render will _never_ change for all functions in the component. This is because each render, all functions are created as brand-new functions. And when a function is created, it grabs a reference to all variables outside of itself and hangs onto it for as long as that function exists.

When a re-render is triggered, a new `props` object is created and passed to our function component. At that time a _brand new_ `handleLikeClick` is created which has reference to the latest version of `props`. But if an old version of that function is still running, it's fine because it still has access to the version of props it was called with to begin with. (If this concept is not sinking in, you can learn more about [how closures work here](https://whatthefork.is/closure)).

One interesting observation is that this example actually has nothing to do with classes vs hooks, but really classes vs function components. But the same could be said of `componentDidMount` vs `useEffect`.

Function components flip the default, and I would argue that it's a good trade that helps us avoid that surreptitious bug.

## Simulate the old default

Just like it's possible to simulate the hooks default behavior with class components, it's possible to simulate the classes default behavior with function components. Here's the code for that example:

```javascript
import * as React from 'react'
import {useApp} from './provider'
import {canLike} from './utils'
import {PostView} from './post-view'

function Post(props) {
  const {user, toggleLike} = useApp()

  const postRef = React.useRef(props.post)
  React.useEffect(() => {
    postRef.current = props.post
  })

  async function handleLikeClick() {
    if (!(await canLike(postRef.current, user))) return

    toggleLike(postRef.current)
  }

  return <PostView post={props.post} onLikeClick={handleLikeClick} />
}

export {Post}
```

Refs allow you to update a value without trigger re-renders. It gives you a similar mutable API to `this.` (when refactoring class components, `useRef` is my go-to for any instance values if I can't simplify things as variables within a single `useEffect`).

Of course, the above example is buggy, so you wouldn't do that. But are there situations where the old default was a good idea? Most certainly! A good example of such a case is a `debounce` function like this one [Yago](https://twitter.com/yagopereiraaz) shared with me during my office hours recently.

Here's a naive implementation of `debounce`:

```javascript
function debounce(fn, delay) {
  let timer
  return (...args) => {
    clearTimeout(timer)
    timer = setTimeout(() => {
      fn(...args)
    }, delay)
  }
}
```

And here's a naive implementation of a `useDebounce` hook:

```javascript
function useDebounce(callback, delay) {
  return debounce(callback, delay)
}
```

Unfortunately, that won't work because you be creating a brand new `debounce`ed version of your function every render which results in the `debounce` `timer` variable being different for each one so the debounce is actually just a `delay` and doesn't actually debounce anything. So let's memoize that:

```javascript
function useDebounce(callback, delay) {
  return React.useMemo(() => debounce(callback, delay), [callback, delay])
}
```

The `callback` and `delay` are required, otherwise you'd end up with a debounce function that can't react to changes in the `delay` and it would always call an old version of the `callback` which would have access to old variables and likely result in bugs.

However, this API means that someone would have to memoize the `callback` otherwise you'd get a new debounce function every render which brings us back to the problem that lead to use memoizing this in the first place:

```javascript
const myFn = React.useCallback(() => {
  // do debounced stuff
}, [vars, i, need])
const debouncedMyFn = useDebounce(myFn, 500)
```

But that's not a great API. This is one situation where the new default as described above doesn't work very well. But we can use refs to get around the problem!

```javascript
function useDebounce(callback, delay) {
  const callbackRef = React.useRef(callback)
  // Why useLayoutEffect? -> https://kcd.im/uselayouteffect
  React.useLayoutEffect(() => {
    callbackRef.current = callback
  })

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

Sweet, so now people don't need to worry about memoizing their callback:

```javascript
const myFn = () => {
  // do debounced stuff
}
const debouncedMyFn = useDebounce(myFn, 500)
```

For this kind of use case, we should be safe from the aforementioned bug _and_ we have a nice API to boot. I'm satisfied.

If you're curious of real-world scenarios where people have done this to simulate the old default, we actually build something like this in [EpicReact.Dev's Advanced React Hooks Workshop](https://epicreact.dev/modules/advanced-react-hooks/usecallback-custom-hooks-intro) with a custom `useAsync` hook. Dan Abramov's [`useInterval` blog post](https://overreacted.io/making-setinterval-declarative-with-react-hooks/) does this as well. And [`react-query`](https://react-query.tanstack.com/) does this for your `queryFn`s.

## Conclusion

React made the decision to flip the default from things changing out from under you to relying on closures to preserve the value of variables at the time a function is defined. This helps us avoid non-obvious bugs and instead forces us to confront issues before we ship to production. It can definitely be a little confusing until you have a solid grasp on how closures work. Despite that, this is a good change, and our apps are more bug-free thanks to it. 🚫🐛🚫

The sneaky, surreptitious bug that React saved us from by using closures.

How React Uses Closures to Avoid Bugs

Before we get started, here's a brief look of valid (today) ways to import React and use the `useState` hook:

```javascript
// global
window.React.useState()

// CommonJS
const React = require('react')
React.useState()

// ESModules default import
import React from 'react'
React.useState()

// ESModules named import
import {useState} from 'react'
useState()

// ESModules namespace import
import * as React from 'react'
React.useState()
```

Below I'll explain where each of these mechanisms came from and why I prefer the last one.

## Before the dawn of time

I started writing React code back in the `React.createClass` days. Here's how we did things back then:

```javascript
var React = require('react')

var Counter = React.createClass({
  propTypes: {
    initialCount: React.PropTypes.number.isRequired,
    step: React.PropTypes.number,
  },
  getDefaultProps: function () {
    return {step: 1}
  },
  getInitialState: function () {
    var initialCount = this.props.hasOwnProperty('initialCount')
      ? this.props.initialCount
      : 0
    return {count: initialCount}
  },

  changeCount: function (change) {
    this.setState(function (previousState) {
      return {count: previousState.count + change}
    })
  }

  increment: function () {
    this.changeCount(this.props.step)
  },

  decrement: function () {
    this.changeCount(-this.props.step)
  },

  render: function () {
    return (
      <div>
        <div>Current Count: {this.state.count}</div>
        <button onClick={this.decrement}>-</button>
        <button onClick={this.increment}>+</button>
      </div>
    )
  },
})
```

Yup, `var`, `React.createClass`, `require`, `function`. Good times.

## Classes and Modules

Eventually, we got ES6 (and later) which included modules, classes, and some other syntax niceties:

```javascript
import React from 'react'

class Counter extends React.Component {
  state = {count: this.props.initialCount ?? 0}
  changeCount() {
    this.setState(({count}) => ({count + change}))
  }
  increment = () => this.changeCount(this.props.step)
  decrement = () => this.changeCount(-this.props.step)
  render() {
    return (
      <div>
        <div>Current Count: {this.state.count}</div>
        <button onClick={this.decrement}>-</button>
        <button onClick={this.increment}>+</button>
      </div>
    )
  }
}
```

This is when the "how should I import React" question started popping up. A lot of people preferred doing this:

```javascript {1, 3}
import React, {Component} from 'react'

class Counter extends Component {
  state = {count: this.props.initialCount ?? 0}
  changeCount() {
    this.setState(({count}) => ({count + change}))
  }
  increment = () => this.changeCount(this.props.step)
  decrement = () => this.changeCount(-this.props.step)
  render() {
    return (
      <div>
        <div>Current Count: {this.state.count}</div>
        <button onClick={this.decrement}>-</button>
        <button onClick={this.increment}>+</button>
      </div>
    )
  }
}
```

Normally this sort of thing isn't even a question. You just do what the library exposes. But React never actually exposed ESModules. It exposes itself as either a global variable called `React` or a CommonJS module which is the `React` object which has `Component` on it (along with other things). But because of the way the code is compiled, both approaches technically work and neither is technically "wrong."

One other note... Looking at the code above you might wonder why we can't change that to:

```diff
- import React, {Component} from 'react'
+ import {Component} from 'react'
```

The reason you need `React` in there is because (at the time) JSX was compiled to use React:

```diff
- <button onClick={this.increment}>+</button>
+ React.createElement('button', {onClick: this.increment}, '+')
```

So if you use JSX, you need to have `React` imported as well.

It wasn't long after this that function components became a thing. Even though at the time these couldn't actually be used to manage state or side-effects, they became very popular. I (and many others) got very accustomed to refactoring from class to function and back again (many people just decided it was easier to use class components all the time).

For me, I preferred using function components as much as possible and this is likely the reason that I preferred using `import React from 'react'` and `React.Component` rather than `import React, {Component} from 'react'`. I didn't like having to update my import statement any time I refactored from class components to function components and vice-versa. Oh, and I know that IDEs/editors like VSCode and WebStorm have automatic import features, but I never found those to work very well (I ran into stuff like [this](https://github.com/testing-library/react-testing-library/issues/642#issuecomment-718926429) all the time).

Oh, and one other interesting fact. If you were using TypeScript instead of Babel, then you'd actually be required to do `import * as React from 'react'` unless you enabled [`allowSyntheticDefaultImports`](https://www.typescriptlang.org/tsconfig#allowSyntheticDefaultImports).

## The Age of Hooks

Then hooks took the scene and the way I wrote components evolved again:

```javascript
import React from 'react'

function Counter({initialCount = 0, step}) {
  const [count, setCount] = React.useState(initialCount)
  const decrement = () => setCount((c) => c - step)
  const increment = () => setCount((c) => c + step)
  return (
    <div>
      <div>Current Count: {count}</div>
      <button onClick={decrement}>-</button>
      <button onClick={increment}>+</button>
    </div>
  )
}
```

This brought up another question on how to import React. We had two ways to use hooks:

```javascript
import React from 'react'
// ...
const [count, setCount] = React.useState(initialCount)

// alternatively:
import React, {useState} from 'react'
// ...
const [count, setCount] = useState(initialCount)
```

So again, should we do named imports, or just reference things directly on `React`? Again, for me, I prefer to not have to update my imports every time I add/remove hooks from my files (and again, I don't trust IDE auto-import), so I prefer `React.useState` over `useState`.

## The new JSX transform and the future of React + ESM

Finally, React 17 was released with basically no real breaking changes but [an announcement](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html) of great import (pun intended): There's a new JSX transform that means you no longer need to import React to transform JSX. So now you can write:

```javascript
function App() {
  return <h1>Hello World</h1>
}
```

And this will get compiled to:

```javascript
// Inserted by a compiler (don't import it yourself!)
import {jsx as _jsx} from 'react/jsx-runtime'

function App() {
  return _jsx('h1', {children: 'Hello world'})
}
```

So the import happens automatically now! That's great, but that also means that if you want to migrate to use this new capability, you'll need to remove any `import React from 'react'` that's just for JSX. Luckily the React team made a script to do this automatically, but they had to make a decision on how to handle situations where you're using hooks. You have two options:

```javascript
import * as React from 'react'
const [count, setCount] = React.useState(initialCount)

// or
import {useState} from 'react'
const [count, setCount] = useState(initialCount)
```

Both of these work today, are technically correct, and will continue to work into the future when React finally exposes an official ESModules build.

The React team decided to go with the named imports approach. I disagree with this decision for reasons mentioned above (having to update my import all the time). So for me, I'm now using the `import * as React from 'react'` which is a mouthful for my hands to type, so I have a snippet:

```javascript
// snippets/javascript.json
{
  "import React": {
    "prefix": "ir",
    "body": ["import * as React from 'react'\n"]
  },
}
```

For me, I'm sticking with `import * as React from 'react'` so I don't have to worry about my imports. And that's my overly long blog post answer for a very common question I get. Hope it was helpful!

How and why I import react using a namespace

Importing React Through the Ages

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

Memoization has to do with caching. Here's a super simple implementation of memoization:

```javascript
const cache = {}
function addTwo(input) {
  if (!cache.hasOwnProperty(input)) {
    cache[input] = input + 2
  }
  return cache[input]
}
```

The basic idea is: hang on to the input and their associated output and return that output again if called with the same input.

The point is to avoid re-calculating a value for which you already have the result cached. In our case, we're avoiding "input + 2" 🙃

```javascript
addTwo(3) // 5
addTwo(3) // 5, but this time we got it from the cache 🤓
// (we didn't have to recalculate it)
// 🤓 I'll show up when we've memoized something
```

Maybe not entirely worthwhile for _this_ calculation, but it could/would be for an expensive one.

Another interesting aspect to memoization is the fact that the cached value you get back is _the same one_ you got last time. So:

```javascript
// let's imagine we have a function that returns an array of matching
// "post" objects:

// assuming getPostsNoMemo is not memoized
const posts1 = getPostsNoMemo('search term')
const posts2 = getPostsNoMemo('search term')
posts1 === posts2 // false (unique arrays)

// but if we memoize
// assuming getPostsMemo is memoized
const posts1 = getPostsMemo('search term')
const posts2 = getPostsMemo('search term')
posts1 === posts2 // true (identical array) 🤓
```

This has interesting implications for React we'll talk about in a second...

From there you need to talk about cache invalidation. If it's a pure function you're memoizing, then you could keep the cache around forever... except you might run into "out of memory" issues depending on how large the cache gets. Cache invalidation is tricky and I'm not going to get into that today.

## React's memoization

React has three APIs for memoization: `memo`, `useMemo`, and `useCallback`. The caching strategy React has adopted has a size of 1. That is, they _only_ keep around the most recent value of the input and result. There are various reasons for this decision, but it satisfies the primary use case for memoizing in a React context.

So for React's memoization it's more like this:

```javascript
let prevInput, prevResult
function addTwo(input) {
  if (input !== prevInput) {
    prevResult = input + 2
  }
  prevInput = input
  return prevResult
}
```

With that:

```javascript
addTwo(3) // 5 is computed
addTwo(3) // 5 is returned from the cache 🤓
addTwo(2) // 4 is computed
addTwo(3) // 5 is computed
```

To be clear, in React's case it's not a `!==` comparing the prevInput. It checks equality of each prop and each dependency individually. Let's check each one:

```javascript
// React.memo's `prevInput` is props and `prevResult` is react elements (JSX)
const MemoComp = React.memo(Comp)

// then, when you render it:
<MemoComp prop1="a" prop2="b" /> // renders new elements

// rerender it with the same props:
<MemoComp prop1="a" prop2="b" /> // renders previous elements 🤓

// rerender it again but with different props:
<MemoComp prop1="a" prop2="c" /> // renders new elements

// rerender it again with the same props as at first:
<MemoComp prop1="a" prop2="b" /> // renders new elements
```

```javascript
// React.useMemo's `prevInput` is the dependency array
// and `prevResult` is whatever your function returns
const posts = React.useMemo(() => getPosts(searchTerm), [searchTerm])
// initial render with searchTerm = 'puppies':
// - getPosts is called
// - posts is a new array of posts

// rerender with searchTerm = 'puppies':
// - getPosts is *not* called
// - posts is the same as last time 🤓

// rerender with searchTerm = 'cats':
// - getPosts is called
// - posts is a new array of posts

// rerender render with searchTerm = 'puppies' (again):
// - getPosts is called
// - posts is a new array of posts
```

```javascript
// React.useCallback's `prevInput` is the dependency array
// and `prevResult` is the function
const launch = React.useCallback(
  () => launchCandy({type, distance}),
  [type, distance],
)
// initial render with type = 'twix' and distance = '15m':
// - launch is equal to the callback passed to useCallback this render

// rerender with type = 'twix' and distance = '15m':
// - launch is equal to the callback passed to useCallback last render 🤓

// rerender with same type = 'twix' and distance '20m':
// - launch is equal to the callback passed to useCallback this render

// rerender with type = 'twix' and distance = '15m':
// - launch is equal to the callback passed to useCallback this render
```

## The value of memoization in React

There are two reasons you might want to memoize something:

1. Improve performance by avoiding expensive computations (like re-rendering    expensive components or calling expensive functions) 2. Value stability

I think we've covered the first point, but I want to make something clear about the value stability benefit. In a React context, this value stability is critical for memoization of other values as well as side-effects. Let's look at a simple example:

```javascript
function App() {
  const [body, setBody] = React.useState()
  const [status, setStatus] = React.useState('idle')
  const fetchConfig = {
    method: 'POST',
    body,
    headers: {'content-type': 'application/json'},
  }

  const makeFetchRequest = () => (body ? fetch('/post', fetchConfig) : null)

  React.useEffect(() => {
    const promise = makeFetchRequest()

    // if no promise was returned, then we didn't make a request
    // so we'll exit early
    if (!promise) return

    setStatus('pending')
    promise.then(
      () => setStatus('fulfilled'),
      () => setStatus('rejected'),
    )
  }, [makeFetchRequest])

  function handleSubmit(event) {
    event.preventDefault()
    // get form input values
    setBody(formInputValues)
  }

  return (
    <form onSubmit={handleSubmit}>
      {/* form inputs and other neat stuff... */}
    </form>
  )
}
```

> Please note: this might not be the way you'd write form submission code, it's > not how I'd do it either... Really, I'd just use react-query personally, but > bear with me for the purpose of the example...

Take a guess at what's going to happen. If you guessed "runaway side-effect loop" you're right! The reason is because `React.useEffect` will trigger a call to the given effect callback whenever individual elements of the dependency array changes. Our only dependency is `makeFetchRequest` and `makeFetchRequest` is created within the component and that means it's new every render.

So this is where the value stability of memoization plays an important role in React. So let's memoize `makeFetchRequest` with `useCallback`:

```javascript
const makeFetchRequest = React.useCallback(
  () => (body ? fetch('/post', fetchConfig) : null),
  [body, fetchConfig],
)
```

`useCallback` will only return a new function when the dependencies change. And because of that, `makeFetchRequest` has a stable value between renders. Unfortunately, `fetchConfig` is _also_ created within the component and that means it's new every render as well. So let's memoize that for value stability:

```javascript
const fetchConfig = React.useMemo(() => {
  return {
    method: 'POST',
    body,
    headers: {'content-type': 'application/json'},
  }
}, [body])
```

Great! So now the `fetchConfig` and `makeFetchRequest` will both be stable and will only change when the `body` changes which is what we want. Here's the final version of this code:

```javascript
function App() {
  const [body, setBody] = React.useState()
  const [status, setStatus] = React.useState('idle')
  const fetchConfig = React.useMemo(() => {
    return {
      method: 'POST',
      body,
      headers: {'content-type': 'application/json'},
    }
  }, [body])

  const makeFetchRequest = React.useCallback(
    () => (body ? fetch('/post', fetchConfig) : null),
    [body, fetchConfig],
  )

  React.useEffect(() => {
    const promise = makeFetchRequest()
    // if no promise was returned, then we didn't make a request
    // so we'll exit early
    if (!promise) return

    setStatus('pending')
    promise.then(
      () => setStatus('fulfilled'),
      () => setStatus('rejected'),
    )
  }, [makeFetchRequest])

  function handleSubmit(event) {
    event.preventDefault()
    // get form input values
    setBody(formInputValues)
  }

  return (
    <form onSubmit={handleSubmit}>
      {/* form inputs and other neat stuff... */}
    </form>
  )
}
```

The value stability provided by `useCallback` for `makeFetchRequest` helps us make sure that we can control when our side-effect runs. And the value stability provided by `useMemo` for `fetchConfig` helps us preserve memoization characteristics for `makeFetchRequest` so that can work.

I don't find myself having to do this stuff a whole lot, but when I need to it's nice to know how. Like I said, I'd just use react-query for this kind of thing, but if I didn't want to, this is how I would actually write this (short of abstracting it away myself):

```javascript
function App() {
  const [body, setBody] = React.useState()
  const [status, setStatus] = React.useState('idle')

  React.useEffect(() => {
    // no need to do anything if we don't have a body to send
    // so we'll exit early
    if (!body) return

    setStatus('pending')
    const fetchConfig = {
      method: 'POST',
      body,
      headers: {'content-type': 'application/json'},
    }
    fetch('/post', fetchConfig).then(
      () => setStatus('fulfilled'),
      () => setStatus('rejected'),
    )
  }, [body])

  function handleSubmit(event) {
    event.preventDefault()
    // get form input values
    setBody(formInputValues)
  }

  return (
    <form onSubmit={handleSubmit}>
      {/* form inputs and other neat stuff... */}
    </form>
  )
}
```

And now I don't need to worry about memoizing anything anyway! Like I said, I don't need to memoize things super often, but when I do, it's nice to know why it's needed and what I'm really doing. Hopefully I helped you understand that too. Good luck!

A basic introduction memoization and how React memoization features work.

Memoization and React

At the end of a long day when the lights are out and I lie down in bed ready to fall into a blissful sleep, sometimes my wife will remind me that I forgot to lock the back door. When this happens, for some reason I often decide (irrationally) to take a chance in the darkness rather than turn on my phone's flashlight. Maybe it's because I like living on the edge. Maybe I'm not thinking. Whatever the reason, doing this is... dangerous.

It's dangerous because I have four children and a dog who's as black as night. If I'm lucky, I'll return to the sanctuary of my bed unscathed with nothing more than an increased heart rate (what a rush!). But often I'll also have stepped on some toys, kicked a door frame, bumped into the banister, and on really unfortunate nights, stepped on my snoozing dog (sorry Gemma!).

Learning can be a lot like stumbling around in the darkness. Except not only is there no illumination to guide you, you're also in someone else's house and their kids are less clean than yours and their dogs are darker and less forgiving than yours. Sound terrifying? If you've ever learned something new, you know it is.

The big problem is you don't know what you don't know. This means you don't know what to look for. You try something and it "works" but you don't know why it works or whether there's a better or easier (less painful) way to do it. You're trying to lock the back door and you walk around the couch 8 times because you're not sure whether there's a more direct route to get there. If you're lucky, you've got other co-workers alongside you.

If you're really lucky they've done this before and can guide you along. But more often they're either too busy or they're just as inexperienced as you are and all they can do is hold your hand and tell you "it's going to be ok." While this is appreciated, it's not directly helpful.

When you're learning something new, you're stumbling in the sea of things you don't know you don't know. Perhaps you've cobbled together API docs from here, a tutorial from there, an online course from way over there, and a tweet or two from back there. You attempt to piece those things together in your mind to try to give you something that resembles knowledge and experience, but often you'll find you've tried to shove a round peg in a square hole. There's no cohesion. And in your rush to create a candle to light your way, you've forgotten the wick.

The other day I tweeted this:

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

I had several people make the suggestion that "learning isn't suffering." I actually agree with this. "Suffering" is the wrong word for what learning **should be**. Learning **is** a struggle, but it **should be** guided struggle where you are presented with problems, but also the right tools and information you need to identify and implement the solution.

Far too many online courses posing as "learning resources" completely take away that struggle. They sit you in a high chair and attempt to spoon feed you knowledge. Unfortunately, leaving out the struggle is basically like forgetting to put food on the spoon 🥄. All the movements are there, but none of the sustenance. They show you the happy path of what you're trying to do and leave you to fend for yourself on error messages (or worse, silent errors) only to later realize that the solution they've given you won't work for the problem you're facing.

There's different kind of struggles though. There's the struggle of working through a problem with a solution that you've been guided into by experience. This first kind of struggle is what creates retention so you can use that as a gained skill later. And then there's the struggle of hitting a wall on some unrelated problem that's simply a road block to what you're really trying to learn.

Maybe you haven't experienced the first, but you've probably experienced the second. That wall-hitting struggle is so often (and unfortunately) unavoidable. Eventually you'll bust down that wall and you'll leave victorious with knowledge of how to bust down that wall in the future, but the victory is hollow because you'll never hit that wall again anyway. It's a side-quest with all the challenge, but none of the reward. Maybe it's fun in the moment, but when you're done your product is not shipped and your manager is not sure you deserve the raise you asked for.

Another struggle involves the struggle of "holding it wrong" or "using the wrong tool for the job." This often comes from learning about the tools that are available, but not learning how the tools work, how they should be used, what problems they're intended to solve, and (just as important) what problems they're _not_ intended to solve. For example, maybe you heard once that using `React.useCallback`, `React.useMemo`, and `React.memo` will improve performance, so you start applying those tools everywhere. And now you're struggling because your code is more complex than it needs to be and in the back of your mind you're worried about that one time the component didn't re-render when it should have.

Learning _can be_ suffering if you're doing the wrong kind of struggling. Stumbling around in the learning darkness is not fun or productive. It's frustrating and far too many people give up completely when that's their experience when struggling to learn.

But there's a way to avoid suffering when learning: **Have a complete and cohesive guide that provides the right kind of struggle and a support system to help you avoid the wrong kind.**

This is [EpicReact.Dev](https://epicreact.dev)

It's not a candle. It's a freaking spotlight.

EpicReact is not just a "happy path" video course that will leave you with all the pieces, no instructions, and no support telephone number. EpicReact is a series of workshops that shows you the tools you can use, how to use them, and gives you experience with the right kind of struggle. The kind that helps you side-step distracting and wasteful side-quests and promotes the reward bearing ones. The kind of struggle that requires work on your part, but work that gives you actual learning retention. It's the kind of struggle that gives you a support system for those times when you're really stuck and things aren't quite clicking for you.

Stop stumbling around in React learning darkness. I've got a spotlight for you so you don't step on any legos or poor innocent dogs. I'm excited to give you the _right_ kind of learning struggle on [EpicReact.Dev](https://epicreact.dev).

Epic React is your learning spotlight so you can ship harder, better, faster, stronger.

Stop Stumbling Around in React Learning Darkness

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

For example, here's my GitHub home page:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## But... Why?

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

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

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

## Conclusion

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

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

Simplify and speed up your app development using React composition

One React mistake that's slowing you down

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

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

When was the last time you saw an error and had _no idea_ what it meant (and therefore no idea what to do about it)? Today? Yeah, you're not alone... Let's talk about how to fix that.

## A story

A while ago, I got a new faucet. It's one of those cool ones where the head of the faucet could come off so we could direct the water's flow and would automatically retract back into the neck when you're done. Unfortunately, it wasn't long before we had a problem:

![Faucet with the head not retracting into the neck](/articles-images/requisite-react/broken-faucet.png)

The head of the faucet wouldn't automatically go back into the neck! And we couldn't even push it back in. It just hung there. Like a sad flower 🥀

So we called the plumber who had installed it for us to have them come look at it and see if they could fix it or give us a replacement. A few days later was the day of our appointment. A few hours before he arrived, I looked frustratingly at the faucet and wondered... So I looked under the sink, and this is what I saw:

![Under a sink a faucet hose is tangled in itself](/articles-images/requisite-react/tangled-hose.png)

That's the hose for our faucet. It turns out there's a simple weight that goes on the hose and that weight is what pulls the head of the faucet into the neck. Because it was tangled in itself, the weight wasn't pulling the hose down. So I reached in and untangled the hose:

![Under a sink a faucet hose is untangled](/articles-images/requisite-react/untangled-hose.png)

And like a miracle, it suddenly worked! I called the plumber to cancel as quickly as I could to avoid revealing my shame. Can you imagine if I hadn't discovered the problem and they came over, untangled the hose, and gave me an invoice for their trouble. I don't know if I could have taken that hit to my ego. The embarrassment would have been too much 🙈

So what does a faucet problem have to do with React? A faucet is an abstraction. We don't have to have faucets. We could just pull the hose straight out of the wall and use that instead, but we put the faucet in place because it makes the water more useful. Normally it works fine, but when there's a problem, if you don't understand how the abstraction works, it's difficult to figure out what went wrong and how to resolve the problem.

## A universal truth

React is an abstraction too. And here's a universal truth about abstractions:

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

Abstractions are all around us. Your phone is an abstraction. Your car is an abstraction. And the better we understand how those things work, the better we are able to use them. And that's not to say that you _can't_ use the abstraction if you don't know how they work. I drive my car all the time and I have no idea how it works. But whenever something goes wrong with it, I'm at a total loss (and that's just the way my mechanic likes it 🤑).

You can use React without a good foundation in the fundamentals and that's totally fine. You can ship really amazing things without a solid foundation. But if you'd like to level-up on your capabilities and productivity with React, then digging in and gaining an understanding in how they work is the way to do it.

## A simple example

There's a fun site [YouMightNotNeedjQuery.com](http://youmightnotneedjquery.com/) which shows common jQuery functions and the code needed for that same functionality based on the browser support you have (up to IE10).

So let's imagine that you needed [jQuery's `toggleClass` functionality](https://api.jquery.com/toggleclass/) so you copy/pasted the code from YouMightNotNeedjQuery.com and built this function so you don't have to bring all of jQuery into your app:

```javascript
function toggleClass(el, className) {
  if (el.classList) {
    el.classList.toggle(className)
  } else {
    var classes = el.className.split(' ')
    var existingIndex = -1
    for (var i = classes.length; i--; ) {
      if (classes[i] === className) existingIndex = i
    }

    if (existingIndex >= 0) classes.splice(existingIndex, 1)
    else classes.push(className)

    el.className = classes.join(' ')
  }
}
```

What you've created is your own little abstraction. But actually, you're also _using_ an abstraction: the DOM. And if you knew a little bit more about that abstraction, you'd know that browsers (including IE10) have support for this built-in. So that function could be simplified... a lot:

```javascript
function toggleClass(el, className) {
  el.classList.toggle(className)
}
```

So by understanding the abstraction we're using (the DOM in this case), we're able to drastically simplify our code which ultimately [impacts our users](https://kentcdodds.com/blog/why-users-care-about-how-you-write-code).

## A problem with learning abstractions

These days not many people build an application without using a soup of tools and libraries to do so. Unfortunately, if you skip over the fundamentals of each tool, it's easy for your understanding of each to become muddled. Is React managing my state or React Query? Is Babel compiling my JSX or React? Do I need PropTypes if I'm using TypeScript? Isn't redux required if you're building a React app? (That last one is a definite no).

One of the biggest causes for people's struggle at understanding abstractions is they struggle to draw lines around the abstractions. When you're not sure which abstraction should do which job, it's very easy to use the wrong tool for the job. Sure you can get it working eventually, but you may be left with a solution that causes you and ultimately your users some real pain.

So a great first step to understanding your abstractions better is to learn them in isolation from one another and only add them to your learning when you run into the problem they actually solve.

Too many people start learning and using React with Webpack, Babel, React Router, Redux, Jest, React Testing Library, Material UI, etc. etc. This makes it really difficult to draw lines around these abstractions and really understand the purpose of each.

## A different approach

This is why [EpicReact.Dev](https://epicreact.dev) introduces one concept at a time. And we don't skip anything. As you just get started, we literally write JavaScript in a script tag of an HTML file. We don't even write React first. We start with regular DOM nodes. Then we add `React.createElement`. Then we add JSX. And we methodically add more and more concepts over time so you get a good idea of what tools are responsible for what so you can use each as effectively as possible.

This is why people who have been using React for _years_ tell me that they _still_ learn new things from my beginner material. Because we so often skip over that methodical approach when we're in a rush to ship something.

## Time to level-up

If you're tired of seeing errors pop up in your console and not understanding what to do about them, then gaining a deeper understanding of the fundamentals of how things work is the best thing you can do to get over that. If you're tired of fumbling around with wiring things together and praying that nobody blows your house of cards over, then taking a bit to sharpen your understanding of your primary abstractions (like React) will go a long way.

And this is exactly why I created [EpicReact.Dev](https://epicreact.dev): To help you level-up your professional React knowledge and productivity.

When was the last time you saw an error and had no idea what it meant (and therefore no idea what to do about it)? Today? Yeah, you're not alone... Let's talk about how to fix that.

Requisite React

React components afford us the opportunity to encapsulate state, logic, and markup in a single place. A component is like a magical machine where you pass in props and a beautiful component pops out the other end.

Unfortunately, truly maintainable, flexible, simple, and reusable components require more thought than: "I need it to do this differently, so I'll accept a new prop for that." Seasoned React developers know this leads to nothing but pain and frustration for both the maintainer and user of the component. Ever hear of [the apropcalypse](https://twitter.com/gurlcode/status/1002110517094371328)? It's not fun.

The only thing you can really expect about the future is the unexpected. Nobody can know the future for certain, so you need some tools in your toolbelt that help you avoid committing yourself to a path that may not satisfy the needs of the future. With React components, these tools are patterns that have been battle tested in real applications and libraries and if you're not using them in your components today, you're likely dealing with APIs that result in more workarounds than lines of maintainable code.

And that's slowing you down.

## For example

One of my favorite tools for creating great component abstractions is the idea of "compound components." The idea of compound components has been around forever (think `<select>` and `<option>`), and it's been implemented in some of my favorite libraries (check [Reach UI](https://reach.tech/)). Utilizing compound components, you can go from an inflexible API like this:

```jsx
<Modal
  modalTitle="Register"
  modalLabelText="Registration form"
  openButtonText="Register"
  dismissable={true}
  contents={
    <LoginForm
      onSubmit={register}
      submitButton={<Button variant="secondary">Register</Button>}
    />
  }
/>
```

To something with ultimate flexibility like this:

```jsx
<Modal>
  <ModalOpenButton>
    <Button variant="secondary">Register</Button>
  </ModalOpenButton>
  <ModalContents aria-label="Registration form">
    <ModalDismissButton>
      <CircleButton>
        <VisuallyHidden>Close</VisuallyHidden>
        <span aria-hidden>×</span>
      </CircleButton>
    </ModalDismissButton>
    <ModalTitle>Register</ModalTitle>
    <LoginForm
      onSubmit={register}
      submitButton={<Button variant="secondary">Register</Button>}
    />
  </ModalContents>
</Modal>
```

(Note, the compound components are all the ones that start with `Modal`).

I can tell some of you are looking at this thinking: "Huh... well I actually like the first one better." But remember, we can't anticipate all the needs of our component's API in the future, so we want to focus on which will be most adaptable.

Consider the difficulty in the following possible future use cases:

- We want to add a "cancel" button (but still need to support the dismiss   button) - We want to style the modal title, open button, or dismiss button (you want to   add a `openButtonProps` prop? lol, I wish I could say I've never tried that   before 🤦‍♂️)

Oh, and the neat thing about this is that if you really _do_ like the first one better, there's nothing stopping you from creating a component that uses the compound components API to expose the same API as the first. But try doing that in the reverse 😉

Taking things further, if it's really common enough, you could create a special `ModalContents` component that handles rendering the dismiss button and title, so in the end it looks like:

```jsx
<Modal>
  <ModalOpenButton>
    <Button variant="secondary">Register</Button>
  </ModalOpenButton>
  <ModalContents aria-label="Registration form" title="Register">
    <LoginForm
      onSubmit={register}
      submitButton={<Button variant="secondary">Register</Button>}
    />
  </ModalContents>
</Modal>
```

But you don't have to sacrifice the benefits of the previous API thanks to composition. Sure you could do something similar with our previous API, but have you ever tried to maintain a component with a hodgepodge of props like that? I mean, I love that React components can be black boxes just as much as the next developer, but I'd prefer to not experience soul-crushing maintainability nightmares any time I need to venture into that black box...

## Conclusion

The beauty of patterns like compound components, state reducers, prop getters, controlled props, etc. is that you can have your simple API _and_ a simple implementation at the same time. If you aren't doing this yet, **now's a great time to start.**

And I'm excited to teach you how on [EpicReact.Dev](https://epicreact.dev).

Truly maintainable, flexible, simple, and reusable components require more thought than: "I need it to do this differently, so I'll accept a new prop for that". Seasoned React developers know this leads to nothing but pain and frustration for both the maintainer and user of the component.

Avoid soul-crushing components

I've taught React to tens of thousands of developers. Before and after hooks were released. One thing I've observed is people tend to struggle with the `useEffect` hook and there are some common hang-ups for them that I'd like to address here.

## ❌ Lifecycles ❌ ✅ Synchronize Side Effects ✅

The biggest struggle I've observed is developers who have experience with React class components and lifecycle hooks like `constructor`, `componentDidMount`, `componentDidUpdate`, and `componentWillUnmount`. You can definitely map these to function components with hooks, but that's a big mistake. Allow me to illustrate. Here's an example of some fun UI:

![User clicks "Bernedoodle" link and information about a Bernedoodle shows up, then the user clicks "Poodle" and poodle info shows up. Then back to "Bernedoodle", then "Bernese Mountain Dog", then "return to list"](/articles-images/myths-about-useeffect/dogs.gif)

Here's a class component implementation of that `DogInfo` component:

```javascript
class DogInfo extends React.Component {
  controller = null
  state = {dog: null}
  // we'll ignore error/loading states for brevity
  fetchDog() {
    this.controller?.abort()

    this.controller = new AbortController()
    getDog(this.props.dogId, {signal: this.controller.signal}).then(
      (dog) => {
        this.setState({dog})
      },
      (error) => {
        // handle the error
      },
    )
  }
  componentDidMount() {
    this.fetchDog()
  }
  componentDidUpdate(prevProps) {
    // handle the dogId change
    if (prevProps.dogId !== this.props.dogId) {
      this.fetchDog()
    }
  }
  componentWillUnmount() {
    // cancel the request on unmount
    this.controller?.abort()
  }
  render() {
    return <div>{/* render dog's info */}</div>
  }
}
```

That's a pretty standard class component for this type of interaction. It's using the `constructor`, `componentDidMount`, `componentDidUpdate`, and `componentWillUnmount` lifecycle hooks. If we naively mapped those lifecycles to hooks, here's how it might look:

```javascript
function DogInfo({dogId}) {
  const controllerRef = React.useRef(null)
  const [dog, setDog] = React.useState(null)
  function fetchDog() {
    controllerRef.current?.abort()

    controllerRef.current = new AbortController()
    getDog(dogId, {signal: controllerRef.current.signal}).then(
      (d) => setDog(d),
      (error) => {
        // handle the error
      },
    )
  }

  // didMount
  React.useEffect(() => {
    fetchDog()
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, [])

  // didUpdate
  const previousDogId = usePrevious(dogId)
  useUpdate(() => {
    if (previousDogId !== dogId) {
      fetchDog()
    }
  })

  // willUnmount
  React.useEffect(() => {
    return () => {
      controllerRef.current?.abort()
    }
  }, [])

  return <div>{/* render dog's info */}</div>
}

function usePrevious(value) {
  const ref = useRef()
  useEffect(() => {
    ref.current = value
  }, [value])
  return ref.current
}
```

There are still some holdouts on hooks. If this is what I thought hooks meant, then I would be a hooks holdout too.

Here's the crux of the issue: **`useEffect` is _not_ a lifecycle hook. It's a mechanism for synchronizing side effects with the state of your app.**

So, in our example, all we care about is: "When the `dogId` changes, fetch the new dog's information." With that as our goal, `useEffect` becomes _much_ simpler for this case:

```javascript
function DogInfo({dogId}) {
  const [dog, setDog] = React.useState(null)

  React.useEffect(() => {
    const controller = new AbortController()
    getDog(dogId, {signal: controller.signal}).then(
      (d) => setDog(d),
      (error) => {
        // handle the error
      },
    )
    return () => controller.abort()
  }, [dogId])

  return <div>{/* render dog's info */}</div>
}
```

🤯 Oh snap. That's _way_ better right?! When the React team introduced hooks, their goal wasn't to simply add lifecycles to function components. Their goal was to fundamentally improve the mental model for application side-effects. And they did.

Big time.

So remember this gem by [Ryan Florence](https://twitter.com/ryanflorence/status/1125041041063665666):

> The question is not "when does this effect run" the question is "with which > state does this effect synchronize with" > > useEffect(fn) // all state > > useEffect(fn, []) // no state > > useEffect(fn, [these, states])

## I can ignore eslint-plugin-react-hooks/exhaustive-deps ❌

Well, technically you can. And _sometimes_ there's a good reason to. But most of the time it's a bad idea and ignoring that rule will lead to bugs. I see this concern come up often when people say: "But I only want this to run on mount!" Again. That's thinking in lifecycles and is wrong. If your `useEffect` callback has dependencies, then you need to make sure that your effect callback is re-run anytime those dependencies change. Otherwise your side-effects will fall out of sync with the state of the app.

Long story short, you'll have bugs. Don't ignore this rule.

## One giant useEffect ❌

Honestly, I don't see this one a whole lot, but I want to include it just in case. No shame if this is you. It happens.

One of the things I love about `useEffect` over lifecycles is it allows me to _really_ separate concerns. Here's a quick example:

![A geochat app showing location based chat, autoscroll, and unread count in the document title](/articles-images/myths-about-useeffect/geo-chat.gif)

Here's some pseudocode for that demo:

```javascript
class ChatFeed extends React.Component {
  componentDidMount() {
    this.subscribeToFeed()
    this.setDocumentTitle()
    this.subscribeToOnlineStatus()
    this.subscribeToGeoLocation()
  }
  componentWillUnmount() {
    this.unsubscribeFromFeed()
    this.restoreDocumentTitle()
    this.unsubscribeFromOnlineStatus()
    this.unsubscribeFromGeoLocation()
  }
  componentDidUpdate(prevProps, prevState) {
    // ... compare props and re-subscribe etc.
  }
  render() {
    return <div>{/* chat app UI */}</div>
  }
}
```

See those four concerns? They're all mixed up. If we wanted to share that code with anything else, it would be a mess. I mean, render props were awesome, but hooks are _way_ better.

I've seen some people create a monster `useEffect` hook that does all the things:

```javascript
function ChatFeed() {
  React.useEffect(() => {
    // subscribe to feed
    // set document title
    // subscribe to online status
    // subscribe to geo location
    return () => {
      // unsubscribe from feed
      // restore document title
      // unsubscribe from online status
      // unsubscribe from geo location
    }
  })

  return <div>{/* chat app UI */}</div>
}
```

But this makes that individual callback pretty complicated. I'd suggest a different approach. Don't forget that you can separate logical concerns into individual hooks:

```javascript
function ChatFeed() {
  React.useEffect(() => {
    // subscribe to feed
    return () => {
      // unsubscribe from feed
    }
  })

  React.useEffect(() => {
    // set document title
    return () => {
      // restore document title
    }
  })

  React.useEffect(() => {
    // subscribe to online status
    return () => {
      // unsubscribe from online status
    }
  })

  React.useEffect(() => {
    // subscribe to geo location
    return () => {
      // unsubscribe from geo location
    }
  })

  return <div>{/* chat app UI */}</div>
}
```

And with this approach, it's _much_ easier to extract this code into a custom hook for each individual concern if that's what you need or want to do:

```javascript
function ChatFeed() {
  // NOTE: this is pseudo-code,
  // you'd likely need to pass values and assign return values
  useFeedSubscription()
  useDocumentTitle()
  useOnlineStatus()
  useGeoLocation()
  return <div>{/* chat app UI */}</div>
}
```

The self-encapsulation of hooks in general is a huge win. Let's make sure we take advantage of that.

## Needlessly externally defined functions ❌

I've seen this one a few times as well. Let me just give you a before/after:

```javascript
// before. Don't do this!
function DogInfo({dogId}) {
  const [dog, setDog] = React.useState(null)
  const controllerRef = React.useRef(null)

  const fetchDog = React.useCallback((dogId) => {
    controllerRef.current?.abort()
    controllerRef.current = new AbortController()
    return getDog(dogId, {signal: controllerRef.signal}).then(
      (d) => setDog(d),
      (error) => {
        // handle the error
      },
    )
  }, [])

  React.useEffect(() => {
    fetchDog(dogId)
    return () => controller.current?.abort()
  }, [dogId, fetchDog])

  return <div>{/* render dog's info */}</div>
}
```

We already saw how simple the above code can be in our earlier example, but let me show that to you again:

```javascript
function DogInfo({dogId}) {
  const [dog, setDog] = React.useState(null)

  React.useEffect(() => {
    const controller = new AbortController()
    getDog(dogId, {signal: controller.signal}).then(
      (d) => setDog(d),
      (error) => {
        // handle the error
      },
    )
    return () => controller.abort()
  }, [dogId])

  return <div>{/* render dog's info */}</div>
}
```

The specific thing I'm trying to call out here is the idea of defining a function like `fetchDog` outside of the `useEffect` callback. Because it's external, you have to list it in the dependencies array to avoid stale closures. And because of _that_ you also have to memoize it to avoid infinite loops. Oh, and then we had to create a `ref` for our abort controller.

Phew, seems like a lot of work. If you _must_ define a function for your effect to call, then do it _inside_ the effect callback, not outside.

## Conclusion

When Dan Abramov introduced hooks like `useEffect`, he compared React components to atoms and hooks to electrons. They're a pretty low-level primitive, and that's what makes them so powerful. The beauty of this primitive is that nicer abstractions can be built on top of these hooks which is frankly something we struggled with before hooks. Since the release of hooks, we've seen an explosion of innovation and progress of good ideas and libraries built on top of this primitive which ultimately helps us develop better apps.

I love it. And I want to teach you all about these primitives as well as abstractions built on top of them in [EpicReact.Dev](https://epicreact.dev) 🚀 Join me.

Some common mistakes I see people make with useEffect and how to avoid them.

Myths about useEffect

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

I still remember when I first heard about React. It was January 2014. I was listening to a podcast. Pete Hunt and Jordan Walke were on talking about this framework they created at Facebook with no support for two way data-binding, no built-in HTTP library, no dependency injection, and in place of templates it had this weird XML-like syntax for the UI. And to top it all off, I was listening to it while driving to the first ever ng-conf. I was so hyped on Angular.js that I didn't really give React.js more thought than: "Huh."

However, a few months later I started seeing some of my friends and co-workers try it out and share why they thought it was interesting. They encouraged me to give it a solid shake. I put it off for a while.

I was busy.

I felt like my current tools were good enough.

But finally, I gave it 5 minutes and that was all it took. I instantly knew that React was an upgrade on my current tools. Unfortunately I couldn't just switch my work project from Angular.js to React. But I started working on side-projects and open source libraries with React. I was living two lives. Angular.js expert during the day, React padawan at night.

Eventually I decided I wanted to spend my work time working with React and got a job at PayPal working with React full-time where I was super happy.

So what was it that hooked me on React (no pun intended... hooks weren't a thing back then) so strong? Honestly, it was a few things, but if I had to summarize it to one thing it was this:

**React is simple.**

I didn't say "easy" because it's not easy for everyone ("easy" is relative to each individual). But it _is_ simple. It is simpler than my former tools, and that's what hooked me.

For more on the distinction between easy and simple, watch [Simplicity Matters](https://www.youtube.com/watch?v=rI8tNMsozo0) [Rich Hickey](https://twitter.com/richhickey) which is a fantastic talk.

## What makes React simple?

### Explicit state updates

The fact that React shuns mutation as an API for changing state and instead state updates are explicit function calls was a huge improvement for me. I can't tell you how much time I spent wondering what was causing my state to change incorrectly. My software was complected by the "ease" of state updates.

Yes, if you compare "two-way data binding" in Angular.js to what it takes to wire up a controlled input with React, you'll find Angular.js takes less code. And that demos incredibly well. But I've learned that what "demos" well and what is maintainable in a real-world scenario are not always correlated. React's choice to go with "one-way data flow" was a good one. It is simple, sensible, flexible, and powerful. I don't care how much code I have to write. I care about how much work it takes for me or my co-workers to change that code in the future without causing any bugs.

### JSX over templates

Using JSX syntax (aka `React.createElement` syntax sugar) instead of string templates meant that I could leverage (and improve) my knowledge of the JavaScript language features rather than learning and being limited by template syntax and struggling with the global namespace/registry of Angular.js directives. I spent a lot of time trying to figure out what I messed up in my template. It's a DSL (domain-specific language) with an enormous amount of complexity.

On top of that, all the time I invested in learning that syntax is now wasted. It's completely inapplicable to anything else I work on (even if I had decided to move on to Angular 2 instead of React). However, by using JSX and understanding the basic syntax sugar, I'm able to use what I learn in non-React code all the time.

### Hooks

React hooks weren't available when I started using React, but React hooks is definitely another thing that makes React simple:

- `useState` when you need to manage state. - `useEffect` when you need to synchronize something outside of React with your   app's state.

There are certainly some things to _familiarize_ yourself about these hooks, and there are some other hooks to help with other use cases, but these things are conceptually simple (again, not necessarily "easy").

My favorite part of hooks is how relatively easy it is to share code in a way that is also simple. To share a chunk of hooks logic between components you apply the same techniques you would when sharing non-hooks code: make a function and call it where you want to use the logic.

On top of that, it's all functions, so you can compose things together. You can combine these hooks into a single custom hook, and then you can combine other custom hooks into yet another custom hook. It's incredibly powerful and doing it is also still simple. For more on this, watch [Custom Hooks in React: The Ultimate UI Abstraction Layer](https://www.youtube.com/watch?v=J-g9ZJha8FE) by [Tanner Linsley](https://twitter.com/tannerlinsley).

### React for everything

I had great success using React to build applications used by millions of PayPal users all over the world. I love it for that scale. And what's awesome about React is that it's not limited to Facebook-scale problems. I've used it successfully to handle my small side-projects to great success. So another thing I love about React and its simplicity is how well it handles challenges, whatever the scale. I recently had a side-project I needed built fast and I was able to build the whole thing in a single `index.html` file using [this approach](https://kentcdodds.com/blog/super-simple-start-to-react). No tooling necessary.

On top of that, React also supports really any platform with a UI. React Native, React VR, even interactive CLIs with Ink. React's simple component-based model and the power of hooks can reach anywhere. Big or small.

Once you learn React, you can build UIs anywhere.

## Community

Aside from the simplicity of the framework, another thing that I love about React is that by any metric, it's the most popular and widely used tool for building frontend applications in the world.

By a huge margin.

This kind of thing is hard to get real metrics on, but the best metric I can find to determine relative popularity is the number of users of the Developer Tools browser extension. In the Chrome DevTools, there are 2+ million users, which is twice the next most popular framework's DevTools.

However you slice it, React is extremely popular. And this has some extremely nice side-effects. In addition to React being worked on by some of the smartest engineers in the world, the size of the community means that many of the smartest engineers in the world are participating in creating and contributing to the surrounding ecosystem of libraries and tools.

This is not to suggest other frameworks don't have this (they do), but React's dominate size means that the number of people experiencing problems and solving them increases the likelihood that any problem you face has been faced and solved by someone in the community already. And if you're hiring, it's also more likely that someone is looking for a job too.

## Conclusion

Betting on React was a big leap for me. I loved Angular.js and I built some awesome applications, libraries, and tools with it. But I'm so glad that I gave React some of my time because it's paid me back in productivity and velocity that I didn't even realize was possible before. If you'd like that in your life and you haven't jumped onboard with React, then I definitely suggest you give it a try.

And I've been working hard on [something](https://EpicReact.Dev) that will really help you with that 😉

I still remember when I first heard about React. It was January 2014. I was listening to a podcast. Pete Hunt and Jordan Walke were on talking about this framework they created at Facebook that with no support for two way data-binding, no built-in HTTP library, no dependency injection, and in place of templates it had this weird XML-like syntax for the UI. And to top it all off, I was listening to it while driving to the first ever ng-conf.

Epic React Articles