<a href="https://www.freepik.com/free-ai-image/view-3d-young-school-student_133758575.htm" target="_blank" rel="noreferrer noopener">3d young school student (Opens in a new tab)</a> by <a href="https://freepik.com" target="_blank" rel="noreferrer noopener">Freepik (Opens in a new tab)</a>, <a href="https://www.freepik.com/free-vector/flat-abstract-wireframe-background_16133537.htm" target="_blank" rel="noreferrer noopener">Flat abstract wireframe background (Opens in a new tab)</a> by <a href="https://freepik.com" target="_blank" rel="noreferrer noopener">Freepik (Opens in a new tab)</a>, Tailwind logotype from <a href="https://tailwindcss.com/brand" target="_blank" rel="noreferrer noopener">Tailwind Official Brand page (Opens in a new tab)</a>, semi-random coding text generated with <a href="https://carbon.now.sh" target="_blank" rel="noreferrer noopener">Carbon (Opens in a new tab)</a>

Tailwind Level up

Level up your Tailwind game

Custom

Tailwind

UI/UX

<a href="https://www.freepik.com/free-psd/3d-rendering-graphic-design_31283887.htm" target="_blank" rel="noreferrer noopener">3D rendering of graphic design (Opens in a new tab)</a> by <a href="https://www.freepik.com/author/freepik" target="_blank" rel="noreferrer noopener">Freepik (Opens in a new tab)</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 (Opens in a new tab)</a> by <a href="https://www.freepik.com/author/rawpixel-com" target="_blank" rel="noreferrer noopener">rawpixel.com (Opens in a new tab)</a> via <a href="https://freepik.com" target="_blank" rel="noreferrer noopener">Freepik (Opens in a new tab)</a>, blurred code image created with <a href="https://carbon.now.sh" target="_blank" rel="noreferrer noopener">Carbon (Opens in a new tab)</a>, Next.js logo from <a href="https://nextjs.org" target="_blank" rel="noreferrer noopener">Next.js official website (Opens in a new tab)</a>, Disqus logo from <a href="https://disqus.com/brand/" target="_blank" rel="noreferrer noopener">Disqus Brand and Logos official material (Opens in a new tab)</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 (Opens in a new tab)</a>, I've been mentioning my issue with setting up my <a href="https://nextjs.org" target="_blank" rel="noreferrer noopener">Next.js (Opens in a new tab)</a> site combined with <a href="https://www.npmjs.com/package/next-themes" target="_blank" rel="noreferrer noopener">next-themes (Opens in a new tab)</a> and <a href="https://disqus.com/" target="_blank" rel="noreferrer noopener">Disqus (Opens in a new tab)</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 (Opens in a new tab)</a> written by <a href="https://dev.to/luisca" target="_blank" rel="noreferrer noopener">Luis Cadillo (Opens in a new tab)</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 (Opens in a new tab)</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>
Light vs. dark color scheme 
A light or dark color scheme is automatically selected based on your site's stylesheets.
 
 
How is the color scheme determined? 
<ul>
 <li>The light scheme is loaded when the text color Disqus inherits from your site has >= 50% gray contrast: between color: #000000; and color: #787878;</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 (Opens in a new tab)</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 (Opens in a new tab)</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 (Opens in a new tab)</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 (Opens in a new tab)</a> where <a href="https://stackoverflow.com/users/10312920/ken-mueller" target="_blank" rel="noreferrer noopener">Ken Mueller (Opens in a new tab)</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 (Opens in a new tab)</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 (Opens in a new tab)</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

React

Next.js

Disqus

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

<a href="https://www.freepik.com/free-psd/gaming-blank-banner-background_41972388.htm" target="_blank" rel="noreferrer noopener">Monitor, keyboard and mouse (Opens in a new tab)</a>, <a href="https://www.freepik.com/free-vector/realistic-3d-shapes-floating-background_13397766.htm" target="_blank" rel="noreferrer noopener">Background 3D composition (Opens in a new tab)</a> by [Freepik](https://www.freepik.com/author/freepik); Blurred <a href="https://unsplash.com/photos/rCbdp8VCYhQ" target="_blank" rel="noreferrer noopener">starry sky (Opens in a new tab)</a> by <a href="https://unsplash.com/@andyjh07" target="_blank" rel="noreferrer noopener">Andy Holmes (Opens in a new tab)</a> via <a href="https://unsplash.com/" target="_blank" rel="noreferrer noopener">Unsplash (Opens in a new tab)<a/>

Blaugust 2023

New to blogging? Veteran of long time content creation? Looking for inspiration on what to write, vlog or stream about? __Blaugust__ has something for you no matter what!

As of now, I've only written a few posts here and there (taking quite some time to rewrite them into something presentable) and I find myself struggling with some consistency in publishing the things I learn about. 

Work, sometimes, gets the best of me and well, life is there too! 😱😆 This is not my first attempt at working on my own website and try to collect a nice bunch of material to showcase when I apply to new workplaces, __but it's possibly the latest best effort that brought a lot of joy into my life and redeemed a lot of love that I have for my own profession__, which before anything has been my favourite hobby ever since I was 10. 🥰

When working on something that is only for me and not for anyone else, events like Blaugust speak to me as a great incentive into pushing myself and try to create something-anything, even when the day seems a bit too short for anything productive.

## So, what is Blaugust exactly?

Without any attempt to write it better than the creator of the event

<blockquote>
 Blaugust is a month-long event that takes place in August each year that focused on blogging and other serialized content. The goal is to stoke the fires of creativity and allow bloggers and other content creators to mingle in a shared community while pushing each other to post more regularly.
 <div class="text-right"></div>— <a href="https://aggronaut.com/2023/07/12/blaugust-2023-is-coming/" target="_blank" rel="noreferrer noopener">Blaugust 2023 is coming (Opens in a new tab)</a> by <a href="https://aggronaut.com/author/belghast/" target="_blank" rel="noreferrer noopener">Belghast (Opens in a new tab)</a>
 </blockquote>

And the beautiful sharing community is something you don't want to miss out! So far I have had such a great time on Discord chatting with a lot of people and seeing what is everyone up to. 😎

I really invite anyone even-so-remotely-interested in joining this event and <a href="https://aggronaut.com/2023/07/12/blaugust-2023-is-coming/" target="_blank" rel="noreferrer noopener">read more about Blaugust from the original post (Opens in a new tab)</a>. You even get an achievement by reading the manual, yay xD

<hr />

## Shoutout to Juhis 🎉

It's thanks to <a href="https://hamatti.org/about/" target="_blank" rel="noreferrer noopener">Juhis (Juha-Matti Santala, hamatti.org) (Opens in a new tab)</a> that I find myself in this amazing community!

Juhis has always been involved in a lot of amazing activities and this is one of the greatest ones I'm also trying to be part of! Ever since I met him in our previous common workplace, __Juhis has always been a great inspiration as a developer, community manager, event organizer, workshop host and speaker__! *When I grow up I wanna be like Juhis* (even if I'm older, technical details 😆) A lot of the things I have confidence in doing today are thanks to him, and I'm glad I can always learn from this amazing person! Thank you so much! 🌻

Oh, and don't forget to check <a href="https://hamatti.org/posts/blaugust-2023-here-we-come/" target="_blank" rel="noreferrer noopener">Juhis' article about Blaugust (Opens in a new tab)</a>!

## Get to know more about this year's participants!

One of the kindest souls in the community, <a href="https://indiecator.org/about-indiecator/" target="_blank" rel="noreferrer noopener">Magi (Opens in a new tab)</a>, recently published <a href="https://indiecator.org/2023/08/02/blaugust-2023-participant-appreciation-post/" target="_blank" rel="noreferrer noopener">an appreciation blog post about all the participants of this year's Blaugust (Opens in a new tab)</a>. Their post is incredibly heartwarming and I appreciate a lot the kind words they've addressed toward my Notion blogpost! 😍

<hr />

## The goal

While I don't believe I have it in me to create 31 posts in 31 days (and I'd already be long behind by now 😱), I'm giving myself an approachable deadline of *at least one post per week* and have four new posts in this site by the end of August. Seems reasonable and should combine pretty well with my work! I'll also figure out how many achievements I've gotten from the challenge once the month is out!

## My biggest learning so far

Although the event just started, I've already discovered something interesting about myself!

For some reason, I've never thought about browsing posts about my favourite videogames, and amazingly enough, it was really refreshing to read more about Path of Exile instead of simply watching YouTube videos as I'd always do. I see that a lot of amazing content goes under the radar when I limit myself to only one input approach and it reminds me that there's far more than mindless Instagram scrolling that I could do to spend my time!

And it's kinda weird, I am okay both reading and watching videos about development, but for some reason I've never thought that reading about video games was also a possibility! LOL. 🤯

## So far so good!

Although I might not have written or rewritten-and-published as many articles as I was hoping to during this week, __I've managed to come up with a somewhat okay dark theme for this website__! I've felt so accomplished as it was something I had in my backlog for a long long time! ✨ __It also put me against some small challenges with Disqus embeds__, for which I'm going soon to write an article about — thinking of sharing it also on <a href="https://dev.to" target="_blank" rel="noreferrer noopener">dev.to (Opens in a new tab)</a> to contribute to its amazing community :D Yay, me!

Having a hard time finding will to work on your blogging website? Blaugust might just be that little spice of inspiration you were looking for!

A Blasting August with Blagust

Inspiration

Productivity

A Blasting August with Blaugust

<a href="https://www.freepik.com/free-vector/gradient-liquid-abstract-background_13346239.htm" target="_blank" rel="noreferrer noopener">Vector Liquid Background (Opens in a new tab)</a> by <a href="https://www.freepik.com/author/pikisuperstar" target="_blank" rel="noreferrer noopener">pikistar (Opens in a new tab)</a> via <a href="https://freepik.com" target="_blank" rel="noreferrer noopener">Freepik (Opens in a new tab)</a>, <a href="https://www.freepik.com/free-psd/3d-illustration-people-working-marketing_42937458.htm" target="_blank" rel="noreferrer noopener">People working marketing (Opens in a new tab)</a> by <a href="https://freepik.com" target="_blank" rel="noreferrer noopener">Freepik (Opens in a new tab)</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 (Opens in a new tab)</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 (Opens in a new tab)</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 (Opens in a new tab)</a>, and I will not try to rewrite it when he's already told it better than I ever can!

<blockquote>
In programming, memoization is an optimization technique 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.
 
In simpler words, it consists of storing in cache the output of a function, and making the function check if each required computation is in the cache before computing it.
 
 <div class="text-right">— <a href="https://www.freecodecamp.org/news/author/gercocca/" target="_blank" rel="noreferrer noopener">Germán Cocca (Opens in a new tab)</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 (Opens in a new tab)</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 (Opens in a new tab)</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? (Opens in a new tab)</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 (Opens in a new tab)</a>, <a href="https://twitter.com/RozenMD" target="_blank" rel="noreferrer noopener">Max Rozen (Opens in a new tab)</a> puts it up in simple words:

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

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

 <div class="text-right">— <a href="https://effectiviology.com/itamar-shatz/" target="_blank" rel="noreferrer noopener">Dr. Itamar Shatz (Opens in a new tab)</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 (Opens in a new tab)</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 (Opens in a new tab)</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 (Opens in a new tab)</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 (Opens in a new tab)</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

JavaScript

<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 (Opens in a new tab)</a> by <a href="https://www.freepik.com" target="_blank" rel="noreferrer noopener">Freepik (Opens in a new tab)</a>, <a href="https://www.freepik.com/free-vector/realistic-white-monochrome-background_16223330.htm" target="_blank" rel="noreferrer noopener">Realistic white monochrome background (Opens in a new tab)</a> by <a href="https://www.freepik.com" target="_blank" rel="noreferrer noopener">Freepik (Opens in a new tab)</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 (=== if you have `Dictionary<string>` the values of the keys can only be `string`, if you have `Dictionary<number>` the values of the keys can only be `number`).

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

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. __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

ELI5

Generics in Typescript and how to use them

<a href="https://www.freepik.com/free-psd/3d-female-character-reading-book_13678507.htm" target="_blank" rel="noreferrer noopener">Person sitting on books (Opens in a new tab)</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 (Opens in a new tab)</a> by <a href="https://www.freepik.com/author/freepik" target="_blank" rel="noreferrer noopener">Freepik (Opens in a new tab)</a>, <a href="https://www.freepik.com/free-psd/website-coding-icon-3d-illustration_28638422.htm" target="_blank" rel="noreferrer noopener">Cute round interface (Opens in a new tab)</a> by <a href="https://www.freepik.com/author/ekayasadesign" target="_blank" rel="noreferrer noopener">Ekayasa.Design (Opens in a new tab)</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 (Opens in a new tab)</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()` (Opens in a new tab)</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()` (Opens in a new tab)</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()` (Opens in a new tab)</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.

oh-no.ooo

What you can find here

Latest Article

Level up your Tailwind game

More Articles

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

A Blasting August with Blaugust

Performance optimization with useMemo

Generics in Typescript and how to use them

JavaScript Symbols