DEV Community: Tim Raderschad

How to write better JavaScript using Immutability

Tim Raderschad — Sun, 10 Oct 2021 19:36:57 +0000

There are many fancy terms that programmers use. Some of them are just a more eloquent version of an otherwise boring-sounding word. Others describe something which can’t really be said in one single word. Immutability is one of the latter. Here is my take of describing it in plain English:

Immutability means not changing something.

But why would I not change something? I’m a developer, I create things, I hear you saying. But don’t worry, you will still be able to change the world if you try to use the power of immutability.

Immutability in JavaScript

If you know a bit of JavaScript you probably know that there are three keywords to define a variable: var, let, and const.

(side note: you should not use var, read here why).
There is a difference between var/let and const:

Variables that are declared with either varor let can be re-assigned later in the code while variables declared using const are constant and can not be re-declared. Here is a code sample:

let name = "ti";
var age = 22;
const job = "WebDev";

// whoops typo
name = "tim";
age = 23;

job = "SysAdmin";

This code won’t work and instead, we will receive the following error:

Uncaught TypeError: Assignment to constant variable.

I guess I got quite lucky because I want to be a WebDev and not a SysAdmin, so it was quite smart by me to use a const here ;). But jokes aside, the easiest and most obvious way to achieve immutability in JavaScript is just to use const when you assign a value to a variable.

Wait, that’s it?

Well if that would have been all, this blog post would be over right now. But JS has some little gotchas which make things just a bit more complicated: Objects and Arrays. Why? Let’s look at another code example:

const person = { name: "tim", age: 23 };
const hobbies = [];

hobbies.push("coding");
hobbies.push("football");

person.hobbies = hobbies;

Does this code compile? Yes, it does. And why? We are actually never re-assigning the initially created variables. We are either calling functions on it like calling hobbies.push which changes the variable or re-assigning a nested value on an object like person.hobbies = hobbies.

And why is this a problem?
Well, we defined both of those variables as const which could make you think, that this variable is constant and it can not be changed later in the code. But Arrays and Objects in JavaScript are special and don’t follow the rule here!

So are we just doomed in JavaScript? Can’t we be immutable?
We are not doomed, we just need to change our mindset a bit. Let’s look at another code example which is using mutable code:

function capitalizeEachWord(elements) {
  for (let i = 0; i < elements.length; i++){
     elements[i] = elements[i].toUpperCase();
  }
  return elements
}

This code takes in an array of elements and returns an array with the same elements but each element will be capitalized. But you might have noticed something about this function. The first, but no important thing is that it will fail if one of the elements is not a string, but most importantly:
This function will change the array which is passed in! What does this mean? Let’s look at another code example:

const names = ["Steve", "Bill", "Elon"];
const bigNames = capitalizeEachWord(names);

// easy, right?
console.log(bigNames); // logs ["STEVE", "BILL", "ELON"]

console.log(names); // logs ["STEVE", "BILL", "ELON"]
// uhm what?

Even though we defined our array of names as a constant, our function still was able to change the value of the passed array. So let’s fix our code so it won’t change the array:

function capitalizeEachWord(elements) {
  return elements.map((currentElement) => {
    return currentElement.toUpperCase();
  });
}

In this example we are using the Array.map method which returns a new array instead of mutating the original one.

Here is a really good cheat sheet for all the ways to immutably update objects and arrays.

Why do I love it?

I personally really like immutability and started loving it when when I used Redux on a daily basis. I think immutable code is much cleaner and more maintainable because there are no side effects. The code is really concise because instead of updating a variable that had been declared 50 lines above the current line you just create a new one. In my opinion, it is really clear what is happening with the code. I also think that using immutable methods like Array.filter to remove an element from an array instead of using Array.splice makes the code much safer and doesn’t give me a false sense of security. If I read const array = [1, 2, 3]; I just assume that it won’t be changed because it’s constant.

Why isn’t everyone doing it?

Well, just like all other patterns in programming this is a really subjective topic. Each developer likes other languages and patterns and like everything in life there are always pros and cons to using it. One of the cons of immutability is memory management. If we have an array with 10,000 elements and we call .map on it, we will have two arrays with 10,000 elements, which means we just doubled the memory used by our application. One other reason is that immutable programming actually takes more effort and might not feel right. Why can’t I push to an array? Why does this function exist if I shouldn’t be using it?

So should you be obsessed about it as well?

As with everything on the internet, you should never follow someone’s advice blindly! If you are not forced to write immutable code (e.g. when working with Redux), you can just do what feels right to you. It will take some time and effort to get used to it and it might be really frustrating not to use some functions which you just learned to use. But if you still like the approach, you will probably love Immer which is a JavaScript library that makes immutability super easy, because it lets use mutable code and just takes care of the rest. Here is a cool blog post by the creator of Immer which tells you why he created it!

3 TypeScript Tricks I wish I knew when I learned TypeScript

Tim Raderschad — Thu, 07 Oct 2021 06:20:34 +0000

Number 1: Readonly<T>

Let’s start with a small example:
We have a simple function which takes in an array of numbers and returns an array with all elements sorted.

function sortNumbers(array: Array<number>) {
  return array.sort((a, b) => a - b)
}

Now look at the code below and look if everything looks good. Think about what the console output will be. I recommend taking some time and actually thinking about it!

const numbers = [7, 3, 5];

const sortedNumbers = sortNumbers(numbers);

console.log(sortedNumbers);
console.log(numbers)

The first output is pretty simple. It is [3, 5, 7]. But now listen. The second output is the same! And you might be asking: Why? I defined the array as const how can it be changed?.

Well, arrays and objects are quite special in JavaScript. If you pass them to a function it will pass the reference to the array or object which means it will mutate the original array if you call certain functions like Array.sort which are in-place.

Readonly to the rescue 🚀

Let’s change up our code a little bit:

function sortNumbers(array: Readonly<Array<number>>) {
  return array.sort((a, b) => a - b)
}

This doesn’t compile though. TypeScript gives us the following error Property ‘sort’ does not exist on type ‘readonly number[]’
Which is actually what we want! We are not able to mutate the parameter which leads to zero side effects!
Nice.
But does this mean we can’t have function which sorts our arrays? Of course we can. We only need to sort a copy of our array rather than sorting the array itself. There are many ways to copy an array in JS like spreading it ([…array]), using array.concat(), Array.from(array) or array.slice() . So let's use the spread operator to finish our function so it looks just like this

function sortNumbers(array: Readonly<Array<number>>) {
  return [...array].sort((a, b) => a - b)
}

And we’re done! Clean code enforced by TypeScript. BTW: This also works with objects!

If you want to learn more about mutability in JS check out this article

Number 2: Any vs Unknown

When you are using eslint together with TS you might have noticed the message unexpected any. At least I was wondering why any is bad. How else should you state a variable can hold any possible value. Let’s look at an example here:

const someArray: Array<any> = [];

// add some values
someArray.push(1);
someArray.push("Hello");
someArray.push({ age: 42 });
someArray.push(null);

We are creating an array that can potentially have all available types in it. While this might not be the best code ever, let’s just go with it. We add a number, a string and an object. Let’s now look at the code below and think about what will happen:

const someArray: Array<any> = [];

// ... adding the values
someArray.forEach(entry => {
  console.log(entry.age);
})

This code is actually valid TypeScript and will compile without any issues. But it will fail at run time. Why? Because as soon as we loop over an entry which is null or undefined, and then try to access .age, it will throw an error like this:

Uncaught TypeError: Cannot read properties of null.

I think this is some kind of false security because you expect things to just work. After all the TS compiler told you the code is fine.

But we can fix this! And the change is actually super simple. Instead of typing the array as Array<any>we can just use Array<unknown> if we now use the same code but with that change it will look like this

const someArray: Array<unknown> = [];

// ... adding the values

someArray.forEach(entry => {
  console.log(entry.age);
})

and this code will not compile! Instead, TypeScript shows the following error when we try to access entry.age

// ... other code

someArray.forEach(entry => {
  // Object is of type 'unknown'
  console.log(entry.age);
})

using unknown enforces us to check the type (or explicitly casting the value) before we do something with a value with is unknown. Let's look at an example:

// ... other code

type Human = { name: string, age: number };

someArray.forEach(entry => {
  // if it's an object, we know it's a Human
  if(typeof entry === 'object'){
    console.log((entry as Human).age);
  }
})

In this case we checked whether the value is an object and then access the .age property. And because this is such a abstract topic, here is a little wrap-up:

any is basically saying the TypeScript compiler to not check that bit of code. Avoid using any whenever you can! It's better to use unknown instead because it enforces you to check the type of the value before using it or else it won't compile!

Note: don't use typeof x === 'object' to check whether something is a valid object, because it will return true for arrays as well.

Number 3: Typing Objects with Records

When I first started using TS I always had to google how to type an object because I could never remember the solution which looked something like this:

interface Person {
  [key: string]: unknown
}

const Human: Person = {
  name: "Steve",
  age: 42
}

While this is a valid solution to type an Object in TS, I think it’s pretty hard to memorize and also it is pretty limited.

For example if I only want to allow certain keys I would go ahead and create a string union like this:

type AllowedKeys = 'name' | 'age';

interface Person {
  [key: AllowedKeys]: unknown
}

const Human: Person = {
  name: "Steve",
  age: 42
}

But, TypeScript doesn’t like this and gives me that error:

An index signature parameter type cannot be a literal type or generic type. Consider using a mapped object type instead.

Uhm, what? This is again one of those TypeScript errors which wants you to just close your IDE and go back to plain JS. But there is a solution which will make the code much more readable:

type AllowedKeys = 'name' | 'age';

// use a type here instead of interface
type Person = Record<AllowedKeys, unknown>;

const Human: Person = {
  name: "Steve",
  age: 42
}

We only had to change from interface to type so we can define a new type and then use the keyword Record which takes two generic parameters where the first one is the type of the keys and the second on of the according values. Pretty simple, right? And by the way, if you now add values to AllowedKeys it will throw an error in the Human Object because it’s missing those properties which is pretty awesome if you ask me!

This post was originally published on cstrnt.dev