<a href="https://www.freepik.com/free-psd/3d-rendering-graphic-design_31283887.htm" target="_blank" rel="noreferrer noopener">3D rendering of graphic design<span class="hidden"> (Opens in a new tab)</span></a> by <a href="https://www.freepik.com/author/freepik" target="_blank" rel="noreferrer noopener">Freepik<span class="hidden"> (Opens in a new tab)</span></a>, <a href="https://www.freepik.com/free-vector/geometric-circle-background-desktop-wallpaper-with-multicolors-vector_18220903.htm" target="_blank" rel="noreferrer noopener">Vector geometric background<span class="hidden"> (Opens in a new tab)</span></a> by <a href="https://www.freepik.com/author/rawpixel-com" target="_blank" rel="noreferrer noopener">rawpixel.com<span class="hidden"> (Opens in a new tab)</span></a> via <a href="https://freepik.com" target="_blank" rel="noreferrer noopener">Freepik<span class="hidden"> (Opens in a new tab)</span></a>, blurred code image created with <a href="https://carbon.now.sh" target="_blank" rel="noreferrer noopener">Carbon<span class="hidden"> (Opens in a new tab)</span></a>, Next.js logo from <a href="https://nextjs.org" target="_blank" rel="noreferrer noopener">Next.js official website<span class="hidden"> (Opens in a new tab)</span></a>, Disqus logo from <a href="https://disqus.com/brand/" target="_blank" rel="noreferrer noopener">Disqus Brand and Logos official material<span class="hidden"> (Opens in a new tab)</span></a>

Next.js theme switch and Disqus embed

In <a href="https://www.oh-no.ooo/articles/a-blasting-august-with-blaugust" target="_blank" rel="noreferrer noopener">my last post about the amazing Blaugust event<span class="hidden"> (Opens in a new tab)</span></a>, I've been mentioning my issue with setting up my <a href="https://nextjs.org" target="_blank" rel="noreferrer noopener">Next.js<span class="hidden"> (Opens in a new tab)</span></a> site combined with <a href="https://www.npmjs.com/package/next-themes" target="_blank" rel="noreferrer noopener">next-themes<span class="hidden"> (Opens in a new tab)</span></a> and <a href="https://disqus.com/" target="_blank" rel="noreferrer noopener">Disqus<span class="hidden"> (Opens in a new tab)</span></a> commenting platform.

This article is here to make sure I can share my solution, as for as simple it was it might help some people that stumble upon it. Let's start first with what issue I had, what I've done, so that we can walk together through the solution!

## What was the issue
After following the <a href="https://dev.to/luisca/step-by-step-guide-to-adding-dark-mode-and-multiple-themes-to-your-nextjs-app-15lh" target="_blank" rel="noreferrer noopener">Step-By-Step Guide to Adding Dark Mode and Multiple Themes to Your Next.js App<span class="hidden"> (Opens in a new tab)</span></a> written by <a href="https://dev.to/luisca" target="_blank" rel="noreferrer noopener">Luis Cadillo<span class="hidden"> (Opens in a new tab)</span></a> (thank you pal!), I found myself with a neat Dark mode but my Disqus embed (installed through <a href="https://www.npmjs.com/package/disqus-react" target="_blank" rel="noreferrer noopener">disqus-react npm package<span class="hidden"> (Opens in a new tab)</span></a>) would not update its theme properly, despite its theme settings being on `Auto`.

<figure>
        <img src="//images.ctfassets.net/hzu7wkrk7tly/3UqieaGPLVgDYj3UwVSHnF/6a048c82fd500213b31979933da29d7a/buggy_disqus_theme.png?fm=avif&r=50" class="big-picture" />
        <figcaption>
            Buggy Disqus theme change at the bottom of my articles
        </figcaption>
    </figure>

I checked that the settings in `<sitename>.disqus.com/admin/settings/general/` were correct, but that didn't help.

<figure>
        <img src="https://images.ctfassets.net/hzu7wkrk7tly/6UJHYV3ekkdBDgjEnGE9yP/f02cdaa0483280661ac222555af511a1/Screenshot_2023-08-05_at_1.22.38.png?fm=avif&r=25&w=600" class="big-picture" />
        <figcaption>
            Disqus settings for automatic detection of the color scheme.
        </figcaption>
    </figure>

## The solution

My initial challenge was understanding how Disqus determined which theme to show in the page. Browsing the documentation I stumbled on a piece of useful information:

<blockquote>
<span class="font-bold">Light vs. dark color scheme</span><br />
A light or dark color scheme is automatically selected based on your site's stylesheets.
<br />
<br />
<span class="font-bold">How is the color scheme determined?</span><br />
<ul>
  <li><mark>The light scheme is loaded when <strong>the text color Disqus inherits from your site has >= 50% gray contrast</strong>: between color: #000000; and color: #787878;</mark></li>

  <li>The dark scheme is loaded in all other instances.</li>
</ul>
<div class="text-right">— <a href="https://help.disqus.com/en/articles/1717201-disqus-appearance-customizations" target="_blank" rel="noreferrer noopener">Disqus Appearance Customization<span class="hidden"> (Opens in a new tab)</span></a></div>
</blockquote>

This allowed me to understand how the color scheme in Disqus was determined, but not yet why my changes wouldn't work. White text on a white background isn't quite the 'Auto' mode I was hoping for!

Searching for some help in <a href="https://stackoverflow.com/" target="_blank" rel="noreferrer noopener">StackOverflow<span class="hidden"> (Opens in a new tab)</span></a>, I found my very same problem but no answer to it: <a href="https://stackoverflow.com/questions/75921829/disqus-theme-not-matching-background-when-changing-blog-theme-from-dark-to-light" target="_blank" rel="noreferrer noopener">Disqus theme not matching background when changing blog theme from dark to light<span class="hidden"> (Opens in a new tab)</span></a>. Despite not finding a solution, I found some comfort in seeing that other peeps had my same problem and that it wasn't just me being... well... dumb xD

A little bit more digging and googling around brought me to another StackOverflow post, <a href="https://stackoverflow.com/questions/75787047/disqus-comments-dark-mode-renders-with-white-background?rq=2" target="_blank" rel="noreferrer noopener">Disqus comments Dark mode renders with white background<span class="hidden"> (Opens in a new tab)</span></a> where <a href="https://stackoverflow.com/users/10312920/ken-mueller" target="_blank" rel="noreferrer noopener">Ken Mueller<span class="hidden"> (Opens in a new tab)</span></a> mentions to "Remove the &lt;meta name="color-scheme" content="dark" /&gt; from your document.".

Now, I didn't have such a thing in my Next.js ecosystem, but I noticed that next-themes applied a `style="color-scheme: dark;"` to my main HTML tag.

```html
<html lang="en" class="dark" style="color-scheme: dark;">
```

<figure>
        <img src="https://images.ctfassets.net/hzu7wkrk7tly/7gl5NhSwwFZc4LgivqyAsN/7a8d2bb8d723d383321339d100e41862/Screenshot_2023-08-05_at_12.43.25.png?fm=avif&r=25&w=600" />
        <figcaption>
            My Chrome inspector showing that the HTML tag in my website had this extra <code>style="color-scheme: dark;"</code> property.
        </figcaption>
</figure>

Since messing around with the inspector costs nothing, I've simply tried to remove the content of `style` and don't you know... it worked!

Checking <a href="https://www.npmjs.com/package/next-themes" target="_blank" rel="noreferrer noopener">next-themes documentation<span class="hidden"> (Opens in a new tab)</span></a>, reading the codebase and bashing my head a little, I seem to understand that this HTML style change comes from the `enableColorScheme` setting of next-themes, which by default is set as `true`, but for my case would need to be set `false`.

```typescript
const MyApp = ({ Component, pageProps }: AppProps) => {
  return (
    <>
      <ThemeProvider attribute="class" enableColorScheme={false}>
        <Provider store={store}>
          <Component {...pageProps} />
        </Provider>
      </ThemeProvider>
    </>
  );
};

export default MyApp;
```

Wohoo! Works like a charm!

But no, wait!

Now if I am in an article page and I want to switch the theme there, my `<DiscussionEmbed>` component from  <a href="https://www.npmjs.com/package/disqus-react" target="_blank" rel="noreferrer noopener">disqus-react<span class="hidden"> (Opens in a new tab)</span></a> won't update automatically! So what do we do now?

I happen to have this component wrapped in a container for easier setup on my page, and I know that React would re-render a component should its key change... so 1 + 1 I had my 2:

```typescript
const DisqusComments: FC<DisqusCommentsProps> = ({ url, slug, title }) => {
  // Import the name of the theme with useTheme() hook
  // from next-themes
  const { theme } = useTheme(); 

  const disqusConfig = {
    url: url,
    identifier: slug,
    title: title,
  };

  // Use it as a key={theme} for the DiscussionEmbed component
  // so that it will re-render should the theme change
  return (
    <div className="my-14">
      <DiscussionEmbed key={theme} shortname={"oh-no"} config={disqusConfig} />
    </div>
  );
};

export default DisqusComments;
```

Basically, I'll use the name of the theme to determine whether the Disqus component should re-render, and should someone change the theme in an article page, __the Disqus comment section will reload with the correct theme__!

At last, all I wanted!

<figure>
        <img src="//images.ctfassets.net/hzu7wkrk7tly/37HN4qOVbiyzNuHZEKBPaa/490dbc65f7935bb6555b17fe6a4bcabd/Disqus_comment_section_light_dark_theme.png?fm=avif&r=25" class="big-picture" />
        <figcaption>
            My website Disqus section adapting to both dark and light color schemes. Yay!
        </figcaption>
</figure>

Let me know if this helped you somehow, if you had the same issue or if somehow it brought you some help understanding a bit more about the problem for your own specific case!

So, you want to have both a light and dark theme in your Next.js website, but your Disqus embed doesn't seem to change its theme accordingly... Maybe this will help!

Fixing Disqus Auto theme switching when using Next.js and next-themes

Custom

React

Next.js

Disqus

Fixing Disqus 'Auto' theme switching when using Next.js + next-themes

<a href="https://www.freepik.com/free-psd/3d-female-character-with-question-marks_13678520.htm" target="_blank" rel="noreferrer noopener">Puzzled person<span class="hidden"> (Opens in a new tab)</span></a> and <a href="https://www.freepik.com/free-vector/realistic-3d-shapes-floating-background_13397766.htm" target="_blank" rel="noreferrer noopener">Background 3d composition<span class="hidden"> (Opens in a new tab)</span></a> by <a href="https://www.freepik.com/author/freepik" target="_blank" rel="noreferrer noopener">Freepik<span class="hidden"> (Opens in a new tab)</span></a>, <a href="https://www.freepik.com/free-psd/website-coding-icon-3d-illustration_28638422.htm" target="_blank" rel="noreferrer noopener">Cute round interface<span class="hidden"> (Opens in a new tab)</span></a> by <a href="https://www.freepik.com/author/ekayasadesign" target="_blank" rel="noreferrer noopener">Ekayasa.Design<span class="hidden"> (Opens in a new tab)</span></a>

React issues

From version 16.8 of react, we have had the honours of using hooks to lighten up our codebase, and bring state and lifecycle methods only to the components that require it, making the class component structure not needed anymore and allowing us to use and reuse the prepacked hooks as well as the ones we make ourselves :D

While today we're not talking in details about <a href="https://react.dev/reference/react" target="_blank" rel="noreferrer noopener" title="Hooks, React official documentation website">what is a Hook, which you can find in React official documentation website<span class="hidden"> (Opens in a new tab)</span></a>, we will spend a bit more time discussing about the common misuses of the ever so popular __useEffect hook__ that most of us know and love for its versatility.

The __useEffect hook__ is a feature of React that allows us to perform *side effects* in functional components. This can include things like modifying the DOM, fetching data, or subscribing to event listeners.

<blockquote>In JavaScript, <mark>a <strong>side effect</strong> is like an action that changes something outside its own function.</mark> Think of it as altering a global setting, updating a web page element, or requesting data online.</blockquote>

The useEffect hook in React gives you a simplified way to manage these actions in function components, bypassing the need for class-based components, simplifying overall the writing and understanding of the code and also boosting the app performance by dodging needless re-renders.

It also allows you to specify a cleanup function, which is called when the component is unmounted, to prevent memory leaks and other issues.

```javascript
import React, { useState, useEffect } from 'react';

function Example() {
  const [count, setCount] = useState(0);

  // Similar to componentDidMount and componentDidUpdate:
  useEffect(() => {
    // Update the document title using the browser API
    document.title = `You clicked ${count} times`;
  });

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}
```

There are several common mistakes that developers make when using the useEffect hook in React. Between newsfeeds, videos and personal experiences, I've seen a few cases more often than others; let's go through some of those together :D

## 1. Failing to include a cleanup function

Sometimes we might need to take into account that an user might resize the browser window, and that things like sub-menus or advertising banners need to contemplate such resize and behave accordingly; we might be easily tempted to do the following

```javascript
import React, { useEffect } from 'react';

function MyComponent() {
  useEffect(() => {
    function handleResize() {
      console.log(window.innerWidth);
    }

    window.addEventListener('resize', handleResize);
  }, []);

  return (
    <div>
      Resize the window and check your console to see the changes.
    </div>
  );
}

export default MyComponent;

```

... and kinda be okay with it.

(In this code, our component uses useEffect to add an event listener to the window whenever the component mounts. The listener logs the window's inner width whenever the window is resized.)

But there's a problem - if the component unmounts, the event listener will still be there, potentially causing memory leaks. This is where the cleanup function comes in. __By returning a function from our useEffect__, we're telling React to call this function when the component is about to unmount.

```javascript
import React, { useEffect } from 'react';

function MyComponent() {
  useEffect(() => {
    function handleResize() {
      console.log(window.innerWidth);
    }

    window.addEventListener('resize', handleResize);

    // Add a cleanup to remove the eventListener
    // when the component is dismounted
    return () => {
      window.removeEventListener('resize', handleResize);
    }
  }, []);

  return (
    <div>
      Resize the window and check your console to see the changes.
    </div>
  );
}

export default MyComponent;

```

Adding a simple `return() => { ... }` to your useEffect will make sure that the EventListener that checks the window resize will be removed and that it will not take its toll when there's no more need for it.

<hr />

## 2. Failing to use the dependencies' array

In the previous example, as we always wanted at every resize to track the new inner width of the browser window, we didn't need to be concerned with the array of dependencies of useEffect. In a lot of other rather common scenarios, however, we want our useEffect to be triggered when specific values change.

Let's say you have a component that fetches some user data based on a __userId__ prop, and displays whether the user is online or not based on an __isOnline__ state. You would want to refetch this data whenever `userId` or `isOnline` change. We could do something like this (omitting TypeScript for simplicity):

```javascript
import React, { useState, useEffect } from 'react';

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [isOnline, setIsOnline] = useState(false);

  useEffect(() => {
    async function fetchData() {
      const response = await fetch(`/api/user/${userId}`);
      const data = await response.json();
      setUser(data);

      if (data.status === "online") {
        setIsOnline(true);
      } else {
        setIsOnline(false);
      }
    }

    fetchData();
  // Our dependency array including the values we want to watch over
  }, [userId, isOnline]); 

  return (
    <div>
      <h1>{user ? user.name : 'Loading...'}</h1>
      <p>{isOnline ? 'Online' : 'Offline'}</p>
    </div>
  );
}

export default UserProfile;

```

The useEffect hook has `[userId, isOnline]` as its dependency array. This means that the `fetchData` function will be called not only when the component first mounts, but also whenever `userId` or `isOnline` change.

If you forget to include a dependency in the array, or include the wrong dependency, it can cause your effect to be run more or less frequently than intended:
- if you leave the array of dependencies empty, __the effect will only run once__ (...which for some cases it might be what you're looking for)
- if you add all the dependencies your editor might suggest you, __you might end up re-rendering the component more than you need__, making your app slow or with undesired outcomes - don't let the editor tell you better on this one xD

## 3. Not using `AbortController` when dealing with fetch requests

Building up from our previous example, if the component `UserProfile` would render as a result of a click on a list of users, one potential problem could be that our component could receive *old data* as a result of a delayed response.

<figure>
<img src="https://images.ctfassets.net/hzu7wkrk7tly/54yeQjNQt8GpP3STw50eVp/72ab886def596041e89e3e63a8d340bc/delayed_requests.gif" alt="Representation of an interface where clicking on different list items (user profiles) too fast might result in misleading UI results. User #1 information will load with no issues; User #2 information will still be loading as the fetch request is still on its way, User #3 information will be only briefly displayed, as finally User #2 request is fulfilled." />
  <figcaption>Representation of an interface where clicking on different list items (user profiles) too fast might result in misleading UI results. User #1 information will load with no issues; User #2 information will still be loading as the fetch request is still on its way, User #3 information will be only briefly displayed, as finally User #2 request is fulfilled.</figcaption>
</figure>

(Yay, a gif!)

We got ourselves in a very unfavorable race condition.

<blockquote>A <strong>race condition</strong> is a situation in programming where the behavior of a piece of code depends on the relative timing of multiple threads/processes.</blockquote>

Race conditions often appear when working with Promises, asynchronous functions, or any kind of deferred execution, such as setTimeout or setInterval. These issues can be mitigated by properly managing the flow of execution in asynchronous operations (for example, using async/await or chaining Promises with then).

So how do we prevent our UI from showing the response of a delayed and outdated request?! You know it, `AbortController` is here to save the day :D

```javascript
import React, { useState, useEffect } from 'react';

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [isOnline, setIsOnline] = useState(false);

  useEffect(() => {
    // Create an AbortController
    const abortController = new AbortController(); 

    async function fetchData() {
      try {
        // We use abortController in our fetch request to keep track
        // of a potential abort signal
        const response = await fetch(`/api/user/${userId}`, { signal: abortController.signal });

        if (!response.ok) {
          throw new Error(response.status);
        }

        const data = await response.json();
        setUser(data);

        if (data.status === "online") {
          setIsOnline(true);
        } else {
          setIsOnline(false);
        }
      } catch (error) {
        if (error.name === 'AbortError') {
          console.log('Fetch aborted');
        } else {
          console.error('An unexpected error happened:', error);
        }
      }
    }

    fetchData();

    return () => {
      // Now if userId or isOnline change, the useEffect cleanup will
      // trigger the abortController and stop any ongoing fetch request
      // connected to it
      abortController.abort();
    };
  }, [userId, isOnline]);

  return (
    <div>
      <h1>{user ? user.name : 'Loading...'}</h1>
      <p>{isOnline ? 'Online' : 'Offline'}</p>
    </div>
  );
}

export default UserProfile;
```

In this updated code
- we create a new `AbortController` instance before the fetch request
- the `signal` property from the `AbortController` is passed to the fetch options
- the `abort()` method is called in the cleanup function returned by useEffect, causing the fetching to be canceled

Basically now, if the userId changes before the fetch has completed, the fetch for the previous userId will be cancelled to prevent setting state on an unmounted component or outdated fetch requests. And well, another great way to prevent memory leaks.

I'd definitely recommend have a look <a href="https://developer.mozilla.org/en-US/docs/Web/API/AbortController" target="_blank" rel="noreferrer noopener">at the documentation for AbortController on mdn web docs<span class="hidden"> (Opens in a new tab)</span></a>, as there you get to see all sorts of examples and exhaust any curiosity about it!

One of my favourite youtubers, <a href="https://www.youtube.com/@WebDevSimplified/about" target="_blank" rel="noreferrer noopener">Web Dev Simplified<span class="hidden"> (Opens in a new tab)</span></a>, has put this issue in better words than either I or ChatGPT will ever manage, so head out to watch his video about <a href="https://youtu.be/GGo3MVBFr1A?t=1015" target="_blank" rel="noreferrer noopener">Top 6 React Hook Mistakes Beginners Make<span class="hidden"> (Opens in a new tab)</span></a>, you'll have a great explanation I promise!

<iframe width="100%" height="400" src="https://www.youtube-nocookie.com/embed/GGo3MVBFr1A?start=1015" data-embed-title="Top 6 React Hook Mistakes Beginners Make" data-embed-url="https://www.youtube.com/watch?v=GGo3MVBFr1A&start=1015" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

<hr />

## 4. Relying on the order of useEffect calls

__The order in which useEffect calls are executed is not guaranteed__, meaning that we should definitely not rely on the order of useEffect calls to determine the behavior of your components.

Let's say we have a blog website where we fetch user information and the user's blog posts. We might be tempted to separate the data fetching into multiple useEffects for better separation of concerns:

```typescript
import React, { useState, useEffect } from 'react';

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [posts, setPosts] = useState(null);

  // Fetch user data
  useEffect(() => {
    fetch(`/api/user/${userId}`)
      .then(response => response.json())
      .then(data => setUser(data));
  }, [userId]);

  // Fetch user posts
  useEffect(() => {
    fetch(`/api/posts?userId=${userId}`)
      .then(response => response.json())
      .then(data => setPosts(data));
  }, [userId]);

  return (
    <div>
      <h1>{user ? user.name : 'Loading user...'}</h1>
      <h2>{posts ? `Posts: ${posts.length}` : 'Loading posts...'}</h2>
    </div>
  );
}

export default UserProfile;
```

While this separation may seem neat, it could lead to unnecessary multiple renders and potential issues with race conditions (one fetch completing before the other).

A better approach might be to combine the two fetch calls into a single useEffect:

```typescript
import React, { useState, useEffect } from 'react';

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [posts, setPosts] = useState(null);

  // Fetch user data and user posts
  useEffect(() => {
    fetch(`/api/user/${userId}`)
      .then(response => response.json())
      .then(data => {
        setUser(data);
        return fetch(`/api/posts?userId=${userId}`);
      })
      .then(response => response.json())
      .then(data => setPosts(data));
  }, [userId]);

  return (
    <div>
      <h1>{user ? user.name : 'Loading user...'}</h1>
      <h2>{posts ? `Posts: ${posts.length}` : 'Loading posts...'}</h2>
    </div>
  );
}

export default UserProfile;
```

In this version, the single useEffect first fetches the user data, then it fetches the user's posts, leaving us with more control over the sequence of events, reducing the number of re-renders and the risk of race conditions.

<hr />

## 5. Not using useEffect at all

Some junior developers may not be aware of the useEffect hook, or may not understand when it is appropriate to use it.

### Performing side effects in the render function

Some of those instances might look as such:

```typescript
// Bad practice
function UserProfile({ userId }) {
  // Fetch will happen in the render
  const user = fetch(`/api/users/${userId}`);

  return <div>{user.name}</div>;
}
```

__The render function in React should be pure__, which means it shouldn't cause any side effects like API calls, subscriptions, or timeouts/intervals. This is because React might call the render function more times than you expect, and having side effects in the render function can lead to unexpected behavior.

And to prevent all that bad, we can simply make use of our friends useEffect and useState:

```typescript
// Better practice
function UserProfile({ userId }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch(`/api/users/${userId}`)
      .then(response => response.json())
      .then(data => setUser(data));
  }, [userId]);

  return <div>{user ? user.name : 'Loading...'}</div>;
}

```

### Not Handling Dependent State Correctly

When state depends on props or another state, it might need to be updated inside a useEffect to ensure it stays in sync, otherwise we might not see updated values.

```typescript
// Bad practice
function SquareArea({ edge }) {
  // Initial value of squared depends on props
  const [squared, setSquared] = useState(edge * edge);

  return <div>{squared}</div>;
}
```

While this might initially appear okay, the problem is that the initial state of squared is set based on the value prop, but useState only sets the initial state once when the component is first rendered. So if the value prop changes in the future, squared will not get updated, because useState does not track the updates of value.

To overcome that, we can do:

```typescript
// Better practice
function SquareArea({ edge }) {
  const [squared, setSquared] = useState(edge * edge); 

  // Update the state when edge changes
  useEffect(() => {
    setSquared(edge * edge);
  }, [edge]);

  return <div>{squared}</div>;
}
```

Our beloved useEffect will take care of updating `squared` every time the `edge` prop will change :D

<hr />

As we can see, useEffect is a powerful tool we can take advantage of to make our apps snappy and sharp, but we need to be wary on how we use it if we don't want to have headaches trying to debug our own mistakes. 🤯

Let me know if I forgot to mention something!


Let's get to know the common weaknesses in using one of our favourite features of React: useEffect! 

Common useEffect mistakes

JavaScript

<a href="https://www.freepik.com/free-vector/gradient-liquid-abstract-background_13346239.htm" target="_blank" rel="noreferrer noopener">Vector Liquid Background<span class="hidden"> (Opens in a new tab)</span></a> by <a href="https://www.freepik.com/author/pikisuperstar" target="_blank" rel="noreferrer noopener">pikistar<span class="hidden"> (Opens in a new tab)</span></a> via <a href="https://freepik.com" target="_blank" rel="noreferrer noopener">Freepik<span class="hidden"> (Opens in a new tab)</span></a>, <a href="https://www.freepik.com/free-psd/3d-illustration-people-working-marketing_42937458.htm" target="_blank" rel="noreferrer noopener">People working marketing<span class="hidden"> (Opens in a new tab)</span></a> by <a href="https://freepik.com" target="_blank" rel="noreferrer noopener">Freepik<span class="hidden"> (Opens in a new tab)</span></a>

Learning React

One of those things that you don't know enough, and then when you know somewhat you tend to use a bit too much is React beloved and behated <a href="https://react.dev/reference/react/useMemo" target="_blank" rel="noreferrer noopener">useMemo hook<span class="hidden"> (Opens in a new tab)</span></a>. In my quest of trying to understand more the features of React that I use on a regular basis, I find myself in need to write more about this hook, clarifying what is it, when to use it and when not.

So, let's get started and unravel this madness!

## What is useMemo?

Introduced in React 16.8, the useMemo hook is a built-in feature designed to memoize values and prevent unnecessary recalculations and re-renders, meaning that instead of calculating things on the fly, it will first check if that computation has already done and take the value already stored.

... Wait wait wait! __memoization what?!__ What's that?!

<a href="https://www.freecodecamp.org/news/author/gercocca/" target="_blank" rel="noreferrer noopener">Germán Cocca<span class="hidden"> (Opens in a new tab)</span></a> makes a great job at explaining this concept <a href="https://www.freecodecamp.org/news/memoization-in-javascript-and-react/" target="_blank" rel="noreferrer noopener">in his article about Memoization in Javascript and React<span class="hidden"> (Opens in a new tab)</span></a>, and I will not try to rewrite it when he's already told it better than I ever can!

<blockquote>
<p>In programming, <strong>memoization is an optimization technique</strong> that makes applications more efficient and hence faster. It does this by storing computation results in cache, and retrieving that same information from the cache the next time it's needed instead of computing it again.</p>
<br />
<p>In simpler words, <mark><strong>it consists of storing in cache the output of a function</strong>, and making the function check if each required computation is in the cache before computing it.</mark></p>
<br />
  <div class="text-right">— <a href="https://www.freecodecamp.org/news/author/gercocca/" target="_blank" rel="noreferrer noopener">Germán Cocca<span class="hidden"> (Opens in a new tab)</span></a> in <a href="https://www.freecodecamp.org/news/memoization-in-javascript-and-react/" target="_blank" rel="noreferrer noopener">What is Memoization? How and When to Memoize in JavaScript and React<span class="hidden"> (Opens in a new tab)</span></a></div>
</blockquote>

So far so good. Yes?! __Nope__.

I have heard that *useMemo should not always be used* and this explanation makes me think instead that it always sounds like a good idea, so let's continue digging up a bit more more, but let's go the long route and let's see first how to implement it.

## How to use useMemo

The basic syntax for useMemo is

```javascript
const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]);
````

This line of code contains the function used to calculate the value and the dependency array. For example, consider a component that filters a list of items based on a search term:

```javascript
import React, { useMemo } from 'react';

const FilteredList = ({ items, searchTerm }) => {
  const filteredItems = useMemo(() => {
    return items.filter(item => item.toLowerCase().includes(searchTerm.toLowerCase()));
  }, [items, searchTerm]);

  return (
    <ul>
      {filteredItems.map(item => (
        <li key={item}>{item}</li>
      ))}
    </ul>
  );
};

```

In this example, we use useMemo to memoize the filtered list of items and avoid recalculating the filtered list every time the component renders. *Still sounds pretty good and still like I should actually be using it more than I actually do.* 🤔

Browsing various examples online, as you can see from the first snippet of code in this article, however, I find the emerging written pattern of using useMemo *only for expensive calculations*, *computed expensive value*, *expensive operations*, and I finally start understanding that there is something particularly in mind for which useMemo is recommended.

But what is an expensive calculation in JavaScript?

## Expensive calculations

Expensive calculations are __tasks that require a significant amount of processing time and resources__: they might be time-consuming, memory-intensive, or computationally complex. What seems to fit in this category is:

- __Manipulating large strings__, such as parsing and transforming text
- __Transforming large datasets through iteration__, while performing multiple calculations on the data
- __Sorting or filtering large arrays__
- __Fetching data through APIs/databases__
- __Processing and manipulating big files__
- __Rendering a top component__ with a significant number of nested components and elements
- __Recursive algorithms__, advanced statistical calculations, matrices, weird formulas etc. etc. etc.

<blockquote data-appearance="suggestion">
<a href="https://react.dev/reference/react/useMemo" target="_blank" rel="noreferrer noopener">React useHook official documentation<span class="hidden"> (Opens in a new tab)</span></a> has a section <a href="https://react.dev/reference/react/useMemo#how-to-tell-if-a-calculation-is-expensive" target="_blank" rel="noreferrer noopener">How to tell if a calculation is expensive?<span class="hidden"> (Opens in a new tab)</span></a> where it teaches us to use the console by adopting <code>console.time()</code> and <code>console.timeEnd()</code> to better determine the cost of our operations.</blockquote>

Not all these operations are inherently worthy of useMemo though! There are at least a few things to consider.

### 1. How often is the operation performed?

If the operation is performed frequently or triggered by state/props changes, and the result doesn't change as often, memoizing the result can prevent redundant recalculations, therefore improving overall performance.

For example, if you have a big array of strings that needs to be formatted in a particular way, and you might want to list all of them in a nice HTML list, using useMemo might help avoiding slow renders in the UI.

### 2. How reusable is the result of useMemo?

The result is used within the component or passed down as props to child components; if the result is used multiple times, useMemo can indeed help avoid unnecessary recalculation.

Think of a large file that you want to use in different sections of your app; it's definitely worth contemplating memoizing it.

### 3. Is it worth the memory consumption?

As the memoized values are stored in memory until the component unmounts or the dependencies change, memoizing large datasets will definitely increase memory consumption; __if the fetching from caching is faster than the recomputation of the calculations, perhaps useMemo might have a valid purpose__.

If you're fetching a big list and your interface freezes, perhaps yes, it's time to think about useMemo.

<hr/>

In all of the above cases, and even more critical than for `useEffect`, __the dependencies of the memoized function need to be properly evaluated__ to make sure that useMemo recalculates the memoized value only when necessary, as performance might otherwise ironically drop.

In his article <a href="https://maxrozen.com/understanding-when-use-usememo" target="_blank" rel="noreferrer noopener">Understand when to use useMemo<span class="hidden"> (Opens in a new tab)</span></a>, <a href="https://twitter.com/RozenMD" target="_blank" rel="noreferrer noopener">Max Rozen<span class="hidden"> (Opens in a new tab)</span></a> puts it up in simple words:

<blockquote>
  <p><mark>Don't use useMemo until you notice parts of your app are frustratingly slow.</mark> <strong>Premature optimisation is the root of all evil</strong>, and throwing useMemo everywhere is premature optimisation.</p>
  <div class="text-right">— <a href="https://twitter.com/RozenMD" target="_blank" rel="noreferrer noopener">Max Rozen<span class="hidden"> (Opens in a new tab)</span></a> in <a href="https://maxrozen.com/understanding-when-use-usememo" target="_blank" rel="noreferrer noopener">Understand when to use useMemo<span class="hidden"> (Opens in a new tab)</span></a></div>
</blockquote>

## "Premature optimization is the root of all evil"

<blockquote data-appearance="warning" class="text-sm">This paragraph might be a tad too long and expanding on a topic that is not quite the purpose of this article; feel free to move to the next header if you already have a grasp about premature optimization. </blockquote>

Calling premature optimization *the root of all evil* seems to be something rather common, and <a href="https://effectiviology.com/itamar-shatz/" target="_blank" rel="noreferrer noopener">Dr. Itamar Shatz<span class="hidden"> (Opens in a new tab)</span></a> in his article about <a href="https://effectiviology.com/premature-optimization/" target="_blank" rel="noreferrer noopener">Premature Optimization: Why It’s the “Root of All Evil” and How to Avoid It<span class="hidden"> (Opens in a new tab)</span></a> says that

<blockquote>
  <p><strong>Premature optimization</strong> involves trying to <mark><strong>improve something</strong> — especially with the goal of perfecting it — <strong>when it’s too early to do so</strong>.</mark></p>

  <div class="text-right">— <a href="https://effectiviology.com/itamar-shatz/" target="_blank" rel="noreferrer noopener">Dr. Itamar Shatz<span class="hidden"> (Opens in a new tab)</span></a> in <a href="https://effectiviology.com/premature-optimization/" target="_blank" rel="noreferrer noopener">Premature Optimization: Why It’s the “Root of All Evil” and How to Avoid It<span class="hidden"> (Opens in a new tab)</span></a></div>
</blockquote>

His article also shows that the famous *Premature optimization is the root of all evil* sentence is a quote from the computer scientist <a href="https://profiles.stanford.edu/donald-knuth" target="_blank" rel="noreferrer noopener">Donald Knuth<span class="hidden"> (Opens in a new tab)</span></a>, from his article <a href="https://dl.acm.org/doi/10.1145/356635.356640" target="_blank" rel="noreferrer noopener">Structured Programming with go to Statements<span class="hidden"> (Opens in a new tab)</span></a>. The article is a reminder to developers not to spend too much time or resources optimizing parts of a program before they need to and especially before they have a working version.

According to Donald Knuth, premature optimization leads to wasted effort, as you might end up optimizing parts of the code that don't have a significant impact on the overall performance, or even optimizing code that eventually gets removed or significantly changed.

His recommendations are to __first build a functional system__, __then identify any performance issues__, and __finally optimize critical parts that actually need optimization__, without forgetting that readability and maintainability are often more important than minor efficiency gains, especially in early development stages.

Dr. Itamar Shatz lists out the <a href="https://effectiviology.com/premature-optimization/#Dangers_of_premature_optimization" target="_blank" rel="noreferrer noopener">dangers of premature optimization<span class="hidden"> (Opens in a new tab)</span></a> in a few yet impactful points, which I recommend reading from his article.

<hr />

I have now some ideas on where useMemo could come at hand as well as potential dangers of premature optimization, but I still feel like the constraints for which it's recommended are still a bit unable to give a clear line. Perhaps it'd be beneficial to go the other route and analyze when _not_ to use useMemo.

## When not to use useMemo

By what we've figured out before, if an operation is relatively simple, doesn't consume much processing time, and doesn't depend on frequently changing data, __using useMemo will add unnecessary overhead without significant performance gains__.

Therefore

- if a component doesn't have any expensive calculations and doesn't render frequently
- or the expensive operation is isolated to a specific part of the component that doesn't impact the overall rendering performance
- or the expensive operation varies significantly between the instances where the component is used
- and we're trying to accommodate all sorts of devices that might not have a lot of memory available
- and the performance improvement is not noticeable by end-users

... __we might find ourselves perhaps not in need of useMemo__.

We also need to consider that adding useMemo to memoize some calculations can make writing unit tests more complicated, and while it's not a reason to avoid useMemo, it's definitely worth to weigh the benefits of memoization also against the ease of testing and maintaining the code.

## Example implementations

From all this reading and writing, I can deduct that there are plausible usages where you expect to process a lot of data, that won't change as often, such as:

```javascript
// Plausible usage of useMemo
import React, { useMemo } from 'react';

const BigProcessedList = ({ data }) => {
  const processedData = useMemo(() => {
    return data.map((item) => {
      // Simulating an expensive computation
      for (let i = 0; i < 1e6; i++) {}
      return item * 2;
    });
  }, [data]);

  return (
    <ol>
      {processedData.map((item, index) => (
        <li key={`${index}__${item}`}>{item}</li>
      ))}
    </ol>
  );
};

```

Another plausible example would be:

```javascript
// Plausible good use of useMemo
import React, { useMemo } from 'react';

const EmployeeList = ({ employees, filter }) => {
  const filteredEmployees = useMemo(() => {
    return employees.filter(emp => emp.department === filter);
  }, [employees, filter]);

  return (
    <ul>
      {filteredEmployees.map((employee) => (
        <li key={employee.id}>{employee.name}</li>
      ))}
    </ul>
  );
};
```

... And potentially, there could be so many bad/unrecommended implementations where there's no big computation needed and therefore useMemo is bringing no real benefit to the end user:

```javascript
// Unoptimal use of useMemo
import React, { useMemo } from 'react';

const CombinedStringComponent = ({ propA, propB }) => {
  const combinedProps = useMemo(() => {
    return `${propA} ${propB}`;
  }, [propA, propB]);

  return (
    <div>{combinedProps}</div>
  );
};
```

Ultimately, the trend with useMemo seems to be that as soon as people get to know more about it, they want to implement it, whereas __it'd make more sense to leave it for only when the app clearly shows benefits from implementing it__. It sounds like a pretty good news to me as it means that most likely I don't have to change anything in this website as I don't seem to see anything particularly too slow... *yay!* 😂

I've truly enjoyed writing about this and I can't help but recommend strongly to read the sources/resources attached to the article; if you feel like I've miswritten something (which can very well be the cause as my best corrections often come days after I rewrote something), don't hesitate to mention that in the comments below!

But before I leave...

## A brief note about useMemo vs. useCallback

You'll also hear this one too! And while `useCallback` is gonna be a topic for another day, let's just iron this one last thing out before we call it a day!

__useCallback__ is similar to useMemo, but __instead of memoizing the result of a function, it memoizes the actual function itself__, which is particularly useful when you have a component that receives a function as a prop and you want to prevent unnecessary re-rendering of child components that depend on that function. This means that if the dependencies of useCallback don't change, __the same function instance is used, avoiding unnecessary re-renders of child components that depend on it__.

Now out! Bye! :D

The useMemo hook is both famous and infamus at the same time. Let's figure out together when we should or should not use it :D

oh-no.ooo

React

Articles

Fixing Disqus 'Auto' theme switching when using Next.js + next-themes

Common useEffect mistakes

Performance optimization with useMemo