Deep Dive Into React Effects In 2023

Of all the React topics that could use a refresh, the docs on useEffect probably needed it the most. The new docs are an amazing achievement, and it is my pleasure to guide you through all I learned from them.

Effects are an advanced topic. This guide hopes to hold a helping hand while pulling no punches.

If you’re new to React, I’d recommend reading the official Quick Start guide first. If you’re already familiar with React and just need a refresher on useEffect for the new year, buckle up! You’re in for a wild ride.

Effects are the second-to-last concept introduced in the new docs.

When React Hooks were first released on February 2019, a lot of attention was put on the useEffect hook. That made sense at the time because useEffect was the point of contact between the new hooks paradigm and the familiar concept of the “component lifecycle.”

However, the over-reliance on useEffect and the lack of best practices at the time led to an avalanche of problems. In short, every single React dev is scarred for life from reading unmaintainable piles of Effects.

By putting Effects at the end of the docs, the React team aims to fix things and subdue the excessive use and glorification of Effects.

There’s a difference between “Effect” and “side effect.”

Before diving deep into what an Effect is, let’s pause for a second and look at the wording.

In the new docs, the thing that you add to a component with the useEffect hook is called an “Effect” (always capitalized).

By capitalizing “Effect”, it’s easy to distinguish it from the generic concept of “side effect”.

This is in contrast to the old docs, in which the thing that you add to a component with the useEffect hook was called “side effect” or just “effect.”

The old docs might have given the impression that side effects are only found on the useEffect hook. But that’s not true at all. Most side effects in React should be on event handlers instead.

Effects are side effects that are caused by rendering, not by user actions.

As a refresher, there are two kinds of code in React components:

• Rendering code (which is pure, except for one bizarre edge-case), and
• side effects (which actually do something).

Most of the time, as we just said, you should use event handlers when you want side effects.

But sometimes there’s no suitable user event. Enter Effects.

Effects let you specify side effects that are caused by the rendering of a component itself, rather than by a particular event caused by a user action.

Not pictured: The purity of our Lord Jesus Christ.

Don’t rush to add Effects to your components.

The truth is that many React apps can get away with little Effects, provided they follow the best practices recommended in the new docs.

But why is it good to avoid Effects? Simply put, they are too powerful, and they often produce code that’s hard to understand.

In a sense, Effects are the fulfilment of the covenant between the React framework and the developer: We get the full power of JavaScript to influence React’s workings, yet we must exercise restraint to avoid being devoured by the Leviathan of complexity.

Think of Effects as a last resort “escape hatch.”

Effects are used to synchronize a component with an external system.

As we said before, you are free to use an Effect any time you need a side effect that’s caused by the rendering of a component. Go ahead, I won’t stop you.

But, according to the new docs, there’s only one valid reason why you would need a side effect that’s caused by the rendering of a component.

And that is: When you need to keep your component synchronized with an external system.

Here, external system means any piece of code that’s not controlled by React, such as:

• DOM APIs. Like timers managed with setInterval(), or event subscriptions using window.addEventListener().
• Third-party libraries. Like an animation library with an API like animation.start() and animation.reset().
• A network. Using the fetch() API to perform a network request.

Note: The fact that your component interacts with an external system is not enough reason to use an Effect. If the interaction with the external system can be handled by refs and event handlers instead, please do so.

Effects run after rendering.

Effects run at the end of the rendering process, after the browser paints the screen update. In other words, useEffect “delays” a piece of code from running until that render is reflected on the screen.

The React team, in all its wisdom, thinks that’s a good time to synchronize the React components with some external system. And it makes sense: React’s entire business is to make pixels dance on the screen, so any external system should back off until React is done.

But if your Effect is doing something visual and it causes some visual flickering, React also offers the useLayoutEffect hook, which blocks the browser from painting until your Effect has run.

How to write an Effect.

It’s easy. Just import and declare your Effect:

import { useEffect } from 'react';

function MyComponent() {
  useEffect(() => {
    // Code here will run after *every* render
  });
  return <div />;
}

When you are synchronizing a component with an external system, you could use a prop to define the sync behavior.

Let’s look at an example of that. Here’s a VideoPlayer component that synchronizes with the browser media API based on the “isPlaying” prop:

function VideoPlayer({ src, isPlaying }) {
  const ref = useRef(null);

  useEffect(() => {
    if (isPlaying) {
      ref.current.play();
    } else {
      ref.current.pause();
    }
  });

  return <video ref={ref} src={src} loop playsInline />;
}

Here’s what happens when VideoPlayer renders (either the first time or if it re-renders):

• First, React will update the screen.
• Then, React will run your Effect, which will call play() or pause() depending on the value of isPlaying prop.

You can use a similar approach to wrap any non-React code (like jQuery plugins) into declarative React components.

Effects run after *every* render, unless you declare dependencies.

By default, Effects run after every render. Often, this is not what you want:

• Sometimes it’s slow. Synchronizing with an external system is not always instant, so you might want to skip doing it unless it’s necessary.
• Sometimes it’s wrong. For example, you don’t want to trigger a component fade-in animation on every render, but only when the component first appears.

In the example VideoPlayer above, the Effect will run on every render, and that’s fine. But if you want to change that, add an array of dependencies as the second argument.

You should start by adding an empty array:

  useEffect(() => {
    // ...
  }, []);

Then you’ll see that the linter is warning about missing dependencies. But don’t panic! Just follow the linter’s instructions until your Effect looks like this:

  useEffect(() => {
    if (isPlaying) { // It's used here...
      // ...
    } else {
      // ...
    }
  }, [isPlaying]); // ...so it must be declared here!

That’s it, you’re done! Specifying [isPlaying] as the dependency array tells React that it should skip re-running your Effect if isPlaying is the same as it was during the previous render.

The dependency array can contain multiple dependencies. React will only skip re-running the Effect if all of the dependencies you specify have exactly the same values as they had during the previous render. React compares the dependency values using the Object.is comparison.

In React, dependencies choose you.

Notice that you can’t “choose” your dependencies.

As a React developer, your task is to write the Effect code. Your only choice regarding dependencies is:

• If you want your Effect to run at every render, don’t add an array of dependencies.
• If you want your Effect to not run at every render, add an array of dependencies and let React fill it.

That’s right, the array of dependencies must match what React expects. You have no say on the matter. This behavior helps catch many bugs in your code.

Careful readers might ask: How does React decide what should be in the array of dependencies?

Technically, the array of dependencies is the list of all reactive values referenced inside the Effect. We’ll look at what “reactive value” means later.

Readers might also ask: Shouldn’t I be able to change the dependencies array to define precisely when an Effect runs?

No, but fear not. Soon, we’ll see a lot of techniques to tightly control when an Effect runs without messing with the dependencies array, including the new and almighty useEffectEvent hook!

The different behaviours with and without the dependency array.

As a summary, let’s look at how the behaviour changes with and without the dependency array:

useEffect(() => {
  // This runs after every render
});

useEffect(() => {
  // This runs only on mount (when the component appears)
}, []);

useEffect(() => {
  // This runs on mount *and also* if either a or b have changed since the last render
}, [a, b]);

Refs and set functions are omitted from the dependency array.

In the example VideoPlayer above, you might have noticed that the Effect uses “ref”, but React doesn’t want to include “ref” as a dependency.

This is because the “ref” object has a stable identity. It never changes, so it will never by itself cause the Effect to re-run.

The set functions returned by useState also have stable identity, so they will be omitted too.

Note that this behavior depends on what the linter can see, as the docs exquisitely explain:

Omitting always-stable dependencies only works when the linter can “see” that the object is stable. For example, if ref was passed from a parent component, you would have to specify it in the dependency array. However, this is good because you can’t know whether the parent component always passes the same ref, or passes one of several refs conditionally. So your Effect would depend on which ref is passed.

Add a cleanup if needed.

Sometimes you need to specify how to stop, undo, or clean up the synchronization with the external system. For example, “connect” needs “disconnect”, “subscribe” needs “unsubscribe”, and “fetch” needs either “cancel” or “ignore”.

To do that, return a cleanup function from your Effect:

useEffect(() => {
  const connection = createConnection();
  connection.connect();
  return () => {
    connection.disconnect();
  };
}, []);

React will call an Effect’s cleanup function each time before the Effect runs again, and one final time when the component unmounts.

Some Effects don’t need a cleanup function. More often they do — but if not, React will behave as if you returned an empty cleanup function that doesn’t do anything.

Effects fire twice in development.

At the time of the First World War, Switzerland had a tiny standing army, but a populace of skilled riflemen. In 1912, Kaiser Wilhelm II asked what a militia of a quarter million Swiss would do if he invaded with an army of a half million Germans. Their response? “Shoot twice and go home.”

React’s Strict Mode is just as bold. Firing twice might be annoying, but it will help you fix bugs that you might have never conceived, making you effectively go home sooner.

Let’s look at one example: By remounting your component, React verifies that navigating away and back doesn’t break your code. Users are known to navigate back and forth for no reason at all, so this trick can save you countless hours of debugging in production!

If you’re dealing with a bug caused by Effects firing twice in development, the right question isn’t “how to run an Effect just once”, but “how to fix my Effect so that it works after remounting”.

Usually, the answer is to implement a cleanup function. The cleanup function should stop or undo whatever the Effect was doing.

The rule of thumb is that the user shouldn’t be able to distinguish between the Effect running once (as in production) and a setup → cleanup → setup sequence (as you’d see in development).

How to cleanup an Effect that animates?

If your Effect animates something in, the cleanup function should reset the animation to the initial values:

useEffect(() => {
  const node = ref.current;
  node.style.opacity = 1; // Trigger the animation
  return () => {
    node.style.opacity = 0; // Reset to the initial value
  };
}, []);

In development, opacity will be set to 1, then to 0, and then to 1 again. This should have the same user-visible behavior as setting it to 1 directly, which is what would happen in production.

How to cleanup an Effect that fetches data?

If your Effect fetches something, the cleanup function should either abort the fetch or ignore its result:

useEffect(() => {
  let ignore = false;

  async function startFetching() {
    const json = await fetchTodos(userId);
    if (!ignore) {
      setTodos(json);
    }
  }

  startFetching();

  return () => {
    ignore = true;
  };
}, [userId]);

The docs explicitly say that an ignore flag is better than an AbortController, because the AbortController can be unreliable if there are asynchronous steps chained after the fetch.

Unless you’re building a library, don’t fetch data from Effects.

Ideally, the last example isn’t something you should worry about because you shouldn’t write your own logic to fetch data on component mount. Just like routing, it’s not trivial to do well.

Why not? The docs offer plenty of reasons:

• Effects don’t run on the server, so it’s hard to make effect-based data fetching play along with server-side rendering.
• It’s easy to end up with “network waterfalls,” and it’s hard to support fetching data in parallel.
• It’s hard to do preloading or caching.
• There’s quite a bit of boilerplate code involved to avoid race conditions.

Instead, the docs suggest two alternatives:

• If you use a meta-framework (like Next.js, Gatsby, or Remix), use its built-in data fetching mechanism.
• Otherwise, consider using a client-side “fetching with cache” library. Popular open source solutions include TanStack Query, useSWR, and React Router 6.4+.

Buying a product is not an Effect.

Sometimes, even if you write a cleanup function, there’s no way to prevent user-visible consequences of running the Effect twice:

useEffect(() => {
  // Wrong: This Effect fires twice in development, exposing a problem in the code.
  fetch('/api/buy', { method: 'POST' });
}, []);

You wouldn’t want to buy the product twice. However, the behavior of “firing twice in development” also exposes a good reason why you shouldn’t put this logic in an Effect. What if the user goes to another page and then presses Back? Your Effect would also run again.

Buying is not caused by rendering; it’s caused by a specific interaction. So you should delete the Effect and make the request from the “buy” button’s event handler.

Note that POST request are fine in Effects if they are not related to user events, but rather to the rendering of a component (for example a POST request to track analytics).

Each render has its own Effects.

You can think of useEffect as “attaching” a piece of behavior to the render output.

In React, “rendering” is like taking a snapshot of the UI in time. A component’s props, state, local variables, event handlers, and Effects are all calculated and attached to the render output, thanks to the magic of closures.

The new docs offer two deep dives into how this works for Effects.

You don’t need an Effect to cache expensive calculations.

If you have an expensive calculation on render, but you don’t want to recalculate it if some unrelated state variable changes, you can cache (or “memoize”) it by wrapping it in a useMemo hook.

If you define its dependencies, it will only run when they change.

Remember, whatever you put inside useMemo should be pure.

And as always, don’t optimize prematurely. The new docs have a nice guide to figure out if a calculation is expensive. As a rule of thumb, if some calculation takes 1 millisecond or more, it might benefit from useMemo.

Avoid chains of Effects.

Sometimes you might feel tempted to chain Effects that each adjust a piece of state based on other state, and trigger each other.

That’s not only inefficient, but it’s a clear signs that your codebase is possessed by Satan. Simply put, as your code evolves, you will run into cases where the “chain” you wrote doesn’t fit the new requirements, and you will resort to ritualistic poultry sacrifices in order to refactor that shit. Lord have mercy!

As a rule of thumb: Before creating a chain of Effects, try to calculate what you can during rendering, and adjust the state as much as possible in event handlers instead.

But sometimes, the chain is unavoidable: For example, imagine a form with multiple dropdowns where the options of the next dropdown depend on the selected value of the previous dropdown, and you have to fetch the new values from the network. Then, a chain of Effects fetching data is appropriate because you are synchronizing with an external system.

Yes, even in this day and age, a form that’s anything but trivial can easily cook up a succulent Spaghetti Bolognese that would make your Italian grandmother proud.

Be careful when initializing your application with Effects.

Some logic should only run once when the app loads.

You might place it in an Effect in the top-level component. But this is no bueno! You’ll quickly discover that it runs twice in development.

There are two possible solutions. You are free to pick whichever works best for your application. Either use a flag:

let didInit = false;

function App() {
  useEffect(() => {
    if (!didInit) {
      didInit = true;
      // Only runs once per app load
      loadDataFromLocalStorage();
      checkAuthToken();
    }
  }, []);
  // ...
}

Or put it outside:

if (typeof window !== 'undefined') { // Check if we're running in the browser.
   // Only runs once per app load
  checkAuthToken();
  loadDataFromLocalStorage();
}

function App() {
  // ...
}

Check the docs for tradeoffs of each approach.

If your external system is a “store”, consider useSyncExternalStore.

If you are using an Effect to synchronize your component to something that could be described as an “external store” that you “subscribe into” — say something like Redux, or even some built-in browser API — then you could use useSyncExternalStore.

Now, I’m gonna be honest here. It’s not very clear to me why the new docs are pushing so much for this bizarre new hook. It’s not clear to me why it’s better than useEffect. Also, I had the impression that useSyncExternalStore was for library authors.

If I were you, I would ignore it for now. But keep your eyes open, this hook might become more useful in the future. Only time will tell.

An Effect’s lifecycle is different from a component’s lifecycle.

Every React component goes through the same lifecycle:

• A component mounts when it’s added to the screen.
• A component updates when it receives new props or state. This usually happens in response to an interaction.
• A component unmounts when it’s removed from the screen.

That’s a good way to think about components, but not about Effects.

If you are not a complete monster that ignores the dependency array rules, you would agree that an Effect describes how to synchronize an external system to a component’s rendering.

With that in mind, we can say that to write an Effect, all you need to do is to describe how to start synchronization and how to stop it. If you do it well, your Effect will be resilient to being started and stopped as many times as it’s needed.

Now you’re thinking with Effects!

Each Effect represents a separate synchronization process.

Resist the temptation of adding unrelated logic to your Effect only because this logic needs to run at the same time as an Effect you already wrote.

It’s more maintainable to have two Effects, if they represent separate processes.

Reactive values: Another way to look at dependencies.

Dear reader, thank you for making it this far in the article. I’m proud of you. Don’t worry, this is the last time we’ll redefine how Effects work, we are almost done.

So, what are reactive values?

Props, state, and all variables declared inside the component are reactive because they’re calculated during rendering and participate in the React data flow.

Any reactive value can change on a re-render, so reactive values used by an Effect must be included in dependencies array.

Effects can “react” to any values from the component body. (Yeah, title drop!)

You can also think of Effects as reactive blocks of code because they re-synchronize when the values you read inside of them change.

So, if your Effect uses a value that’s defined outside of the component, the linter won’t ask you to add it as a dependency because it’s not a reactive value.

Mutable values (including global variables) can’t be dependencies.

A mutable value like location.pathname can’t be a dependency. It’s mutable, so it can change at any time completely outside of the React rendering data flow. This also breaks the rules of React because reading mutable data during rendering (which is when you calculate the dependencies) breaks purity of rendering.

For the same reason, a mutable value like ref.current or things you read from it also can’t be a dependency.

What to do when you don’t want to re-synchronize?

Ok, here’s the big question. Let’s say you have some dependencies in your array but you don’t want them to trigger a synchronization. As a developer, you don’t have much control of the dependencies, so what can you do?

You could “prove” to the linter that these values aren’t reactive values. For example, by moving them outside of the component, or by moving them inside the Effect.

You could also avoid relying on objects and functions as dependencies. If you create objects and functions during rendering and then read them from an Effect, they will be different on every render.

Don’t ignore the linter.

Sometimes people take extreme measures to avoid re-synchronizing. If you have an existing codebase, you might have some Effects that suppress the linter like this:

useEffect(() => {
  // ...
  // eslint-disable-next-line react-hooks/exhaustive-dependencies
}, []);

There’s no need for that. The linter is your friend. If the linter suggests a dependency, but adding it causes a loop or some other issue, it doesn’t mean the linter should be ignored. It means you need to change the code inside (or outside) the Effect so that that value isn’t reactive and doesn’t need to be a dependency.

React’s ultimate weapon: useEffectEvent

Let’s finish our tour of Effects with a bang!

React devs know true pain.

For eons, React codebases were corrupted with //estlint-disable-next-lines. We, the React devs, have been waiting patiently for useEffectEvent since February 2019!

I cannot overstate my joy. I’ll let the code speak for itself:

function Page({ url }) {
  const { items } = useContext(ShoppingCartContext);
  const numberOfItems = items.length;

  const onVisit = useEffectEvent(visitedUrl => {
    logVisit(visitedUrl, numberOfItems);
  });

  useEffect(() => {
    onVisit(url);
  }, [url]); // All dependencies declared
  // ...
}

Here, onVisit is an Effect Event. The code inside it isn’t reactive. This is why you can use numberOfItems (or any other reactive value!) without worrying that it will cause the surrounding code to re-execute on changes!

Mind you, this feature is still experimental. But the React team has hinted that it will be released by the time the new React docs are out of beta, which should be soon.

Closing thoughts

Dear reader, if you made it this far, I commend you. We have been through a lot together. We have laughed, we have cried, we have bled React. And now we are better for it.

But I must be honest with you: The new React docs are way better than my impious writing, be sure to check them out!

For my full breakdown of the new React docs, click here:

React JS Best Practices From The New Docs

Thanks for reading! If you enjoy humorous tech stories like these and want to support me to keep writing forever, consider signing up to become a Medium member. It’s $5 a month, giving you unlimited access to stories on Medium. If you sign up using my link, I’ll earn a small commission. You can also follow me on Medium and Twitter.

Join Medium with my referral link — Sebastian Carlos