---
title: "Rules of React's useEffect | CoderPad"
description: "useEffect is prolific in React apps. Here are four rules associated with the hook and in-depth explanations of why they're important."
canonical: "https://coderpad.io/blog/development/rules-of-reacts-useeffect/"
last_modified: "2023-06-05 14:36:06"
---
[Back to blog](https://coderpad.io/blog/)

# Rules of React’s useEffect

February 15, 2022 8 Minute Read

By Corbin Crutchley

[Development](https://coderpad.io/blog/development/)

React’s`useEffect`is a powerful API with lots of capabilities, and therefore flexibility. Unfortunately, this flexibility often leads to abuse and misuse, which can greatly damage an app’s stability.

The good news is that if you follow a set of rules designated to protect you during coding, your application can be secure and performant.

No, we’re not talking about React’s “ [Rules of Hooks](https://reactjs.org/docs/hooks-rules.html) ”, which includes rules such as:

- No conditionally calling hooks
- Only calling hooks inside of hooks or component
- Always having items inside of the dependency array

These rules are good, but can be detected automatically with linting rules. It’s good that they’re there (and maintained by Meta), but overall, we can pretend like everyone has them fixed because their IDE should throw a warning.

Specifically, I want to talk about the rules that can only be caught during manual code review processes:

- Keep all side effects inside`useEffect`
- Properly clean up side effects
- Don’t use`ref`in`useEffect`
- Don’t use`[]`as a guarantee that something only happens once

While these rules may seem obvious at first, we’ll be taking a deep dive into the “why” of each. As a result, you may learn something about how React works under the hood – even if you’re a React pro.

## Learn how to run front-end developer interviews that don’t suck

[Read our guide](https://coderpad.io/blog/interviewing/5-tips-for-interviewing-frontend/)

## Keep all side effects inside`useEffect`

For anyone familiar with React’s docs, you’ll know that this rule has been repeated over and over again. But why? Why is this a rule?

After all, what would prevent you from storing logic inside of a`useMemo`and simply having an empty dependency array to prevent it from running more than once?

Let’s try that out by running a network request inside of a`useMemo`:

```
const EffectComp = () => {
  const [activity, setActivity] = React.useState(null);

  const effectFn = React.useMemo(() => {
    // Make a network request here
    fetch("https://www.boredapi.com/api/activity")
      .then(res => res.json())
      .then(res => setActivity(res.activity));
  }, [])

  return <p>{activity}</p>
}Code language: JavaScript (javascript)
```

Huh. It works first try without any immediately noticeable downsides. This works because`fetch`is asynchronous, meaning that it doesn’t block the [event loop](https://www.youtube.com/watch?v=8aGhZQkoFbQ&vl=en). Instead, let’s change that code to be a synchronous`XHR`request and see if that works too.

```
function getActivity() {
  var request = new XMLHttpRequest();
  request.open('GET', 'https://www.boredapi.com/api/activity', false);  // `false` makes the request synchronous
  request.send(null);

  return JSON.parse(request.responseText);
}

const EffectComp = () => {
  const [data, setData] = React.useState(null);

  const effectFn = React.useMemo(() => {
    setData(getActivity().activity);
  }, []);

  return <p>Hello, world! {data}</p>;
}Code language: JavaScript (javascript)
```

Here, we can see behavior that we might not expect to see. When using useMemo alongside a blocking method, the entire screen will halt before drawing anything. The initial paint is then made after the fetch is finally finished.

However, if we use useEffect instead, this does not occur.

Here, we can see the initial paint occur, drawing the “Hello” message before the blocking network call is made.

Why does this happen?

### Understanding hook lifecycles

The reason`useEffect`is still able to paint but useMemo cannot is because of the timings of each of these hooks. You can think of`useMemo`as occurring right in line with the rest of your render code.

In terms of timings, the two pieces of code are very similar:

```
const EffectComp = () => {
  const [data, setData] = React.useState(null);

  const effectFn = React.useMemo(() => {
    setData(getActivity().activity);
  }, []);

  return <p>Hello, world! {data}</p>;
}Code language: JavaScript (javascript)
```

```
const EffectComp = () => {
  const [data, setData] = React.useState(null);

  setData(getActivity().activity);

  return <p>Hello, world! {data}</p>;
}Code language: JavaScript (javascript)
```

This inlining behavior occurs because`useMemo`runs during the “render” phase of a component.`useEffect`, on the other hand, runs after a component renders out, which allows an initial render before the blocking behavior halts things for us.

Those among you that know of “useLayoutEffect” may think you have found a gotcha in what I just said.

“Ahh, but wouldn’t useLayoutEffect also prevent the browser from drawing until the network call is completed?”

Not quite! You see, while useMemo runs during the render phase, useLayoutEffect runs during the “ commit” phase and therefore renders the initial contents to screen first.

>

[useLayoutEffect’s signature is identical to useEffect, but it fires synchronously after all DOM mutations.](https://reactjs.org/docs/hooks-reference.html#uselayouteffect)

See, the commit phase is the part of a component’s lifecycle after React is done asking all the components what they want the UI to look like, has done all the diffing, and is ready to update the DOM.

>

If you’d like to learn more about how React does its UI diffing and what this process all looks like under the hood, take a look at [Dan Abramov’s wonderful “React as a UI Runtime” post](https://overreacted.io/react-as-a-ui-runtime/).

There’s also [this awesome chart demonstrating how all of the hooks tie in together](https://github.com/Wavez/react-hooks-lifecycle) that our chart is a simplified version of.

Now, this isn’t to say that you should optimize your code to work effectively with blocking network calls. After all, while`useEffect`allows you to render your code, a blocking network request still puts you in the uncomfortable position of your user being unable to interact with your page.
Because JavaScript is single-threaded, a blocking function will prevent user interaction from being processed in the event loop.

>

If you read the last sentence and are scratching your head, you’re not alone. The idea of JavaScript being single-threaded, what an “event loop” is, and what “blocking” means are all quite confusing at first.

We suggest taking a look at [this great explainer talk from Philip Robers](https://www.youtube.com/watch?v=8aGhZQkoFbQ) to understand more.

That said, this isn’t the only scenario where the differences between`useMemo`and`useEffect`cause misbehavior with side effects. Effectively, they’re two different tools with different usages and attempting to merge them often breaks things.

Attempting to use`useMemo`in place of`useEffect`leads to scenarios that can introduce bugs, and it may not be obvious what’s going wrong at first. After long enough, with enough of these floating about in your application, it’s sort of “death by a thousand paper-cuts”.

These papercuts aren’t the only problem, however. After all, the APIs for useEffect and useMemo are not the same. This incongruity between APIs is especially pronounced for network requests because a key feature is missing from the`useMemo`API: effect cleanup.

## Always clean up your side effects

Occasionally, when using`useEffect`, you may be left with something that requires cleanup. A classic example of this might be a network call.
Say you have an application to give bored users an activity to do at home. Let’s use a network request that retrieves an activity from an API:

```
const EffectComp = () => {
  const [activity, setActivity] = React.useState(null);

  React.useEffect(() => {
    fetch("https://www.boredapi.com/api/activity")
      .then(res => res.json())
      .then(res => setActivity(res.activity));
  }, [])

  return <p>{activity}</p>
}Code language: JavaScript (javascript)
```

While this works for a single activity, what happens when the user completes the activity?

Let’s give them a button to rotate between new activities and include a count of how many times the user has requested an activity.

```
const EffectComp = () => {
  const [activity, setActivity] = React.useState(null);
  const [num, setNum] = React.useState(1);

  React.useEffect(() => {
    // Make a network request here
    fetch("https://www.boredapi.com/api/activity")
      .then(res => res.json())
      .then(res => setActivity(res.activity));
    // Re-run this effect when `num` is updated during render
  }, [num])

  return (
  <div>
    <p>You should: {activity}</p>
    <p>You have done {num} activities</p>
    <button onClick={() => setNum(num + 1)}>Request new activity</button> 
  </div>
  )
}Code language: JavaScript (javascript)
```

Just as we intended, we get a new network activity if we press the button. We can even press the button multiple times to get a new activity per press.
But wait, what happens if we slow down our network speed and press the “request” button rapidly?

Oh no! Even tho we’ve stopped clicking the button, our network requests are still coming in. This gives us a sluggish feeling experience, especially when latency times between network calls are high.

Well, this is where our cleanup would come into effect. Let’s add an [AbortSignal](https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal) to cancel a request when we request a new one.

```
const EffectComp = () => {
  const [activity, setActivity] = React.useState(null);
  const [num, setNum] = React.useState(1);

  React.useEffect(() => {
    const controller = new AbortController();
    const signal = controller.signal;

    // Make a network request here
    fetch("https://www.boredapi.com/api/activity", {signal})
      .then(res => res.json())
      .then(res => setActivity(res.activity));

    return () => {
      controller.abort();
    }
    // Re-run this effect when `num` is updated during render
  }, [num])

  return (
  <div>
    <p>You should: {activity}</p>
    <p>You have done {num} activities</p>
    <button onClick={() => setNum(num + 1)}>Request new activity</button>
  </div>
  )
}Code language: JavaScript (javascript)
```

If we open our network request tab, you’ll notice how our network calls are now being canceled when we initialize a new one.

This is a good thing! It means that instead of a jarring experience of jumpiness, you’ll now only see a single activity after the end of a chain of clicking.

While this may seem like a one-off that we created ourselves using artificial network slowdowns, this is the real-world experience users on slow networks may experience!

What’s more, when you consider API timing differences, this problem may be even more widespread.

Let’s say that you’re using a [new React concurrent feature](https://coderpad.io/blog/development/why-react-18-broke-your-app/), which may cause an interrupted render, forcing a new network call before the other has finished.

The first call hangs on the server for slightly longer for whatever reason and takes 500ms, but the second call goes through immediately in 20ms. But oh no, during that 480ms there was a change in the data!

This means that our`.then`which runs`setActivity`will execute on the first network call – complete with stale data (showing “10,000”) – after the second network call.

This is important to catch early, because these shifts in behavior can be immediately noticeable to a user when it happens. These issues are also often particularly difficult to find and work through after the fact.

## Don’t use refs in useEffect

If you’ve ever used a useEffect to apply an`addEventListener`, you may have written something like the following:

```
const RefEffectComp = () => {
  const buttonRef = React.useRef();

  const [count, setCount] = React.useState(0);

  React.useEffect(() => {
    function buttonAdder() {
        setCount(v => v + 1);
    }

    buttonRef.current.addEventListener('click', buttonAdder);

    return () => {
        buttonRef.current.removeEventListener('click', buttonAdder);
    }
  }, [buttonRef.current])

  return <div>
    <p>{count}</p>
    <button ref={buttonRef}>Click me</button>
  </div>
}Code language: JavaScript (javascript)
```

While this might make intuitive sense due to utilizing`useEffect`’s cleanup, this code is actually not correct. You should not utilize a`ref`or`ref.current`inside of a dependency array for a hook.

This is because changing refs does not force a re-render and therefore useEffect never runs when the value changes.

While most assume that`useEffect`“listens” for changes in this array and runs the effect when it changes, this is an inaccurate mental model.

A more apt mental model might be: “useEffect only runs at most once per render. However, as an optimization, I can pass an array to prevent the side effect from running if the variable references inside of the array have not changed.”

This shift in understanding is important because the first version can easily lead to bugs in your app. For example, instead of rendering out the button immediately, let’s say that we need to defer the rendering for some reason.

Simple enough, we’ll add a`setTimeout`and a boolean to render the button.

```
const RefEffectComp = ()=>{
  const buttonRef = React.useRef();

  const [count, setCount] = React.useState(0);

  React.useEffect(() => {
    function buttonAdder() {
      setCount(v => v + 1);
    }
          console.log('UseEffect has run');
          // This will throw an error during the first render otherwise
    if (!buttonRef.current) return;

    buttonRef.current.addEventListener('click', buttonAdder);

    return () => {
      buttonRef.current.removeEventListener('click', buttonAdder);
    }
  }, [buttonRef.current])

  const [shouldRender, setShouldRender] = React.useState(false);

  React.useEffect(() => {
    const timer = setTimeout(() => {
      setShouldRender(true);
    }, 1000);

    return () => {
      clearTimeout(timer);
      setShouldRender(false);
    }
  }, []);

  return <div>
    <p>{count}</p>
    {shouldRender && <button ref={buttonRef}>Click me</button>}
  </div>
}Code language: JavaScript (javascript)
```

Now, if we wait a second for the button to render and click it, our counter doesn’t go up!

This is because once our`ref`is set after the initial render, it doesn’t trigger a re-render and our`useEffect`never runs.

A better way to write this would be to utilize a [“callback ref”](https://unicorn-utterances.com/posts/react-refs-complete-story#callback-refs), and then use a`useState`to force a re-render when it’s set.

```
const RefEffectComp = ()=>{
  const [buttonEl, setButtonEl] = React.useState();

  const [count, setCount] = React.useState(0);

  React.useEffect(() => {
    function buttonAdder() {
      setCount(v => v + 1);
    }

    if (!buttonEl) return;

    buttonEl.addEventListener('click', buttonAdder);

    return () => {
      buttonEl.removeEventListener('click', buttonAdder);
    }
  }, [buttonEl])

  const [shouldRender, setShouldRender] = React.useState(false);

  React.useEffect(() => {
    const timer = setTimeout(() => {
      setShouldRender(true);
    }, 1000);

    return () => {
      clearTimeout(timer);
      setShouldRender(false);
    }
  }, []);

  return <div>
    <p>{count}</p>
    {shouldRender && <button ref={buttonElRef => setButtonEl(buttonElRef)}>Click me</button>}
  </div>
}Code language: JavaScript (javascript)
```

This will force the re-render when`ref`is set after the initial render and, in turn, cause the`useEffect`to trigger as expected.

To be fair, this “rule” is more of a soft rule than anything. There are absolutely instances – such as setTimeout timers – where utilizing a ref inside of a useEffect make sense. Just make sure you have a proper mental model about refs and useEffect and you’ll be fine.

>

Want to refine your understanding of refs even further? [See my article outlining the important details of refs for more.](https://unicorn-utterances.com/posts/react-refs-complete-story)

## Don’t expect an empty dependency array to only run once

While previous versions of React allowed you to utilize an empty array to guarantee that a`useEffect`would only run once, [React 18 changed this behavior](https://coderpad.io/blog/development/why-react-18-broke-your-app/). As a result, now`useEffect`may run any number of times when an empty dependency array passes, in particular when a [concurrent feature is utilized](https://github.com/reactwg/react-18/discussions/46#discussioncomment-846786).

Concurrent features are new to React 18 and allow React to pause, halt, and remount a component whenever React sees it appropriate.

As a result, this may break various aspects of your code.

You can [read more about how an empty dependency array can break in your app from our article about React 18’s changes to mounting.](https://coderpad.io/blog/development/why-react-18-broke-your-app/)

## Conclusion

React’s useEffect is an instrumental part of modern React applications. Now that you know more about its internals and the rules around it, you can build stronger and more dynamic programs!

If you want to continue learning skills that will help make your React apps better, I suggest taking a look at [our guide to React Unidirectionality](https://coderpad.io/blog/development/master-react-unidirectional-data-flow/), which outlines a good way to keep your application flow more organized.

## Subscribe for more CoderPad insights

## Trending Articles

Previous slide Next slide [Development

## What is Prompt Engineering?

Introducing AI tools such as ChatGPT and Bard helps increase the efficiency of tasks such as data generation, code generation and completion, text summarization, etc. How were these AI tools trained to answer almost every question you ask them? The answer, prompt engineering, is discussed in this blog post.

Read the post](https://coderpad.io/blog/development/what-is-prompt-engineering/) [Development

## A Guide To Using React’s useCallback() Hook

Are you looking to optimize your React applications? Have you heard of the useCallback hook? useCallback is a powerful React hook that helps you optimize your application by preventing unnecessary re-renders. In this post, we'll dive into React's useCallback() hook, define referential equality and callback functions and how to tie it all together.

Read the post](https://coderpad.io/blog/development/a-guide-to-using-reacts-usecallback-hook/) [Development

## MySQL vs. PostgreSQL: How Do They Compare?

A database is a convenient tool that allows users to access information, maintain records, and apply commonly used operations, such as insertion, modification, deletion, and data organization. Learn about MySQL vs PostgreSQL, their features, advantages, and disadvantages. Finally, check out which one is the best choice for you.

Read the post](https://coderpad.io/blog/development/mysql-vs-postgresql-how-do-they-compare/) [Development

## PostgreSQL LIKE Operator: A Detailed Guide

When using databases, searching for values that match a given pattern is a familiar necessity. Learn how you can retrieve entries with queries including a particular string using Postgres LIKE operator.

Read the post](https://coderpad.io/blog/development/postgresql-like-operator-a-detailed-guide/) [Development

## How To Use DataProvider In TestNG With Examples

When it comes to testing there are many tools and techniques available. In this post, we'll discuss how to use DataProvider with TestNG.

Read the post](https://coderpad.io/blog/development/how-to-use-dataprovider-in-testng-with-examples/) [Development

## How To Get Up And Running With Django Migrations: A Guide

Django migrations are a way of handling the application of changes to a database schema. By following the steps outlined in this guide, you can easily set up and use migrations in your Django projects.

Read the post](https://coderpad.io/blog/development/how-to-get-up-and-running-with-django-migrations-a-guide/) [Development

## Writing A Parameterized Test In JUnit With Examples

A JUnit parameterized test allows you to decouple data from structure, generating cleaner and more reliable tests. Learn more in this guide.

Read the post](https://coderpad.io/blog/development/writing-a-parameterized-test-in-junit-with-examples/) [Development

## How To Use Assert In JUnit With Examples

The JUnit Assert class is what you use to write unit testing assertions in JUnit. Learn more about it in this guide, full of examples.

Read the post](https://coderpad.io/blog/development/how-to-use-assert-in-junit-with-examples/) [Development

## A Simple Guide To TypeORM: What It Is And How To Use It

Considering current languages have object-oriented programming features, most database management systems are based on the relational model, with tables instead of objects. For these reasons, mapping relational objects is very important in development. In this article, you will learn what TypeORM, one of the main tools used today, is.

Read the post](https://coderpad.io/blog/development/a-simple-guide-to-typeorm-what-it-is-and-how-to-use-it/) [Development

## Using PreparedStatement in JDBC With Examples

In this post, we'll see why and how to work with JDBC and PreparedStatement. We will also learn along with examples using code.

Read the post](https://coderpad.io/blog/development/using-preparedstatement-in-jdbc-with-examples/) [Development

## React vs React Native: The Differences Explained

React and React Native are similar in that they both allow web developers to build applications based on the unique concept of components. But the two frameworks do this in radically different ways. In this post, we cover the key differences between react and react native frameworks, implementation, and which is an appropriate choice.

Read the post](https://coderpad.io/blog/development/react-vs-react-native-the-differences-explained/) [Development

## Logging in Django

The most challenging part of fixing a problem is identifying it. Unfortunately, this statement is exceptionally true when it comes to debugging. Learn how to use the power of logging into your Django applications to improve your debug process in this article.

Read the post](https://coderpad.io/blog/development/logging-in-django/)

## Hire with confidence.

See why engineering teams trust CoderPad to evaluate developers with realistic, AI-ready hiring workflows.

[Request a demo](https://coderpad.io/sales/)