If you've ever used a native `<select>` and `<option>` in HTML, you've already
experienced the power of **compound components**—even if you didn't know the
name.

But what if you could bring that same flexibility and declarative power to your
own React components? That's what the Compound Components pattern is all about.

## What and Why: Compound Components in React

Compound components are a set of components that work together to form a
complete UI, implicitly sharing state and behavior. Think of them as a family:
each member has a role, but they all work together seamlessly.

The classic example is HTML's select:

```html
<select>
	<option value="1">Option 1</option>
	<option value="2">Option 2</option>
</select>
```

The `<select>` manages the state, and the `<option>`s are just configuration.
You don't have to wire them up manually—they just work.

You _could_ build a custom select like this:

```tsx
<CustomSelect
	options={[
		{ value: '1', display: 'Option 1' },
		{ value: '2', display: 'Option 2' },
	]}
/>
```

But what if you want to add custom attributes to an option, or change how it's
displayed when selected? You'd have to keep adding more props and configuration,
making your API more complex and less flexible.

Compound components let you keep your API simple and declarative:

```tsx
<CustomSelect>
	<CustomOption value="1">Option 1</CustomOption>
	<CustomOption value="2">Option 2</CustomOption>
</CustomSelect>
```

Now, you can pass _anything_ as children, and each option can be as flexible as
you need.

The parent component (like `<CustomSelect>`) manages the shared state and passes
it down to its children using React's context API. The children (like
`<CustomOption>`) consume that context and interact with the parent as needed.

This pattern lets you build components that are:

- **Flexible:** Users can compose your components however they want.
- **Declarative:** The structure of the UI matches the structure of the code.
- **Extensible:** Add new features without breaking existing APIs.

## Real-World Impact & When to Use

This isn't just a theoretical pattern. It's used in some of the most popular UI
libraries, like
[Radix UI Tabs](https://www.radix-ui.com/primitives/docs/components/tabs) and
[Radix UI Accordion](https://www.radix-ui.com/primitives/docs/components/accordion).
In fact, most of [Radix UI](https://www.radix-ui.com/primitives) is built on
this pattern.

Reach for compound components when:

- You want to give users maximum flexibility in composing your UI.
- You want to avoid prop explosion and keep your API clean.
- You want your components to "just work" together, like native HTML elements.

Want to master patterns like this—and many more?
[EpicReact.dev](https://epicreact.dev) is packed with hands-on workshops,
real-world examples, and deep dives into the patterns that make React apps
scalable and maintainable. Whether you're a beginner or a seasoned pro, you'll
find something to level up your React skills.


Build flexible, declarative UIs like native HTML with Compound Components—a powerful React pattern you’ll master at EpicReact.dev.

Compound Components: Truly Flexible React APIs

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

## Why You Need Unique IDs

Unique IDs are essential for:

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

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

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

### Using the Web Crypto API

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

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

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

## Example: Adding Items to a List

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

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

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

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

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

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

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

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

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


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

Generating Unique IDs for Client-Only Data in React

Every so often, I hear from learners who've had one of those "wait a minute…" moments where something that seemed obscure in the workshop suddenly becomes the perfect tool for the job. Ben from Cheltenham sent me one of those stories, and with his permission, I'm sharing it here (completely unedited). It’s a perfect example of how subtle lessons from [Epic React](https://www.epicreact.dev) can shape your long-term intuition as a React developer.

---

Hey Kent (&team)!

I wanted to share a quick AHA moment that perfectly captures why your courses are so valuable to me.

**The Setup:** I did (some of) Epic React a while back, and in the fundamentals workshop you covered resetting component state with the key prop. You said: "So there you go, that is using the key prop to reset an element, you can put this on an entire chunk of your UI, however you want to do that, and that can reset that entire chunk of UI, again, not something you do a ton, but absolutely something you do sometimes, so just put this in the back of your mind to think on in the future as a mechanism for resetting the state of, or your UI for a particular area, because it can be useful sometimes. Great job!"

And honestly, my first thought was "lol, when would I ever need this? I've been coding React for 5 years and can't think of a single time I've needed it."

**The Payoff:** Months later, I'm at work dealing with a React Native text input that has stale state when users navigate between animals in our livestock management app.

I could fix it in the event handler, but that would mean updating multiple handlers and adding tons of complexity to what's already a massive feature drowning in tech debt - and we definitely don't need any more complexity, thank you very much! I also considered useEffect, but it felt like the wrong tool for the job.

I brainstormed with Claude, explored different approaches, and then - boom - "Wait, didn't Kent mention something about this in that workshop ages ago?"

One line change: `<AnimalActionForm key={currentAnimal?.id} session={session} />`

Problem solved. Perfectly clean. No complexity added.

**The Real Value:** But here's the deeper insight: In the past, I probably did encounter situations like this - I just solved them poorly because I didn't know better options existed. I would have gone straight to useEffect thinking "this is fine" without even considering alternatives.

Your courses don't just give me more tools - they expand my mental model of what's possible. Now when I see a useEffect synchronising local state like this, something feels off. I think "wait, this does not feel right. There must be a cleaner way." instead of just accepting it as the only solution. And the funny thing is that the solution can be incredibly banal (like in this case).

It's like you're training my developer intuition to recognise code smells I didn't even know were smells before. The techniques are valuable, but the shifted perspective on what constitutes "good" vs "fine" code is even more valuable.

**The Point:** This is exactly why your courses are so good. I have similar experiences so far from going through Epic Web. Even when I don't work in Remix, Epic Web gives me a reference for what good code looks like, what problems well-designed applications should solve, tips and tricks that seem "academic" at the time but turn out to be gold later.

I always forget to write down these moments, but this one was too perfect not to share. Your "useless" key example saved me from some really gnarly production code. Thanks for teaching the stuff that seems unnecessary until it's exactly what you need!

Have a great weekend! 🚀

Kind regards
Ben (from Cheltenham, UK)


---

Thanks again to Ben for taking the time to share this moment. If you’ve had a similar “aha!” from [Epic React](https://www.epicreact.dev), [Epic Web](https://www.epicweb.dev), [Epic AI](https://www.epicai.pro), etc., I’d love to hear from you. Sometimes the most “banal” tricks end up being the most powerful ones in your toolbox.


A developer shares how a tiny tip from Epic React—using the key prop to reset component state—saved him from a gnarly state bug in a complex React Native app.

How a “Useless” Tip Saved Ben's Sanity in Production

In this post, we’re going to dive deep on how you use modern React APIs for building forms. We will not be using third party libraries or frameworks. Understanding these lower level primitives will unlock them for you when using libraries and frameworks.

I recently heard someone say that web applications are just a skin on top of a database. And that’s actually pretty accurate. Since the beginning of the web, modern web applications have had two sides to them:

1. Users view data
2. Users mutate data

Loading data into a web application is a pretty straightforward proposition. It’s only when we start talking about needing to modify that data and keep things in sync that things get more complicated.

From day 1, HTML supported mechanisms for both of these use cases.

## Viewing Data

This allows the user to navigate to another page to view more data:

```html
<a href="/remix-utah/events/301213597">Remix Meetup June 🏖</a>
```

This *also* allows the user to navigate to another page to view more data, but enables them to control the data that comes back by including the user’s input in the generated URL:

```html
<form action="/remix-utah/events/search">
	<label for="event-search">Query</label>
	<input id="event-search" type="search" name="query" />
	<button type="submit">Search</button>
</form>
```

Let’s say the user types “August” in the input and hits enter. Thanks to the `action` the user would be sent to `/remix-utah/events/search?query=August`. So by default, `<form>` is just like `<a>` with the special ability of allowing the user to provide input.

## Mutating data

For both `<form>` and `<a>`, the navigation is performed via a `GET` request, which makes sense because you’re trying to `GET` data. But what if the user is trying to *modify* the data?

For example, let’s say you want to be able to sign up for an event with `/remix-utah/events/301213597/join`. If we made that endpoint a `GET` then we could do that like so:

```html
<a href="/remix-utah/events/301213597/join">Join Remix Meetup June 🏖</a>
```

This would certainly work (you could even use a `<form>` with a submit button if you wanted. However, this would also open your users up to a potential problem: **accidental or malicious modification of data**. Since `GET` requests are designed to be idempotent (they should be callable repeatedly without observable effects), using them for state-changing actions can lead to unintended consequences.

Additionally, if you made a login form using a `GET` request, then the user submits their password and the URL looks like this: `/login?username=kody&password=kodylovesyou`! The user’s submission is in plain text in plain sight!

This is part of the reason we have `POST` requests and while you can’t make `<a>` use `POST` instead of `GET`, you can do this with `<form>`.

`POST` requests are designed for submitting data to be processed to a specified resource. There’s no feature of HTML that triggers a `POST` request without user interaction, so they can safely be used to change the state of the server, which is perfect for our scenario of joining an event. Here’s how you can use a form to `POST` data:

```html
<form action="/remix-utah/events/301213597/join" method="POST">
	<button type="submit">Join Remix Meetup June 🏖</button>
</form>
```

By using `method="POST"`, we indicate that this form is meant to modify data on the server. The server will then process this request and update its state accordingly, ensuring that the user's intent to join the event is recorded.

### Handling Data Mutations with JavaScript

While traditional form submissions cause a full page reload, modern web applications often use JavaScript to handle these actions asynchronously, providing a smoother user experience.

Here's an example of how you might handle a form submission with JavaScript:

```html
<form id="join-event-form">
	<button type="submit">Join Remix Meetup June 🏖</button>
</form>

<script type="module">
	const form = document.getElementById('join-event-form')
	form.addEventListener('submit', async (event) => {
		event.preventDefault()

		const response = await fetch('/remix-utah/events/301213597/join', {
			method: 'POST',
			headers: { 'Content-Type': 'application/json' },
			body: JSON.stringify({ /* any necessary data can go here */ }),
		})

		if (response.ok) {
			alert('Successfully joined the event!')
		} else {
			alert('Failed to join the event.')
		}
	})
</script>
```

This script intercepts the form submission, prevents the default browser behavior, and instead sends an asynchronous `POST` request to the server. This way, the page does not need to reload, and the user receives immediate feedback on their action.

You may notice the lack of `method="POST"` in this example and that’s because it’s not strictly necessary since we prevent the browser’s default behavior.

While preventing the full page refresh is great, we lose a lot of things the browser does for us automatically when we prevent that default behavior which result in bugs we find in applications all the time.

For example, race conditions and data revalidation. That said, if you have a framework that helps you with those things (like [React Router](https://reactrouter.com/)/[Remix](https://remix.run)), then the effort is worth the improved user experience.

## React Form Actions

Mutations are an important and common part of dynamic web applications. So is linking to different parts of the application. However, mutating data is complicated because as soon as the user has performed the mutation, there are parts of the UI they could be looking at that could be out of date.

Now, to be clear, with a regular browser mutation there isn’t a problem because the full page refresh means the user always sees the latest that the server has to offer. However, if we’re focused on providing the best user experience possible, the full page refresh is unacceptable. But that means we need to update the data on the page after the mutation.

Another thing that complicates both links and forms in client-side applications is managing pending states. By default, the browser will show a spinner (often in place of the favicon), but when we prevent that default behavior we need to think about giving feedback to the user during the transition.

React has a great solution [for transitions](https://react.dev/reference/react/useTransition), but that’s only half of the story for forms. Because of this added complexity, React 19 has a built-in mechanism for handling forms called “actions.”

Just like the action attribute in an HTML form, you use the action prop in a React component. However, in addition to a URL, you can instead provide a function which will be called upon submission of the form.

```tsx
function JoinEventForm() {
	function joinEvent(formData) {
		const response = await fetch('/remix-utah/events/301213597/join', {
			method: 'POST',
			body: formData,
		})

		if (response.ok) {
			alert('Successfully joined the event!')
		} else {
			alert('Failed to join the event.')
		}
	}

	return (
		<form action={joinEvent}>
			<button type="submit">Join Remix Meetup June 🏖</button>
		</form>
	)
}
```

If you’re familiar with React forms using the `onSubmit` prop, I want you to note a few key differences here:

1. There’s no need to add `event.preventDefault` because that’s handled for us by React
2. The `action` is automatically treated as a transition, so anything that happens during the action which trigger components to suspend will be a part of that same transition. More on this in a bit.
3. We can hook into the pending state of this action using `useFormStatus` .
4. React manages errors and race conditions to ensure our form’s state is always correct (no infinite spinners).

## Pending States

There are a couple ways to manage the pending states for this interaction.

### useFormStatus

If you’re familiar with how context works in React apps, think of the `<form>` component as a provider and the `useFormStatus` hook as a function which accesses that provider’s data. Fundamentally, the `<form>` in React manages state of the status of the form and we can access that in any child component of the `<form>` . So to access the pending state of our form (while the submission is in flight) we need to create a child component.

```tsx
function JoinButton({ children }: { children: React.ReactNode }) {
	const { pending } = useFormStatus()

	return (
		<button type="submit">
			{pending ? 'Joining...' : children}
		</button>
	)
}

function JoinEventForm() {
	async function joinEvent(formData) {
		const response = await fetch('/remix-utah/events/301213597/join', {
			method: 'POST',
			body: formData,
		})

		if (response.ok) {
			alert('Successfully joined the event!')
		} else {
			alert('Failed to join the event.')
		}
	}

	return (
		<form action={joinEvent}>
			<JoinButton>Join Remix Meetup June 🏖</JoinButton>
		</form>
	)
}
```

The cool thing about [the `useFormStatus` hook](https://react.dev/reference/react-dom/hooks/useFormStatus) is that it also gives you access to other things about the form (including the submitted data). So if you’re building a login form, you could have the pending state say: `logging you in as {data.get('username')}` .

One thing I don’t love about it though is the requirement to make an entirely new component to consume the form’s state, so let’s look at an alternative approach.

### useActionState

It’s easiest to explain [`useActionState`](https://react.dev/reference/react/useActionState) with an example:

```tsx
const JOIN_URL = '/remix-utah/events/301213597/join'

async function joinEvent(
	previousState: { joined: boolean },
	formData: FormData,
) {
	const response = await fetch(JOIN_URL, {
		method: 'POST',
		body: formData,
	})

	if (response.ok) {
		return { joined: true }
	} else {
		return { joined: false }
	}
}

function JoinEventForm() {
	const [state, formAction, isPending] = useActionState(
		joinEvent,
		{ joined: false },
		JOIN_URL,
	)

	return (
		<div>
			{state.joined ? (
				<p>See you there!</p>
			) : (
				<form action={formAction}>
					<button type="submit">
						{isPending ? 'Joining...' : 'Join Remix Meetup June 🏖'}
					</button>
				</form>
			)}
		</div>
	)
}
```

Alright, so what’s going on here is `useActionState` accepts a function (`joinEvent`), some initial state (`{ joined: false }`), and optionally a permalink URL (`JOIN_URL`). It then returns an array with the current state (`state`), a function you can call to trigger the action (`formAction`), and whether the form submission is pending (`isPending`).

The `joinEvent` function accepts the previous state. In a way you can think of it as a reducer a la `useReducer`. When our form is submitted, it’s `action` is called with the `formData`. Our `action` is the `formAction`. The `formAction` function will call `joinEvent` with the current state followed by any arguments it’s called with. I understand that may be a little confusing, so let me illustrate by being obnoxiously verbose:

```tsx
function JoinEventForm() {
	const [state, formAction, isPending] = useActionState(
		(prevState, ...args) => joinEvent(prevState, ...args),
		{ joined: false },
		JOIN_URL,
	)

	return (
		<div>
			{state.joined ? (
				<p>See you there!</p>
			) : (
				<form
					action={(formData) => {
						const args = [formData]
						formAction(...args)
					}}
				>
					<button type="submit">
						{isPending ? 'Joining...' : 'Join Remix Meetup June 🏖'}
					</button>
				</form>
			)}
		</div>
	)
}
```

The `action` prop is called with the `formData`, we then make an array called `args` with only one element of `formData` which we then spread into a call of `formAction`. `formAction` then calls our inline function with the `prevState` and the rest of the args (in our case that’s just the `formData`, but as far as `useActionState` is concerned, it doesn’t have to be. It just forwards along whatever arguments there are.

From there, our `joinEvent` function performs whatever async stuff it needs to do, and then it returns a value which ends the transition and triggers our form to rerender with the `state` being equal to our returned value.

Of course during the transition, `isPending` will be `true` so we can show our pending state. However, we don’t have access to the `formData` outside our `action` so we wouldn’t be able to use the form submission as part of our pending UI like we could with `useFormStatus`. But there’s even more we can do!

Before we talk about that, I’ll just briefly mention that the third argument to `useActionState` is called a `permalink` and it’s there for server rendering and progressive enhancement. What React does with that is set the `action` to the URL you provide during server rendering. That way if the form is submitted before React has a chance to load on the page, the regular browser behavior will take over and submit the form with the full-page refresh functionality we’re used to (you’ll just want to make sure your server can handle the form submission properly). Hooray for progressive enhancement!

### useOptimistic

Showing the user feedback of pending tasks is important and useful. It’s awesome if the pending state actually looks like the finished state (maybe with a subtle indicator that it’s not actually complete). A good example of this is when you send a Slack/Discord message. The message appears in the messages list, but it’s slightly transparent to give you the sense that it’s an incomplete mutation.

You can do this with [`useOptimistic`](https://react.dev/reference/react/useOptimistic):

```tsx
// ...

function JoinEventForm() {
	const [state, formAction] = useActionState(
		joinEvent,
		{ joined: false },
		JOIN_URL,
	)
	const [optimisticJoined, setOptimisticJoined] = useOptimistic(state.joined)

	return (
		<div>
			{optimisticJoined ? (
				// show faded a bit if we've not yet finished joining...
				<p style={{ opacity: state.joined ? 1 : 0.8 }}>See you there!</p>
			) : (
				<form
					action={(formData) => {
						setOptimisticJoined(true) // Optimistically set the state to joined
						return formAction(formData)
					}}
				>
					<button type="submit">
						Join Remix Meetup June 🏖
					</button>
				</form>
			)}
		</div>
	)
}
```

The `useOptimistic` hook allows you to immediately update the UI to reflect the user's action before the network request completes. If the actual request fails, the state is reverted to the previous state. This provides a smoother user experience by reducing the perceived latency of the action.

We can even remove the pending UI from the button, but we add a little transparency to the success message to give the impression things are not completely settled. You may want to consider the experience for non-seeing users as well. React provides us with all we need to build this kind of experience!

You can even perform multiple steps and keep the user up-to-date with what’s happening with `useOptimistic`. It’s awesome:

```tsx
// ...

function JoinEventForm() {
	const [state, formAction] = useActionState(
		joinEvent,
		{ joined: false },
		JOIN_URL,
	)
	const [optimisticMessage, setOptimisticMessage] = useOptimistic("")

	return (
		<div>
			{state.joined ? (
				<p>See you there!</p>
			) : (
				<form
					action={async (formData) => {
						setOptimisticMessage("Joining meetup...")
						await formAction(formData)
						setOptimisticMessage("Sending notifications...")
						await sendNotification()
					}}
				>
					<p>{optimisticMessage}</p>
					<button type="submit">
						Join Remix Meetup June 🏖
					</button>
				</form>
			)}
		</div>
	)
}
```

In this example, we use the `useOptimistic` hook to provide feedback to the user at multiple stages of the form submission process. Initially, we set the optimistic message to "Joining meetup...", then await the `formAction`. Once that completes, we update the message to "Sending notification..." and await the `sendNotification` function.

## Conclusion

I think it’s awesome that we’ve not needed to reach for any libraries other than React to have all of this functionality. Really, what’s cool is what you *don’t see* but get like declarative management of errors and pending transitions and proper management of race conditions. And a great Optimistic UI story is also awesome. We also didn’t get to talk much about how this integrates with the server via the [`"use server"`](https://react.dev/reference/rsc/use-server) directive, but that’s a huge win as well which we’ll have to explore in the future.

I hope this article helped you get a more clear picture of what’s possible with React 19’s form primitives.

React 19 introduces terrific primitives for building great forms. Let's dive deep on forms for the web with React.

A deep dive on forms with modern React

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.

Compound Components: Truly Flexible React APIs

What and Why: Compound Components in React

Real-World Impact & When to Use

Get my free 7-part email course on React!

More Articles

Generating Unique IDs for Client-Only Data in React

How a “Useless” Tip Saved Ben's Sanity in Production

A deep dive on forms with modern React

Myths about useEffect