<a href="https://www.freepik.com/free-psd/3d-female-character-reading-book_13678507.htm" target="_blank" rel="noreferrer noopener">Person sitting on books<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>

Learning JavaScript

The good perk of having a lot of people who code around you is that you end up discussing things that you don't get to see on a day-to-day basis as a simpleton frontend developer.

This time, I landed on the __concept of symbols in JavaScript__, which is something I don't have to deal with at work, but something that JavaScript offers and it'd be nice to understand what it is and why it is :D

## What is a Symbol?

__A symbol is a unique and immutable data type in JavaScript__.

If that doesn't tell you anything (which indeed didn't for me), know that a symbol is one of the <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures#primitive_values" target="_blank" rel="noreferrer noopener">JavaScript primitive data types<span className="hidden"> (Opens in a new tab)</span></a> just as string, boolean, integer etc. but it works like a *special identifier to access object properties*, and it can be used more or less like a property key.

Let's imagine that we have an object where we store a person's `name`, an `id` and their `age`.

```javascript
let person = {
  name: "Sophia",
  id: 12345678,
  age: 24, // (yes, I'm a trailing comma person)
};
```

If we want to access the value of the `id` property, we'd just do:

```javascript
console.log(person.id); // will give us 12345678
```

It is fair to assume that `id` won't change as often as the other characteristics of a person, and tailor our work around that assumption.

Let's try to use a symbol as a key by creating it. This can be done using the `Symbol()` constructor:

```javascript
let symbolIDKey = Symbol("id");
let person = {
  name: "Sophia",
  [symbolIDKey] = 12345678,
  age: 30,
};
console.log(person[symbolIDKey]); // outputs 12345678
```

You could, in theory, use no `"id"` parameter (properly referred as __descriptor__), but if you were to use more than one symbol key, it'd be more challenging to know which is which.

## Why symbols then?

Using symbols as object keys will provide you with a unique and guaranteed way of accessing object properties, __even if other code adds or modifies properties with the same key__.

For example:

```javascript
let symbolIDKey = Symbol("id");
let person = {
  name: "Sophia",
  [symbolIDKey] = 12345678,
  age: 30,
};
```

Some other code, for whatever reason, will try to do

```javascript
person.id = 00000000;
```

You will be left with

```javascript
let symbolIDKey = Symbol("id");
let person = {
  name: "Sophia",
  [symbolIDKey] = 12345678,
  age: 30,
  id: 00000000,
};

console.log(person.id); // will output 00000000
console.log(person[symbolIDKey]); // will output our more expected 12345678
```

The symbol key is allowing us to preserve the original value even if some other code might try to alter the property `id`.

> With symbols you can add private properties to an object that are not intended to be modified or accessed directly by other code.

But beware! Symbols keys are not enumerated, which means that __they do not show up in the list of keys of the object__ if you try to access them by loops and mappings.

You cannot even access the symbol keys of an object with <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/keys" target="_blank" rel="norefferer noopener">`keys()`<span className="hidden"> (Opens in a new tab)</span></a> nor with <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/getOwnPropertyNames" target="_blank" rel="norefferer noopener">`getOwnPropertyNames()`<span className="hidden"> (Opens in a new tab)</span></a>!

You will need to be aware of the structure of your object and if you need to access the symbol keys, you'll have to use <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/getOwnPropertySymbols" target="_blank" rel="norefferer noopener">`getOwnPropertySymbols()`<span className="hidden"> (Opens in a new tab)</span></a>.

...

And that's it! I don't see myself using this approach anytime soon, but it's good to know that, should I be concerned with the integrity of the data I work with, there are ways for me to preserve some information in the flimsy world that JavaScript often creates for us.


JavaScript symbols are a unique and immutable data type that can be used as object property keys to prevent external code to unexpectedly modify properties. That's it, but if it doesn't yet make sense to you, reading the article might actually help.

Javascript Symbols

Custom

JavaScript

ELI5

JavaScript Symbols

<a href="https://www.freepik.com/free-psd/concept-mobile-application-cloud-services-male-character-sits-big-cloud-sign-with-phone-3d-illustration_26314276.htm" target="_blank" rel="noreferrer noopener">Concept mobile application and cloud services character<span class="hidden"> (Opens in a new tab)</span></a> by <a href="https://www.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-vector/realistic-white-monochrome-background_16223330.htm" target="_blank" rel="noreferrer noopener">Realistic white monochrome background<span class="hidden"> (Opens in a new tab)</span></a> by <a href="https://www.freepik.com" target="_blank" rel="noreferrer noopener">Freepik<span class="hidden"> (Opens in a new tab)</span></a>

Typescript

Sometimes I wonder whether I love or hate Typescript. I see the benefits of implementing it in the majority of frontend solutions, but I struggle with the syntax and the mumbo jumbo names that don't tell me anything. "Generics" would be one of those, as the name kindly suggests too, it's a name that could mean anything 🤷 When I find myself in the situation where I think I have grasped something but I haven't quite, the best solution is to try to write something about it to bring in clarity!

## So what are Generics?

Generics in TypeScript provide a way to create reusable data structures (arrays, stacks, queues, linked lists etc.), components and functions that can work with different data types.

Take for example:

```typescript
interface Dictionary<T> {
  [key: string]: T;
}
````

With generics you can create a container type that can hold different types of values based on needs, e.g.:

```typescript
const myDictionary: Dictionary<number> = {
  age: 30,
  height: 180,
};

const myOtherDictionary: Dictionary<string> = {
  name: 'John',
  city: 'New York',
};
```

This is useful when you want to create a flexible and type-safe container, such as a dictionary or a set. You'll be guaranteed, whether the structure will accommodate strings or numbers, that it will follow the interface `Dictionary` and expect an object with keys whose value will reflect the data you use it with.

Let's make another practical example; let's say you want to have a function that allows you to print whatever type of array in a particular format, like an ordered list. In this case, the type of the data passed is not relevant to you, you only care that it's presented in an ordered list.

```typescript
function printArray<T>(array: T[]): string {
  const items: string = array.map(item => `<li>${item}</li>`).join('');
  return `<ol>${items}</ol>`;
}
```

Now you can use this function to format the arrays before appending them to a div:

```typescript
function printArray<T>(array: T[]): string {
  const items: string = array.map(item => `<li>${item}</li>`).join('');
  return `<ol>${items}</ol>`;
}

// An example function to append HTML content to a div element
function appendToDiv(containerId: string, content: string): void {
  const container = document.getElementById(containerId);
  if (container) {
    container.innerHTML = content;
  }
}

// Our data types
const numbers: number[] = [1, 2, 3, 4, 5];
const strings: string[] = ['apple', 'banana', 'orange'];

// Our data types formatted through the printArray function
const numbersListHTML: string = printArray(numbers);
const stringsListHTML: string = printArray(strings);

// Append the lists to an hypotetical div container that shows the list
appendToDiv('orderedLists', numbersListHTML);
appendToDiv('orderedLists', stringsListHTML);
```

In the example, `printArray` doesn't care whether the array inputted is a numeric or a string one, but it makes sure to guarantee type safety based on the data type you pass to it.

Not bad, right?

<hr/>

## What is a somewhat more practical application of generics in the real-life coding world?

Generics can be useful when working with promises and asynchronous operations, allowing you to specify the type of the resolved value.

```typescript
// Function that returns a promise to fetch data from an API
function fetchData<T>(url: string): Promise<T> {
  return fetch(url)
    .then(response => {
      if (!response.ok) {
        throw new Error('Network response was not ok');
      }
      return response.json() as Promise<T>;
    })
    .catch(error => {
      console.error('Error fetching data:', error);
      throw error;
    });
}

// Usage
interface UserData {
  id: number;
  name: string;
  email: string;
}

const apiUrl = 'https://api.example.com/users/1';

fetchData<UserData>(apiUrl)
  .then(data => {
    // Here, 'data' will be of type UserData
    console.log('User Data:', data);
  })
  .catch(error => {
    console.error('Error fetching user data:', error);
  });
```

While this example is not perfect, it offers us a great way to dynamically query for various URLs, and for each case we have the possibility to provide the type we expect to receive: we query for `https://api.example.com/users/1` - we expect to receive a response containing user information - so we provide the interface `UserData` to the function `fetchData<UserData>(apiUrl)` and if the request doesn't fail, our response will be already using the correct interface. Neat!

<hr />

## Challenges with Generics

Not all that shines is gold, and the same can be said about generics. While they offer this great versatility, you can imagine they also provide a lot of complexity to a codebase, as they will require developers to pay better attention to the data flow and make sure that things won't go as unexpected.

Together with the broader learning curve proposed to developers, there are also various limitations of type inferring that might make generics limiting to a practical application. No idea about those limits, will let you know when I stumble on those :D 

## Long story short

<mark>If you use them, make sure it makes sense on why you're using them and that they actually bring benefits on what you're doing.</mark> If you're working on a npm package that needs to accommodate different solutions (idk, a table with columns that can sort according to the data type provided, where you might not know ahead of time what values will be entered), generics might be very well what you're looking for! Bear in mind however, that they will always create an extra layer of complexity that you need to account for your code and for all your team mates!

Let's figure out together what do we do with all those weird Ts in Typescript :D Believe it or not, they can let you work with different data types in a safe and reusable way, so you can build cool stuff with confidence!

Generics in TypeScript and how to use them

Generics in Typescript and how to use them

<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

Performance optimization with useMemo

React

<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! 

oh-no.ooo

JavaScript

Articles

JavaScript Symbols

Generics in Typescript and how to use them

Performance optimization with useMemo

Common useEffect mistakes