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

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

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?

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

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

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

Can you modify React Props?

Why React needs a key prop

Myths about useEffect