Forem: Lucy Love

Javascript Symbols

Lucy Love — Thu, 13 Jun 2024 06:24:30 +0000

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 JavaScript primitive data types 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.

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:

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:

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:

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

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

person.id = 00000000;

You will be left with

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 keys() nor with getOwnPropertyNames()!

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 getOwnPropertySymbols().

...

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.

Sources and inspiration

ChatGPT prompt: Act like a senior software developer mentor. Explain to me in the simplest way possible what javascript Symbols are, making very basic examples that DO NOT use "foo" "bar" words. Make small sentences and ask me often if I am able to understand. Thank you.
Symbol from mdn web docs
JavaScript Symbols from Flavio copes
Cover: Person sitting on books and Background 3d composition by Freepik, Cute round interface by Ekayasa.Design Originally posted in oh-no.ooo (JavaScript Symbols), my personal website.

An Introduction to Quantum Computing

Lucy Love — Tue, 11 Jun 2024 11:41:49 +0000

Quantum computing here, quantum computing there, quantum computing everywhere! Can we make some sense out of it? I'd like to not feel like completely out of place when people talk about it, so let's figure it out together!

I start this serie of posts about Quantum computing for personal learning, with the sake of understanding the general implications of it in our modern society and how it can impact my day-to-day life with technology. I do not claim to be an expert in the topic and this are more my notes based on what I'm learning reading articles and asking ChatGPT to simplify what I'm reading :D

Quantum computing is a revolutionary new technology that harnesses the principles of quantum mechanics (an intricate branch of physics that explores the wonders of the subatomic realm and tries to explain the nature of particles to discover the fundamental principles that govern our world -- we're not here today for this though) to process information at incredible speeds.

Unlike classical computers, which store and process information using bits that are either 0 or 1, quantum computers use quantum bits, or qubits, which can exist in multiple states simultaneously, meaning that a qubit can be both 0 and 1. ...but how?

Representation of a qubit compared to a typical bit.
Source: Devopedia. Credit: Volkswagen Aktiengesellschaft 2019.

Superposition

Let's talk about the idea of superposition, which describes the ability of a qubit to exist in multiple states at the same time. If a normal bit can have as a state either 0 or 1, the state of qubit can be represented as

|ψ⟩ = α|0⟩ + β|1⟩

which would require quite some explantation, but to make it briefly:

The symbol |ψ⟩ represents the state of the qubit. ψ is just a variable name, and the |⟩ symbols are like brackets that indicate it's a quantum state.
The α|0⟩ and β|1⟩ terms are probability amplitudes. They represent the chances of finding the qubit in the states |0⟩ and |1⟩
α represents the probability amplitude of finding the qubit in the |0⟩ state;
β represents the probability amplitude of finding the qubit in the |1⟩ state.

(... and yes because I also had to ask myself, probability amplitudes are quite complex numbers, but the gist of them is that the sum of α and β adds up to 1, meaning that the sum of the probabilities of all possible outcomes is always equal to 1.)

We can picture the state of a qubit like a point on a ball, called the Bloch sphere. The numbers α and β decide where exactly on the ball the qubit's point is. If α and β are regular numbers, then the qubit's point is on the middle of the ball's surface, like the equator. This means the qubit is equally a mix of |0⟩ and |1⟩. But if α and β are complex numbers (read more about complex numbers on Math Is Fun), the qubit's point is somewhere else on the ball's surface. This means the qubit is a more general mix of |0⟩ and |1⟩.

When a qubit is in superposition, it is like it's exploring all possible states at once. However, when we measure the qubit, it collapses into a definite state, either 0 or 1. The act of measurement forces the qubit to choose one of the possibilities, and from that point on, it behaves like a classical bit.

For instance, if |α|^2 = 0.4 and |β|^2 = 0.6, the measurement is more likely to yield the outcome 1, but there is still a chance of obtaining the outcome 0.

Okay but... how do you set a qubit in superposition?

In order to do that, we can use a specific quantum gate known as the Hadamard gate (H gate) (more about what is a quantum gate later :D). The Hadamard gate creates an equal superposition of the |0⟩ and |1⟩ states for a qubit. Here's a simplified explanation of how it works:

Start with a qubit in the |0⟩ state or the |1⟩ state
Apply the Hadamard gate (H gate) to the qubit
If the qubit is initially in the |0⟩ state, the H gate will put it into an equal superposition of |0⟩ and |1⟩. The resulting state will be (|0⟩ + |1⟩) / √2, meaning the qubit is in both states simultaneously
But, if the qubit is initially in the |1⟩ state, the H gate will again put it into an equal superposition of |0⟩ and |1⟩ but the resulting state will be (|0⟩ - |1⟩) / √2, meaning the qubit is in both states but with a phase shift (which is a far more intricate topic and I am still looking to find good and simple readings about it -- feel free to share in the comment section below!).

Reading the values of multiple qubits works similarly, with each qubit measured individually, and the outcomes combined to form a classical bit string or a quantum state in the case of entanglement. Which leads us to the next point...

Entanglement

Another important concept in quantum computing is entanglement, which describes the phenomenon of two or more qubits being connected in a way that allows them to affect each other's behavior, even if they are separated by large distances. Fundamentally, entanglement creates instantaneous correlations between their measurement outcomes, taking place in three stages:

Preparation: two or more qubits are brought together and interact with each other in a specific way through a quantum gate operation (too long of a topic to cover here for now, but Universal Quantum has a great article on Medium about quantum gates).
Resulting State: as a result of this interaction, the qubits become entangled and share a joint quantum state, which cannot be expressed as a simple combination of individual qubit states as the entangled state encompasses the entire system as a whole rather than describing each qubit independently.
Correlations: the measurement outcomes of one qubit are instantaneously correlated with the measurement outcomes of the other(s). These correlations hold true regardless of the physical separation between the entangled qubits, which is often referred to as non-locality or spooky action at a distance (once again, a topic for another time).

Briefly about Quantum gates

This is where I start to lose it a bit after the Hadamard gate we mentioned before. Sounds like a good place where I should continue reading more until I am confident enough to write notes about the topic 😎 Anyway...

A quantum gate is an instruction (or operation) that we can use to change the state of qubits. Just like how math operations such as addition or multiplication transforms numbers, a quantum gate transforms the quantum state of qubits, each gate having a specific effect on the qubits: rotating the state, flipping it, or putting it in a superposition and whatsoever.

Basically, they are the building blocks that help us manipulate and utilize the power of quantum computing. Once again, Universal Quantum has a great article on Medium about quantum gates and I recommend checking something more by yourself (and if you feel generous, don't be afraid to share some good links with me :D)

Briefly about Challenges

Seems fair to mention, before closing, why this technology is not yet widespread and what are the things that it needs to overcome.

One of the major challenges in building a quantum computer is the delicate nature of qubits. Because they are based on the principles of quantum mechanics, qubits are easily affected by their environment, and can be easily disrupted by outside factors such as temperature, noise, or even light. This makes it difficult to control and manipulate qubits, and to maintain their quantum state for long periods of time.

Despite these challenges, researchers have made significant progress in developing quantum computers in recent years. In 2019, Google announced that its quantum computer had achieved "quantum supremacy" by solving a problem that would be impossible for a classical computer to solve in a reasonable amount of time. This was a major milestone in the development of quantum computing, and showed that the technology is rapidly advancing.

Conclusions

So, what did we learn here?

We've learned about qubits, which unlike the binary bits in classical computing, can exist in multiple states at once due to superposition.
We've also discovered that a specific quantum gate, the Hadamard gate, can set a qubit in this superposition state.
Furthermore, qubits can be entangled, meaning they can affect each other instantaneously irrespective of the distance between them.
Lastly, we've had a general discussion about quantum gates, the operations that manipulate the state of qubits, serving as the foundational building blocks of quantum computing.

What next?

I'd love to continue my studies focusing more on:

(First of all, brushing up my linear algebra, because it seems to help a lot reading documents online)
Quantum gates
Quantum algorithms
Quantum error correction
More about quantum supremacy
More about challenges

Thank you for reading so far, if you did, and don't hesitate sharing good resources in the comments below if you feel like!

Sources and inspiration

Qubit from Devopedia
Quantum Computing for the Very Curious from Andy Matuschak and Michael Nielsen on Quantum Country
Quantum computing, Quantum superposition & Quantum entanglement from Wikipedia
Quantum Supremacy Using a Programmable Superconducting Processor from John Martinis (Chief Scientist Quantum Hardware) and Sergio Boixo( Chief Scientist Quantum Computing Theory) at Google AI Quantum via Google Research
Quantum Computing Expert Explains One Concept in 5 Levels of Difficulty with Dr. Talia Gershon (Senior Manager, Quantum Research at IBM) from Wired
ChatGPT prompts: How can a quantum bit be both 0 and 1 at the same time? Can you give me an accurate yet simple description to follow? How do we read the values of qubits? Can you explain to me in simple terms what is qubits entanglement, how does it happen, and what does it imply? Can you tell me more about the correlation in entanglement? Can you explain to me in simple terms what is qubits entanglement, how does it happen, and what does it imply?Can you tell me more about the resulting state of entanglement? ... and honestly too many more to share xD
Cover: 3d characters business fall illustration, 3D Atom and Background 3D composition by Freepik; Blurred starry sky by Andy Holmes via Unsplash Originally posted in oh-no.ooo (An Introduction to Quantum Computing), my personal website.

Generics in Typescript and how to use them

Lucy Love — Mon, 10 Jun 2024 20:13:24 +0000

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:

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

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.

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:

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?

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.

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

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!

Sources and inspiration

Various prompts from ChatGPT
TypeScript Generics Documentation
How to use Generics in TypeScript by Jonathan Cardoso via Digital Ocean
Cover: Concept mobile application and cloud services character by Freepik, Realistic white monochrome background by Freepik Originally posted in oh-no.ooo (Generics in Typescript and how to use them), my personal website.

declare-ai.org - ... so, who wrote that?!

Lucy Love — Mon, 10 Jun 2024 11:45:58 +0000

One of the latest interesting discussions on Slack at work has been about the value proposition of declare-ai.org, a website created (without any assistance from a Generative AI) by David Bryant Copeland that recognises the excitement around AI and wants to help people inform and be informed about its uses.

(bit off topic but, I am perplexed by the fact that David's own website doesn't have any comment about AI Content Declaration; perhaps they felt they had said all about the topic in the main website. Or perhaps they just wanted to make sure it is clear to people that their work has nothing to do with any sort of AI, maybe out of frustration for the new wave of low-quality/low-effort content blatantly created with AI and not wanting their work even remotely put on the same plate)🤷.

While I recommend checking the website (as I couldn't write any better about it than you could deduct from checking the actual site), the process it proposes is as follows:

Flow proposed by AI Content Declaration on how to determine what type of Generative AI attribution you need for your content. Diagram generated with Venngage.

Not sure if the diagram can be read in an accessible way, therefore let me repeat it here (I will use a structure that proposes first the condition that end the flow). We start asking ourselves Was Generative AI used in any way?; if the answer is no, then the answer is None (as in no contribution from generative AI). If the answer is yes, we are prompted to another question Did Generative AI produce the entire work?; answering yes will land us on Total, as in total AI contribution; if we answer no, we are asked the last question Did Generative AI contribute creatively?; yes brings us to Creative Assistance and no will bring us to Non-creative Assistance.

It is up to your own judgement to determine if you used the AI in a creative way, but the website offers you a nice way to determine what could be considered creative assistance and what not.

And once you go through this hierarchy, you can make a public declaration about it, in the best way that suits you and with the examples proposed. It allegedly also proposes to add this information in the form of meta tags... because why not?!

Now now, will I use it? Not yet! I would like to see it having more popularity; but what I like to do is to be open about the source of my work! And that's why I gladly mention at least the most important prompts I ask about to ChatGPT at the end of each article. My go-to way to use ChatGPT is to get inspiration on how to start discussing about a topic, steal good-sounding adjectives (as my English can only benefit from expanding my vocabulary), and in general to get over a writer's block that often prevents me from sharing more, and learn more about something.

More than often, I read what ChatGPT proposes to me, and I'm immediately like nope, definitely not that! as it often goes with a very bland structure, lots of repetition, and unneeded conclusion paragraphs that give no particular value to the topic asked. But more than once, when I want to make sure I understand something about a particular topic, it performs as a great teacher that never gets tired, no matter how stupider my questions become. And it's really a teacher that I'd wish for everyone to have.

Many feel ashamed to mention they'd use any sort of generative AI and they'd prefer to keep it hidden. Instead of having a sense of appreciation for this technology, a lot of people tend to judge negatively the skills of people using AI, assuming that they're lazy, not knowledgeable, not actual professionals and that they'd not be able to succeed without such tool. I personally find unfair to question people's skills' worth based on how much they like to use AI, as I don't think my critical thinking is compromised any more than it'd be if I were to acquire information from a YouTube video, an online article, a book and so on. With that premise, I use ChatGPT as one among many sources to acquire knowledge and understanding of a topic, and it never is for me the only source of information.

Rather than hide its usage, I absolutely love the idea to share with people how it helps me go past a lot of hurdles. Before ChatGPT, I also have never been particularly shy about sharing where I've learned something, or what sources I have browsed to learn and/or do something. I really love to share with people because I would not be the person that I am today if people didn't share the things I've digested to this day.

We seem to forget that not too long ago, we were all assuming developers were just copying stuff from StackOverflow and asking questions over there. So how does that exactly differ, in terms of originality and competence, from what ChatGPT offers us these days?

Have you ever wondered how many people make use of ChatGPT for writing their blog posts? What's your take on the topic? Should people be more clear to which extend they use AI or would you just be happy to have valuable content in front of your eyes, regardless of how it came to be? Let me hear your opinion in the comments!

Sources and inspiration

Declare-AI official website
The aforementioned discussion on Slack at work
Cover: Title and background gradient tweaked out with the DOM Inspector from Declare-AI official website Originally posted in oh-no.ooo (declare-ai.org - ... so, who wrote that?!), my personal website.

Solving Tailwind's "Unknown at rule @apply"

Lucy Love — Sun, 09 Jun 2024 20:33:11 +0000

Chances are you are using VSCode, and chances are you're also using Tailwind in one of your projects. Chances are that at my first chances are... you went immediately nuh-uh and moved on (and if you're a NeoVim user I can't help you anyway, you're already doomed and lost in the recommended plugins someone chose for you and you're probably still figuring out half of them) but if I got your attention with the first two assumptions, then this post might be relevant for you!

One issue I've been having ever since using Tailwind with SCSS modules has been that VSCode goes absolutely ballistic marking every @apply as an unknown CSS rule, as the editor assumes it's one at-rule from CSS. (If you are wondering what at-rules are, @import and @media might sound a bit more familiar :D)

@apply is a Tailwind directive that mimics in semantics a native CSS at-rule, and this one in the specific takes care of enabling Tailwind utility classes in a .scss file ... which by now we already now — I know, we wouldn't be reading this article otherwise — so jumping to the main thing, let me present you my favourite solution from the solutions list that this article from byby.dev proposes.

Open the .vscode folder in your project, create a tailwind_directives.json file and add the following lines. I took the liberty of expanding from the article, which was talking specifically about the @tailwind directive, and take it as a chance to put all the Tailwind specific directives I could find from Tailwind's documentation:

{
    "version": 1.0,
    "atDirectives": [
        {
            "name": "@tailwind",
            "description": "Use the @tailwind directive to insert Tailwind's `base`, `components`, `utilities`, and `screens` styles into your CSS."
        },
        {
            "name": "@apply",
            "description": "Use @apply to inline any existing utility classes into your own custom CSS."
        },
        {
            "name": "@screen",
            "description": "The screen function allows you to create media queries that reference your breakpoints by name instead of duplicating their values in your own CSS. Apparently deprecated in favour of @media?!"
        },
        {
            "name": "@layer",
            "description": "Use the @layer directive to tell Tailwind which “bucket” a set of custom styles belong to. Valid layers are base, components, and utilities."
        },
        {
            "name": "@config",
            "description": "Use the @config directive to specify which config file Tailwind should use when compiling that CSS file. Do not put @config before your @import statements."
        }
    ]
}

Then, head to settings.json and add these two lines:

{
// ... other stuff
  "css.customData": [".vscode/tailwind_fix.json"],
  "scss.customData": [".vscode/tailwind_fix.json"]
}

And voilá! Done!

...
Now now, you might be tempted to follow the first solution proposed by the article, which simply tells VSCode to ignore every at-rule it cannot recognise:

{
// Warning: Sub-optimal approach
// Please follow the previous advice!
// ... other stuff
  "css.lint.unknownAtRules": "ignore"
  "scss.lint.unknownAtRules": "ignore"
}

But! What about typos? We all make them, and I wouldn't trust myself writing things correctly any day :'D Better be more specific and let pass only the things we are aware of!

Sources and inspiration

How to fix the unknown at rule @tailwind warning by byby.dev
Tailwind's Functions & Directives documentation
Cover: Tailwind logotype from Tailwind Official Brand page, 3d abstract background with paper cut flower shape by GarryKillian via Freepik Originally posted in oh-no.ooo (Unknown at rule @apply... k thx bye!), my personal website.

Performance optimization with useMemo

Lucy Love — Sun, 09 Jun 2024 17:08:15 +0000

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 useMemo hook. 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?!

Germán Cocca makes a great job at explaining this concept in his article about Memoization in Javascript and React, and I will not try to rewrite it when he's already told it better than I ever can!

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.

— Germán Cocca in What is Memoization? How and When to Memoize in JavaScript and React

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

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:

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.

Note:
React useHook official documentation has a section How to tell if a calculation is expensive? where it teaches us to use the console by adopting console.time() and console.timeEnd() to better determine the cost of our operations.

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.

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 Understand when to use useMemo, Max Rozen puts it up in simple words:

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.
— Max Rozen in Understand when to use useMemo

"Premature optimization is the root of all evil"

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.

Calling premature optimization the root of all evil seems to be something rather common, and Dr. Itamar Shatz in his article about Premature Optimization: Why It’s the “Root of All Evil” and How to Avoid It says that

Premature optimization involves trying to improve something — especially with the goal of perfecting it — when it’s too early to do so.
— Dr. Itamar Shatz in Premature Optimization: Why It’s the “Root of All Evil” and How to Avoid It

His article also shows that the famous Premature optimization is the root of all evil sentence is a quote from the computer scientist Donald Knuth, from his article Structured Programming with go to Statements. 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 dangers of premature optimization in a few yet impactful points, which I recommend reading from his article.

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:

// 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:

// 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:

// 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 on my 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

Sources and inspiration

Official React useHook documentation
ChatGPT prompt: Can you help me write a good article on the What, Why and How of using useMemo hook?
W3School documentation on useMemo
What is Memoization? How and When to Memoize in JavaScript and React by Germán Cocca from freeCodeCamp
Understand when to use useMemo by Max Rozen
Premature Optimization: Why It’s the “Root of All Evil” and How to Avoid It by Dr. Itamar Shatz
Cover: Vector Liquid Background by pikistar via Freepik, People working marketing by Freepik Originally posted in oh-no.ooo (Performance optimization with useMemo), my personal website.

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

Lucy Love — Sat, 08 Jun 2024 09:19:07 +0000

In my last year's post about the amazing Blaugust event, I've been mentioning my issue with setting up my Next.js site combined with next-themes and Disqus 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 Step-By-Step Guide to Adding Dark Mode and Multiple Themes to Your Next.js App written by Luis Cadillo (thank you pal!), I found myself with a neat Dark mode but my Disqus embed (installed through disqus-react npm package) would not update its theme properly, despite its theme settings being on Auto.

Buggy Disqus theme change at the bottom of my articles

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

Disqus settings for automatic detection of the color scheme.

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:

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?

The light scheme is loaded when the text color Disqus inherits from your site has >= 50% gray contrast: between color: #000000; and color: #787878;

The dark scheme is loaded in all other instances.

— Disqus Appearance Customization

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 StackOverflow, I found my very same problem but no answer to it: Disqus theme not matching background when changing blog theme from dark to light. 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, Disqus comments Dark mode renders with white background where Ken Mueller mentions to "Remove the <meta name="color-scheme" content="dark" /> 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 lang="en" class="dark" style="color-scheme: dark;">

My Chrome inspector showing that the HTML tag in my website had this extra style="color-scheme: dark;" property.

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 next-themes documentation, 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.

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 disqus-react 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:

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!

My website Disqus section adapting to both dark and light color schemes. Yay!

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!

Sources and inspiration

Step-By-Step Guide to Adding Dark Mode and Multiple Themes to Your Next.js App by Luis Cadillo
next-themes npm package
disqus-react npm package
Disqus theme not matching background when changing blog theme from dark to light from StackOverflow
Disqus comments Dark mode renders with white background from StackOverflow
Cover: 3D rendering of graphic design by Freepik, Vector geometric background by rawpixel.com via Freepik, blurred code image created with Carbon, Next.js logo from Next.js official website, Disqus logo from Disqus Brand and Logos official material Originally posted in oh-no.ooo (Fixing Disqus 'Auto' theme switching when using Next.js + next-themes), my personal website.

Level up your Tailwind game

Lucy Love — Fri, 07 Jun 2024 20:28:07 +0000

This is my first article in Dev.to, please be patient with the poor markdown-ing!

Alright, this article might or might not be for you.

If you're the type of person that finds some Tailwind UI components and copies all the classes without any second thought, this might be for you.

If you're passionate about Tailwind and you appreciate getting creative with its utilitarian classes, this might be for you.

If you struggle with Tailwind and wonder why can't we just stick to plain old CSS, this might be for you.

If you don't like repetition and suspect that (besides wasting your time with the previous statements) some of the things that I'll show here are something you're already aware of, this might still be for you — repetition can't be that bad and I really tried to bring in something for everybody!

The idea here is to go through a Tailwind speed-run and find things that could help you use it more efficiently. And if nothing resonates with you, share with me in the comment section what did I miss :D

(And yes, the assumption is that you use VSCode, and occasionally Next.js for a thing or two, although a lot of these topics remain valid also with other frameworks.)

Let's get started then, shall we?

Before you proceed reading, let's make sure you are already using Tailwind CSS Intellisense, because if you're not, you definitely should. It's impossible to remember all the classes that Tailwind offers, and a little while we type them out is really appreciated!

Speaking of classes...

Classes, classes everywhere!

Meme generated with Imgflip Meme Generator

Yes, let's make sure we start with the easy-peasy. Lots of people complain that Tailwind litters the project components with hecklots of classes, making it difficult to read through the component. To them I tell... have you heard of Tailwind Fold by Stivo? No? Now you have.

In his article about Hiding classes in VSCode, our friend and constant source of inspiration Flavio Copes goes through a quick look at how this VSCode extension simply shows and hides the classes through a simple click.

While this is a worthy approach, you might not want to click to toggle classes visibility (I know I don't), and therefore the next suggestion would be...

Tailwind + Sass (and a sprinkle of `@mixin` if you will)

(We'll assume you're using Next.js, because, let's be honest, what else would you want to use if you had a choice?! I'm kidding, kinda :D)

We all love (I hope, otherwise why are you here?!) the power of Tailwind, but separating the functional part of a component from its styling is still a dream for many. The good news? You can achieve this by combining Tailwind with Sass! You just need to install Sass and everything will start working right off the bat!

Joaquin Collado, through Rootstrap, has an easy guide on how to Use Module SCSS with Tailwind in Next.js. Let's follow along!

First, install Sass

npm install --save sass

Then, create the .module.scss for your components, e.g. Button.module.scss

.button {
  @apply p-4 rounded bg-blue-500;
}

Import the styles in the component

import styles from './Button.module.scss';

And finally use them in your React component

/* ... */

<button className={styles.button}>Click Me</button>

/* ... */

Ta-da! 🎉 You will now be able, for most things, to separate the Tailwind classes from your component.

And you know what?! This approach allows you to use also the @mixin properties if you're used to them!

Mixins allow you to define styles that can be re-used throughout your stylesheet. They make it easy to avoid using non-semantic classes like .float-left, and to distribute collections of styles in libraries.
— @mixin and @include explanation from the official Sass documentation

Have a look at this demo repository in CodeSandbox where you can see Tailwind + Sass + a simple implementation of @mixin in action, or — if you prefer — test this implementation of Tailwind + Sass + @mixin locally by cloning it from GitHub.

So, let's take it slow and check... what do we have over there?

// page.tsx
import SassButton from "@/components/sassButton/sassButton";
/* ... */
<SassButton>Hello, I am a simple button</SassButton>
<SassButton className="block mt-4" variant="cancel">
    Me too!
</SassButton>
/* ... */
<SassButton className="w-full m-2" variant="alert">
    I am a variant that takes in
    both color and optional text color
</SassButton>

We have a poorly-named SassButton component that can accept two props (ignoring the children, in our case the text we want our button to have), className and variant. Both props are optional, and while we get later to className and best practices on how to use that, let's focus on the variant part.

Now, moving to the button component

// SassButton.tsx
import cx from "classnames";
import { FC } from "react";
import styles from "./sassButton.module.scss";

interface SassButtonProps {
  variant?: "default" | "cancel" | "alert";
  className?: string;
  children: React.ReactElement | string;
}

const SassButton: FC<SassButtonProps> = ({
  variant = "default",
  className = "",
  children,
}) => (
  <button className={cx(
    styles["button-" + variant], 
    className
  )}>
    {children}
  </button>
);

export default SassButton;

we use the variant prop to determine what style the button will inherit from our sassButton.module.scss (which will be button-<variant_name>), and when no variant is set we just set its value to default.

Let's finally have a look at the Sass module.

@mixin button-styles(
$button-bg-color, 
$button-text-color: "white"
) {
  background-color: $button-bg-color;
  color: $button-text-color;
  @apply p-4 rounded;
}

.button-default {
  // here you can pass the background color
  // text color will use the default from the @mixin
  @include button-styles(blue);
}

.button-alert {
  // here you can pass both background color and text color
  @include button-styles(orange, black);
}

.button-cancel {
  @include button-styles(#ff0000);
}

Our sass module starts with the overall shape and appearance of our button through the @mixin directive called button-styles, and it uses $button-bg-color and $button-text-color as variables to customize the color of the background and the text of the button.

Subsequently, we reuse the same setup by providing the variants default alert and cancel with the desired background and text color (the latter being optional and defaulting to white if nothing else is specified) by calling on button-style through the @include directive.

(Congratulations, you just had an absolute speed-run on how to use @mixin if this is your first time!)

Notice that with this approach nothing forbids us to use Tailwind classes at any point; we are already using simultaneously traditional CSS properties combined with Tailwind classes. Allegedly, no one could stop us from doing

.button-cancel {
  @include button-styles(#ff0000);
  @apply text-xs underline;
}

and it would be up to us to choose how to organise and create all the variants.

Heck, you might and think "why bringing @mixin up at all?" and in general I would say that Tailwind on its own is more than enough, but in a system that needs to contemplate multiple variants of the same component, @mixin could be the solution you were looking for — also, my objective with this article is to showcase more possibilities on how to work with Tailwind!

(Also... for some reason, I am not successful setting up a default value for $button-bg-color, if you know why let me know in the comments how to set all the parameters optional!)

So do you remember that className I said I was gonna mention again later? Now it's the time, for we are going to talk about...

The misunderstood art of managing space between elements and sections

If you're working with a good design system, I'd expect everything to be well-divided in sections and you being blessed with the consistency of everything spaced consistently throughout the project.

A good design system would have an atomic structure, where each smallest atom is a discernible component that may coincide to one or a few more HTML elements in the page that provide some value. Using these atoms/components together would form molecules, which would be the equivalent of a header, footer, sidebar — which all are sections of a website page — and a full page could be then considered an organism.

The reality is that most times, designers work in components and not in sections, meaning that there's no real concept of molecules, just atoms and straight into organisms. This implies that there is easily a lot of discrepancy on how much space there can be above an heading or below a section based on the rest of the content of the page if there is no clear demarcation of the end of a section and the beginning of another.

In the above image (titled Bad spacing), the elements have an add a margin down approach to space components between each other. While this might still result in the desired appearance for some pages, reusing the same components in new pages will cause issues as the margins might differ. There is no clarity on how much space the navigation or the article header should have, nor how much their components should have space around them.

In this other image (titled "Better spacing") we can see an improved understanding of spacing between elements and a clearer use of sections. We are able to deduct how much space there should be around each component, not only under, and which part of the overall space doesn't really belong to any component.

(Yes, I know, some components such as "Tags" should also be able to see the settings of each single "Tag" and in my picture they are all compact together, but I just wanted to get the spacing point across... :D)

While we are not here to discuss about design systems (although I would anytime), I want you to acknowledge that components shouldn't directly take care of accommodating spacing based to their position in a page, but rather, they should be able to circumstantially receive and accommodate their spacing directives.

What do I mean by circumstantially? Nothing more than accepting classes related to the spacing that is needed for the page where the component will show up.

You can check this CodeSandbox to test how to give arbitrary spacing classes to a component or, like before, you can check how to give arbitrary spacing classes from this GitHub repository.

Let's dig into the code.

We have three different pages, app/pages.tsx, app/articles/page.tsx and app/about/page.tsx that make use of the same <HeaderTitle> component. The homepage uses the component without worrying much about its spacing in the page:

// app/page.tsx

/* ... */

<HeaderTitle
  title="Lorem ipsum"
  description="This HeaderTitle component 
doesn't have any extra spacing setting"
/>

/* ... */

Meanwhile, both app/articles/page.tsx and app/about/page.tsx infer an extra className property that allows the <HeaderTitle> component to take up different space in the page.

// app/articles/page.tsx

/* ... */

<HeaderTitle
  title="Lorem ipsum"
  description="This HeaderTitle has some extra margin 
around it to fit better something like an article title"
  className="my-24 mx-12" // we added margins for this page
/>

/* ... */

// app/about/page.tsx

/* ... */

<HeaderTitle
  title="Lorem ipsum"
  description={
    <>
      <ul>
        <li>
          This HeaderTitle shows how much 
          flexibility you can have
        </li>
        <li>
          while the component itself doesn&apos;t have 
          to include natively any &apos;fixed&apos; 
          position
        </li>
      </ul>
    </>
  }

  // with this approach, we can also infer
  // other styles related to the position of the element
  className="fixed right-0 top-24"

/>

/* ... */

The point here is that the code of the <HeaderTitle> component itself remains untouched and un-duplicated, while its spacing properties are relative to the contexts it gets used on, allowing for flexibility of usage across different pages and different needs.

You might want to argue now "couldn't we just wrap the component into another div whenever we need more space around it?", and while that is possible, it also creates extra elements that might create challenges while delivering semantic HTML. Also, it really helps us categorizing which classes we need for its spacing and positioning, and which ones are for the component itself.

Which, guess what, leads us straight into the next topic!

Grouping by purpose for the sake of readability

It takes absolutely nothing to make Tailwind classes difficult to digest; you check one component's styling and all you see is a long list of classes and no quick glance will prevent you from mistakenly apply a second mx- class or so.

So, next in my personal recommended Tailwind best-practices, is to think about what each class is doing — layout, spacing, typography, colors, etc. — and group by that!

For example, instead of writing

<div class="mt-4 bg-blue-500 text-white p-6 rounded-lg shadow-lg hover:bg-blue-700">
  <!-- content -->
</div>

You could organize them like this

<div class="p-6 mt-4 rounded-lg shadow-lg bg-blue-500 text-white hover:bg-blue-700">
  <!-- content -->
</div>

Grouping similar classes together makes it easier to read and understand what stylings are being applied to the element.

If it sounds daunting as a task, worry not! Someone has already thought of a VSCode extension, Tailwind Raw Reorder, that will take care of the sorting for you! (And apparently, it also works in module.scss files without any extra configuration!)

The order that the extension proposes is as follows (or at least ChatGPT think it is — at least I couldn't find this from anywhere else):

Layout: container, box-border, box-content, etc.
Positioning: static, fixed, absolute, relative, sticky, etc.
Flex and Grid: flex, inline-flex, grid, inline-grid, etc.
Spacing: m-0, p-0, space-x-0, etc.
Sizing: w-full, h-full, max-w-full, min-h-full, etc.
Typography: font-sans, text-sm, font-bold, etc.
Background: bg-white, bg-opacity-50, etc.
Border: border, border-0, rounded, ring, etc.
Effects: shadow, opacity-0, etc.
Transitions and Transforms: transition, duration-300, ease-in, scale-100, etc.
Miscellaneous: cursor-pointer, select-none, etc.

You can read more about the development journey of Tailwind Raw Reorder on Reddit, where people talk also about the official recommendation for Automatic class sorting with Tailwind (which I don't recommend anymore because it only sorts classes alphabetically, although I wouldn't necessarily diss, as I did like the combo of Tailwind + Prettier it when I discovered its existence).

It is fair to note that Tailwind Raw Reorder by Andrew Trefethen is a fork of the now dated Headwind VSCode extension.

Well damn, if this isn't all that you need to make the most out of Tailwind in a smart way!

But wait! There's more!

Tailwind Merge to the rescue

While I've already written a small snippet about Tailwind Merge, let me reiterate here what's for.

Like the name suggests, tailwind-merge npm package by Dany Castillo offers a solution that combines and reuses Tailwind utility classes.

Suppose you have a button component that can be either primary or secondary, with different styles for each state, some styles taken from a button.module.scss and perhaps with something else inherited by className as we have seen is possible from above (oh god, what a mess — I am legally obligated to mention the classic "Your scientists were so preoccupied with whether or not they could that they didn't stop to think if they should.").

Instead of having to figure out whyyy is the padding not working as you'd expect, you can use tailwind-merge and give hierarchy on how all the various classes take priority.

// button.tsx

import { FC, ReactNode } from 'react';
import { twMerge } from 'tailwind-merge';
import styles from './button.module.scss';

interface ButtonProps {
  type?: 'primary' | 'secondary';
  className?: string;
  children: ReactNode;
}

const Button: FC<ButtonProps> = ({ type = 'primary', className, children }) => {
  const baseClasses = 'p-4 rounded-lg';
  const typeClasses = type === 'primary' ? 'bg-blue-500 text-white' : 'bg-gray-500 text-black';

  return (
    <button className={twMerge(baseClasses, typeClasses, styles.button, className)}>
      {children}
    </button>
  );
};

export default Button;

Assuming a fictitious button.module.scss containing

// button.module.scss

.button {
  @apply text-xl;
}

The button will eventually have the following classes

'p-4 rounded-lg bg-red-500 underline text-xl text-white'

This approach eliminates potential conflicts and contradictions and hopefully keeps your elements rendered with fewer clean(er) classes.

The one caveat of Tailwind Merge, imho, is that you would have to start using it at the beginning of a project; however, nothing prevents you from progressively add it into the codebase.

Now, what else? Well, there's plenty!

Speed it up with component libraries

We all like to keep rebuilding the wheel, as every project proposes different nuances and we just want that button to work exactly as we had it envisioned. But the key to a successful "I build it my way" is to know when to build and when to borrow.

shadcn/ui offers a great set of components (styled with Tailwind) that you can take as-is and customize all while they already include some accessibility contemplations. It differs from other libraries as it invites you to be hands-on the actual component and it allows you to modify it to your exact needs without having to create extra levels of abstractions for customisation.

It is worth to note that, like everything, it is not perfect and sometimes you might want to rewrite a couple of things here and there. For example, its class handling proposes a mix of clsx and twMerge that might be redundant, as described by Pablo Haller in his article Something I don’t like from shadcn/ui.

That being said, shadcn/ui is a great way to speed up your work, especially combined with some good Figma prototyping made simple for you by Pietro Schirano with their Figma @shadcn/ui - Design System.

And while shadcn/ui is a great free solution to implement ready-made-tailwind-styled components, you might want to use a more mature system such as Flowbite.

Flowbite (whose main contributor is Zoltán Szőgyényi) is a component library that is also built on top of Tailwind CSS. It provides a broader set of UI components that you can easily integrate into your Tailwind projects and it really helps you making everything look professional and curated from the very beginning.

On top of everything, Flowbite proposes a lot of videos that help you navigate the new ecosystem, as well as a lot of constant updates to their product, which we know is something we desire in a system that we want to implement and hopefully use for a long time.

If you want to familiarise with a great design system but you're not ready yet to make a monetary commitment, Flowbite is the right resource nonetheless. They offer also a free version of their Flowbite Design System, which can help you speed up your prototyping and design process while keeping high-quality mockups — and eventually figure out if Flowbite is the solution you were looking for.

Let's talk about forms

Got no time to make that form pretty? Worry not, because Tailwind Forms can come to the rescue to style in a consistent manner all your forms!

It provides base styles for form controls like inputs, text areas, checkboxes, and radio buttons.

You can simply install the plugin

npm install @tailwindcss/forms

add it to your tailwind.config.js

module.exports = {
  //...
  plugins: [
    require('@tailwindcss/forms'),
  ],
}

and that's pretty much it! Wanna customise something more? Feel free to add some extra styles to the form elements like you normally would!

Be sure to check out the Tailwind Forms documentation and be sure to checkout the Tailwind Form example they provide!

Snippity snippets!

I'd like to end this article by shining some lights on other majestic work that people have done and shared.

The homepage of Tailwind UI.

You can find a ready-made collection of templates in Tailwind UI, developed and curated by the very same creators of Tailwind. It's a nice mature collection of components and templates, with the only downside that it will cost you some money. But hey, quality stuff nevertheless!

The homepage of Tailwind Snippets.

Tailwind Snippets, as it mentions in their homepage, proposes a collection of UI templates to speed up your UI development using React and Tailwind CSS. Quick and easy to browse, find the elements you need and copy away!

Tailwind Snippets website, but the one of the Tailwind Snippets VSCode plugin.

With the same name but with a VSCode extension coming along with it, Tailwind Snippets is a VSCode extension that allows you to take advantage of the numerous snippets available in Tailwind Snippets and developed by ZS Software Studio.

Tailwind Components website.

On the same note, you'll find Tailwind Components with its community-shared free-to-use components... all the options!

And these are just a few of the ready-made snippets you can copy away. Do you have a favourite one, or am I missing out on something good? Please share!

I hope you found some good resources in this article, and that ideally you might have learned a thing or two. If you have any questions or additional tips, drop a comment below!

Sources and inspiration

Tailwind CSS Intellisense by Tailwind CSS
Tailwind Fold by Stivo
Hiding classes in VSCode by Flavio Copes
How to Use Module SCSS with Tailwind in Next.js by Joaquin Collado via Rootstrap
ChatGPT prompt: Can you show me what order would the class list (handled by Tailwind Raw Reorder) have?
Tailwind Raw Reorder by Andrew Trefethen
tailwind-merge npm package by Dany Castillo
shadcn/ui main website
Something I don’t like from shadcn/ui by Pablo Haller
Flowbite by Zoltán Szőgyényi
Flowbite Design System on Figma
Tailwind Forms documentation
Tailwind UI
Tailwind Snippets
Tailwind Snippets, the one that offers the Tailwind Snippets VSCode plugin
Tailwind Components
Cover: 3d young school student by Freepik, Flat abstract wireframe background by Freepik, Tailwind logotype from Tailwind Official Brand page, semi-random coding text generated with Carbon

Originally posted in oh-no.ooo (Level up your Tailwind game), my personal website.

Forem: Lucy Love

Javascript Symbols

What is a Symbol?

Why symbols then?

Sources and inspiration

An Introduction to Quantum Computing

Superposition

Entanglement

Briefly about Quantum gates

Briefly about Challenges

Conclusions

What next?

Sources and inspiration

Generics in Typescript and how to use them

So what are Generics?

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

Challenges with Generics

Long story short

Sources and inspiration

declare-ai.org - ... so, who wrote that?!

Sources and inspiration

Solving Tailwind's "Unknown at rule @apply"

Sources and inspiration

Performance optimization with useMemo

What is useMemo?

How to use useMemo

Expensive calculations

1. How often is the operation performed?

2. How reusable is the result of useMemo?

3. Is it worth the memory consumption?

"Premature optimization is the root of all evil"

When not to use useMemo

Example implementations

A brief note about useMemo vs. useCallback

Sources and inspiration

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

What was the issue

The solution

Sources and inspiration

Level up your Tailwind game

Classes, classes everywhere!

Tailwind + Sass (and a sprinkle of @mixin if you will)

The misunderstood art of managing space between elements and sections

Grouping by purpose for the sake of readability

Tailwind Merge to the rescue

Speed it up with component libraries

Let's talk about forms

Snippity snippets!

Sources and inspiration

Tailwind + Sass (and a sprinkle of `@mixin` if you will)