DEV Community: Diogo Almeida

Improving Coupling in your Project

Diogo Almeida — Mon, 23 Dec 2024 14:29:59 +0000

Hey everyone! This post is meant to help you improve how your project's data types are connected, making them more reliable and easier to understand.

TLDR for you folks in a hurry: avoid repeating types and consts that refer to the same thing and try to give them suggestive names (even if they are a simple string or a number). This will make it easier for you to identify, modify, or remove your code later.

The Problem

Imagine you are developing an e-commerce website, and you have defined the product's type as:

export type ProductType = {
  id: string;
  name: string;
  price: number;
};

On a project of this kind, you can easily find multiple ways where one might refer to a product's id, from simple functions:

const getProductById = (products: ProductType[], id: string) => {...};
const onProductPress = (productId: string) => {...};

To more advanced situations, such as saving a product's data in a state store, or passing props to other components in JS Frameworks

The Issues

Now let's address the issue(s) with this approach:

What if the product's id wasn't this simple and easy to remember? What if it was something like ab12-w35-s48-09 (representing for example vendor-category-product-variant)?
What if, and this is my key point, you had to change the type of the product's id, in all of its occurrences throughout your project? This could be particularly difficult if you gave it different names (like productId, product_id, pid, or id) when referring to it in different files. You couldn't just search for string either because you would most certainly find many occurrences that were not related to it.

The Potential Solutions

To address issue one, you could use Template Literals Types, which would make the new product id's type: ${string}-${string}-${string}-${string}. Repeating this across multiple files would now be annoying, so one could either:

create a custom type for the id field, and use it in the ProductType:

type ProductIdType = `${string}-${string}-${string}-${string}`

If needed, you could also create and refer to different types for each string, or refer to others you created previously. Finally you would use the new type as such:

(productId : ProductIdType) => {...}

or you could refer to the id entry of the ProductType:

(productId : ProductType['id']) => {...}

Both these approaches would solve issue two: wherever you'd find ProductIdType or ProductType['id'], you'd know that you were dealing with a product's id, and knew that you should replace it.

The first solution might seem friendlier, but you would now have a bi-parted structure, where you have one type for the product and another for the id, which can be used independently. Here's an example representation of said structure:

This is no doubt a smaller issue, but if you change/delete the id entry of the ProductType, that change wouldn't be reflected in your whole project.

The last approach, however, is the one I usually follow, because it increases your data's coupling (by lack of a better word). All your references to the product's data now point directly to the ProductType:

Conclusion

I'm not saying you should always create types for all your data. Whenever I see myself repeating references to the same data's type, I usually opt to access the original one, as in the second approach.

Bonus tip 1: You can apply the same logic for consts: If you see yourself repeating the same magic number or string in multiple places, it's best to give it a proper designation and use it.

Bonus tip 2: Use Pick, Omit and Exclude and other Utility Types if you want to select/exclude more than one entry of a type instead of repeating them.

That's all! I hope you liked my post. Feel free to leave your feedback on this topic.

The Power of Reduce: Optimizing JavaScript Code for Speed and Efficiency

Diogo Almeida — Tue, 14 May 2024 08:37:30 +0000

Hey everybody! This is my first-ever post!

In this article, I will be talking about the reduce method of JavaScript arrays, which I feel is sometimes forgotten. I will give a brief introduction to this method, and then I will proceed to compare it with other iteration methods.

TLDR

Review your array iterations
Instead of map and filter, use reduce;
Spreading (as in [...list]) large lists is a bad idea; Push to list instead
reduce is faster than map and filter, and for in for large lists

Personal Notes

I'm a Frontend Developer with less than 2 years of experience and this is my first article.

I'm saying this to let you know that I'm still very new, so all feedback is welcome, whether it's about technical content, writing, or personality (please keep it constructive).

Motivation: the path to a single loop

While reviewing some people's code (and sometimes my own 😬), I realized that it's really easy to employ unnecessary iterations of arrays and that sometimes reduce could improve the code.

For example, if I have a list of people and I want to get the list of names of all adults, it is easy to think: "First I need to filter the list and get all the adults (age > 18 years in my country) and then I need to map it and return their names".
I believe that arrow functions makes this type of thought even easier because it eliminates the need to write function.

However, what keeps you from iterating the list of people and adding a person's name to an empty list if they are an adult. This is reduce in a nutshell.
This can also be done with ease using a for loop, although occasionally people overlook this method as well.

Reduce method introduction

I will now give a short introduction to how the reduce method works, so if you are already familiar with it, be sure to jump to the benchmark section.

Theory

In JavaScript, we have more than one way to iterate an array, like map, for, or reduce. The last one is perhaps the less 'friendly' and common between the three, but instrumental as well, as we shall see.

The method receives two arguments:

a callback function, that will be used to return the accumulated value in each iteration, and
an initial value, which will be used to start the accumulation.

The callback function itself receives up to four arguments:

The accumulator, sometimes referred to as total or abbreviated to acc, is the value that is "added" onto each iteration;
The currentValue, i.e, the current element of the array being iterated
Optionally, the currentIndex, the position of the currentValue in the array. Commonly used;
Optionally, the array being iterated. It's rarely used since you typically are iterating a variable that you declared previously. It is useful nonetheless because if you chain methods (e.g. you call initialArray.sort(...).reduce(...)), then the array parameter will be the sorted array and not the initial one.

You might notice that I'm employing terms related to accumulate. This is because that is what reduce does: it starts with one value, and each iteration it will "add" onto that value (I added quotation marks because algebraic addition is not necessarily involved).

Let's look at some code:

Practical Examples

I'm just going to give you some basic examples of how to use reduce because my goal isn't to turn you into reduce expert (nor do I claim to be) but to keep this method in the back of your mind.

Retrieving the names of all Adults
Let's focus on the previous example. If you were to do the same with map and filter, you would do something like:

peopleList.filter((person) => person.age >= 18)
          .map((adult) => adult.name);

With reduce, you'll do something like this:

peopleList.reduce((acc, person) => {
  if (person.age >= 18) acc.push(person.name);
  return acc;
}, []);

This way, you only use one loop instead of two. Is it less 'friendly'? You tell me.

There are a lot more uses of reduce, and ways of using it. I opted to use an arrow function but you don't have to if you don't want. In this CodePen you can find:

A comparison of the retrieval of the adults' names between map and filter, for in and reduce;
Another example, is where you sum all the numbers in a list. This is a typical example introduced when using reduce.

The reason I'm not detailing it here is that I don't want the concept "reduce is for sums only" to settle in your head. Yes, it is used for that, but not exclusively, as a teacher once told me.

In this example, I also detail how you can use reduce with regular functions and inline returns;

Benchmarking iteration methods

Now, those who know me know that I am a bit obsessed with avoiding repetition and increasing speed and performance.

This is the origin of my article.

I wanted to test if there was any difference performance-wise between map and filter, and reduce. Then I decided to throw for in in the mix as well.

Always learning!

So I did an initial benchmark and I quickly found a problem:

⚠ Spreading slows the reduce method!

See, in the reducer function, I was returning the acc the following way:

return condition ? [...acc, item] : acc;

With short lists, this isn't much of a problem, but with colossal-sized lists, this syntax made the reduce method much slower (as you will see).

Imagine my surprise when I first developed the benchmark and saw that reduce (the method I am advocating in my article) was much slower than map and filter! However, after some research, I found out that this was because in each iteration an object is created, and thousands of elements are spreaded onto it, so a strategy change was needed:

if(condition) acc.push(item);
return acc;

Now, whenever I employ reduce in my projects, instead of spreading, I push the item to the acc.

The benchmark

So, to develop my benchmark I created another CodePen where:

A list of 100,000 random numbers is created;
Each method runs a certain task 100 times, and each execution is timed;
And an average is obtained for each method; Regardless of the iteration and method, the task itself is to obtain the binary converted numbers smaller than 16. It's not a "real world" example, but it'll do for this purpose.

You'll see that I added the reduce method with spread and push so that you can see the difference in performance. So let's see what the fastest method is.

Results: And the winner is...

Reduce! Of course, it's reduce. I wouldn't be making this article if it wasn't. 😄

You'll notice I didn't add the reduce with spread time to the graphic because it was 8.8 seconds long (over 3000 times slower than with push)! All other methods are measured in milliseconds.

As you can see, the difference between the three iteration methods is not very large, but it doesn't change the fact that map and filter are 3 milliseconds slower than reduce. Of course, with smaller lists, the difference will be minimal.

Some things to consider about this benchmark are:

The code may seem overcomplicated, but that was the best way I found to avoid re-creating functions with each iteration or method.
I pushed the list's length to reaches that probably aren't reasonable. It's rare the project where one deals with lists with thousands of elements. But if you are, and performance is a big issue in your website, reduce is your friend;
Dealing with big lists isn't usually handled in pure JS. There are several ways to handle them, such as virtualization or pagination, so be warned.
The times I presented were obtained by running the code on CodePen, so in production, on a server, the execution can be faster.

That's all folks!
Thank you for reading my first post, and I hope you found it useful in some way (I don't refund the time you spent on it otherwise)