DEV Community: Marco Slooten

4 Common Angular Mistakes

Marco Slooten — Sun, 04 Apr 2021 07:36:40 +0000

Are you making these four Angular mistakes? OK, now that I got your attention we can add back some nuance to the clickbait. I thought it would be fun to make a list of frequent Angular 'mistakes'. However, none of these four items are always a mistake. I've found that they are often a code-smell or an indication that there might be a flaw in the code. I've made these mistakes myself a lot and I saw them happen a lot, too. I think it's a good thing to be aware of the potential issues and the possible solutions to them. So let's get to it.

1. Not unsubscribing

With Angular, you will almost certainly deal with observables sooner or later. In order to use them, we either need to subscribe explicitly in the .ts file, or use them directly with the async pipe in the .html template. I suggest using the async pipe as much as possible since it will automatically unsubscribe for you, but sometimes you just need the data in your TypeScript file. In that case, it's very easy to forget to unsubscribe.

Why is this a problem? Well, the subscription keeps tabs on the observable, even after the component is gone. That means we are still waiting on data, even when we no longer need it. So in fact, by not unsubscribing, you are creating a memory leak.

Luckily, it's easily fixed. There are multiple ways to do it:

Use the async pipe where possible. You can use the data in your template like this: <p>{{ observable | async }}</p>. If you need to transform the data in any way, you can do it with RxJS without needing to subscribe.
If you only need the first emission from an observable, consider using first() (or take(1)) in the subscription: this.observable.pipe(first()).subscribe(...). This will automatically unsubscribe after getting the first emission. If it is possible that it won't emit something, this is not the right option. Also, if you expect the data to possibly change while viewing/interacting with the component, it's also not the right option. When in doubt, go for option 3:
Initialize a property with a subscription, and add any new subscriptions to that. In the ngOnDestroy method, you can then unsubscribe to just the one subscription (which will contain the others):

subscription = new Subscription();

ngOnInit(): void {
  // Here we want to subscribe to this.observable:
  this.subscription.add(this.observable.subscribe(...));
}

ngOnDestroy(): void {
  // Unsubscribe to all observables we've added to this.subscription
  this.subscription.unsubscribe();
}

2. Not using trackBy

Even though it's in the Angular docs, it can be easily forgotten. In Angular loops, you have to provide a function that keeps track of the items, to see whether or not they have changed. If you don't do this, Angular doesn't know which items are different. So when there's a change, it will re-render the entire thing instead of only the changed item(s).

This is the one I still forget sometimes. The reason why this happens so often, is that it's not always immediately obvious from the app that there's something wrong. However, start adding data or interactivity, and you will start to notice.

One real-world example of this is when you have a list, which you can filter down by typing in an input box. Especially if you have more things going on in your for-loop (a nested loop for instance), it will quickly slow down if you need to filter the list live while typing. You might see the items flash briefly, even if they haven't changed. Of course you can debounce the input (to not trigger the change detection immediately), but it's best to fix it at the root and combine the two tactics.

Now, if you have a simple, flat, unordered list with static data, it doesn't matter that much. Especially if the list always remains the same during the time the component is shown. However, sometimes you just can't be sure whether it's static. In doubt, I'd say add the trackBy function.

It's a matter of creating a function that receives two arguments; the index of the item and the value of the item. You return a value by which the item is uniquely identifiable.

Syntax:

<ul>
  <li *ngFor="let item of data; trackBy: myTrackingFn">
    {{ item.name }}
  </li>
</ul>

myTrackingFn(index, value): number {
  return value.id;
}

3. Using the default change detection

One of the benefits of a framework like Angular, is that it can do a lot for you. An important aspect of this is keeping track of changes. However, by default, Angular has very aggressive change detection, meaning it will check for changes and potentially re-render on every small change (even a scroll event). This is nice when prototyping, but in production this may lead to issues.

Personally, I believe that the default change detection should be OnPush. It will only re-render when inputs change, events fire or when manually triggered. Often, OnPush just works. On some occassions, for instance if you have a few computed properties that need to be displayed (say, you have a calculation that you are doing in your .ts file and need to show it in the template), you will have to manually trigger a change detection cycle.

How to enable OnPush? In the component decorator, add the following line (and import ChangeDetectionStrategy from @angular/core):

changeDetection: ChangeDetectionStrategy.OnPush

4. Not making (proper) use of RxJS

OK, this turned out to be a pretty long one. Long story short: only subscribing to observables in your component's TS is a difficult pattern that can lead to bugs and having to handle subscriptions. Instead, you can almost always do the things you want to do with RxJS, and by doing that keeping the data an observable. Here's the long version:

Angular comes with RxJS bundled. This library helps us deal with asynchronicity in our data in a reactive way. For instance, if you make a HTTP request, you'll get an observable back. You can then add code to respond to the data you'll receive back later. However, like asynchronous data, RxJS can be pretty hard to fully grasp. I highly recommend to create a sandbox (Codesandbox, Stackblitz) and test some use cases with test data.

When you need to do something to the data that you're getting before showing it, that's when to look closer at RxJS's operators. Transforming, combining, filtering, you name it. In the example, we're getting data from two different APIs, need to combine it and then use it in our application.

When I wasn't aware of everything you could do with RxJS (or rather, was actively avoiding having to use it when I just started), I might haven written code like this: (for the record, this is a bad example, do not copy)

  name$ = of('Marco').pipe(delay(1000)); // This will be the response for the API.
  // With 'of' and the delay we're mimicking an API response
  job$ = of('developer').pipe(delay(2000)); // Same thing here
  name: string;
  job: string;
  message: string;

  ngOnInit(): void {
    this.data1$.subscribe(val => {
      this.name = val;
    });
    this.data2$.subscribe(val => {
      this.job = val;
      if (this.name && this.job) {
        this.message = `${this.name} is a ${this.job}`;
      }
    });
  }

What's happing here and why is it 'wrong'? First, I get two observables (name$ and job$). After that, I declare two properties which will hold the data once we get it back from the observable.

In the OnInit method, I subscribe to both the observables seperately. In the subscribe, I assign to my property to hold the data. So far, it's the same for both. However, I want to show a message in the template, saying 'Marco is a developer'. I need both pieces of data. I added in a check in the second observable, to see if both data sources are already there, and then I build the string.

Why is this problematic?

This is what's happening, but what's wrong? First of all, with API requests we never know for sure what the response time is going to be. We cannot know for sure whether the first or the second observable will receive the data first. The code will only work if the second observable gets the data later, otherwise nothing will happen. You might opt to copy that code and add it to the first subscription as well. That will work, but you might already have a feeling that it's not supposed to be used that way and does not scale or maintain well.

We also got an issue with change detection. If we set the change detection to OnPush, like we looked at in the previous step, it's not going to pick up any changes. In fact, it will not even pick up the first value. When Angular gets to the OnInit lifecycle method, chances are there hasn't been an emission from the observable (yet). We will never see anything in our template, unless we mock the data without any delay.

On top of that, we also did not manage the subscription. We've got a memory leak here (see tip 1!).

Summarizing, we got five properties to construct a simple string based on two observables. We also have issues with synchronicity, change detection and unhandled subscriptions. Most of these issues can be fixed using the same style of coding, but by now it's becoming clear that surely, there's a better way?

How to improve this?

Well, we need to make better use of RxJS! We want to take that data, as it comes in, in whatever order, and combine it. We show it on the page only when we have both pieces. A good place to start is on learnrxjs.io. Looking at the navbar, I think I want to search in the 'Operators' category. There's some subcategories there, but the first is 'Combination', which is what I want. CombineLatest sounds like something that might fit. Reading the description, it surely looks that way. It says:

| When any observable emits a value, emit the last emitted value from each

That's basically what we want, so let's proceed. For the record, there are other operators to consider for this use case (e.g. forkJoin, withLatestFrom or zip) but combineLatest is the most generic and is often used, so I'll stick with that for now.

We can refactor the ngOnInit part like this:

ngOnInit(): void {
  this.message$ = combineLatest([this.data1$, this.data2$]).pipe(
    map(([name, job]) => {
      return `${name} is a ${job}`;
    })
  );
}

CombineLatest is getting our two observables. When both have emitted something, combineLatest will emit the data. We can then tack on subsequent actions by adding them within .pipe. Within the pipe, we can use all kinds of operators. In this case I used map, which is very similar to a regular JS array.map() function. It will transform the data. In the end, it will emit whatever is returned from the map function!

We can remove the two properties that were holding the data, and convert the message property to an observable (denoted by the \$ at the end of the name). In the html template, we can simply show the message like this: {{ message$ | async }}.

This is less code (which typically means less bugs), easier to understand (once you are a bit familiar with RxJS), not dependant on the type of change detection or on the order the data comes in, not causing memory leaks and just better in almost every single way. Yet, the 'bad' example or variants thereof aren't as uncommon as you might think, especially to those just learning Angular and/or RxJs. Typically, RxJS takes some practice before it 'clicks', but when it does, you feel like you've unlocked a super power!

On to the next mistake

By now, you should be aware of the four patterns highlighted above. When you encounter them, be vigilant because it might indicate a problem. Once you know what to look for, you can hopefully write Angular a little bit more confidently! Did I miss any common mistakes? Let me know!

Photo by Joe Chau on Unsplash

Creating a Reusable Avatar Web Component

Marco Slooten — Wed, 26 Aug 2020 13:36:24 +0000

This avatar component will be a web component. It's a newish technology that over the last year seemed to have gained a lot more browser support. It aims to solve the reusability problem for bigger organisation or ambitious projects: letting developers use components that are compatible with all JS frameworks. After all, they are native JavaScript. That means that there doesn't need to be a component library for each framework (e.g. no separate libraries for React, Angular, Vue, Svelte, you name it), you could just do it with web components. It makes web components highly suitable for a component library.

So let's make one component. We're going to recreate the avatar component I've made in this blog post (https://marcoslooten.com/blog/creating-avatars-with-colors-using-the-modulus/) and turn in into a web component. As a reminder, this is what it will look like:

Create a new web component

There are frameworks for web components, but we're going to build one just with vanilla JavaScript. You might be tempted to name it 'avatar', but that's actually an invalid name. To allow better separation from native HTML elements, web components need to contain a dash. Note how there aren't any HTML elements that contain a dash, so you can consider the dash a visual clue that it might be a web component. Let's call it custom-avatar then. Moving on!

First, create a class named 'CustomAvatar' which extends HTMLElement. Extending is necessary because we need access to all kinds of functionality which comes with the HTMLElement. After the class, we need to tell the browser that there's a new custom element with a certain name ('custom-avatar') and a certain class ('CustomAvatar'):

class CustomAvatar extends HTMLElement {}
window.customElements.define('custom-avatar', CustomAvatar);

Although the class name (CustomAvatar) can be any name we want, it's convention to use the same name as our custom element, but in PascalCase (each word capitalized) instead of kebab-cased (with a dash). You can now add the tag to the HTML: <custom-avatar></custom-avatar>. Nothing to see yet. Let's make it look like an avatar!

Adding HTML and CSS to your web component

Inside of the CustomAvatar class, we are going to use the constructor. This method is called when the component is initialized and can be used for markup and styling. We are also going to call super(), which is needed to inherit all the methods and properties from HTMLElement.

class CustomAvatar extends HTMLElement {
  constructor() {
    super();
  }
}
window.customElements.define('custom-avatar', CustomAvatar);

Next, we are going to use the Shadow DOM. This is the encapsulated part of a web component: only the web component itself can change it. That means that your web component isn't affected by its surroundings. Let's say I have an h1 tag inside my web component and use the generic styling <style>h1 { background: hotpink}</style>. Even if the page around it has an h1 with styling, it will never affect the h1 within my web component (and the other way around).

Now the fun begins and we can add our markup to the shadow DOM. I've added comments to explain what each step does.

class CustomAvatar extends HTMLElement {
  constructor() {
    super();

    // Enable the shadow DOM for this component
    this.attachShadow({ mode: 'open' });

    // Create a HTML template (this is a special tag which can hold markup)
    const template = document.createElement('template');

    // Set the innerHTML to the actual markup we want
    template.innerHTML = `<div class="avatar"></div>`;

    // Create a style element
    const styles = document.createElement('style');

    // Inside the style element, add all the CSS
    styles.textContent = `
    .avatar {
      width: 52px;
      height: 52px;
      display: flex;
      align-items: center;
      justify-content: center;
      background-color: hotpink;
      border-radius: 50%;
      font-family: sans-serif;
      color: #fff;
      font-weight: bold;
      font-size: 16px;
    }
    `;

    // Append the style element to the shadow DOM
    // shadowRoot is the wrapper of our component
    this.shadowRoot.appendChild(styles);

    // Take the template contents, and copy them to the shadow DOM
    this.shadowRoot.appendChild(template.content.cloneNode(true));
  }
}

Now you should see a pink circle on the page. We're getting somewhere!

Add attributes to pass user data

Instead of props or @Input() or whatever you're used to with a framework like React or Angular, we're going to use regular HTML attributes to pass data to our component. We only need the initials, so that we can use the avatar like this: <custom-avatar initials="MJ"></custom-avatar>. If you do this, you can access the attributes using JavaScript, e.g. this.getAttribute('initials'). Some examples of web components let you retrieve the attributes in the constructor using this method, but that's bad practice (see the spec here: https://html.spec.whatwg.org/multipage/custom-elements.html#custom-element-conformance). A better idea to do it in connectedCallback, which is called when the component is loaded.

Even better is attributesChangedCallback. This method is called whenever the attributes are updated. Luckily, they are also changed when the component first loads. The initial value of attributes is null and once it's ready it will set them to the provided attribute value. attributesChangedCallback takes three arguments: name, oldValue, and newValue. Perfect for us! Not only is it a good place to get the initial values, but it will also run again in case the value has changed (and we would need to get a new color for our avatar). Add the following code outside of the constructor:

// This is our code to generate a color code from a string
// For more info, see the blog about this technique:
// https://marcoslooten.com/blog/creating-avatars-with-colors-using-the-modulus/

getColorFromText(text) {
  const colors = ['#00AA55', '#009FD4', '#B381B3', '#939393', '#E3BC00', '#D47500', '#DC2A2A'];
  const charCodes = text
    .split('')
    .map(char => char.charCodeAt(0))
    .join('');
  return colors[parseInt(charCodes, 10) % colors.length];
}

// This static get is needed to tell our component which attributes to watch
// If you don't provide this, it won't work
static get observedAttributes() {
  return ['initials'];
}

// This will run only when our 'initials' attribute changes
attributeChangedCallback(name, oldValue, newValue) {
  // But for future-proofing, I'd like to check anyway
  if(name === 'initials') {
    // Get the avatar div from the shadow DOM:
      const avatar = this.shadowRoot.querySelector('.avatar');
        // Set the text to the attribute value:
      avatar.innerText = newValue;
        // And set the background color to the color from the getColorFromText method
      avatar.style.backgroundColor = this.getColorFromText(newValue);
  }
}

How to make a web component

Now you know how to make a simple web component! We've started by creating a class that extends the HTMLElement and telling the DOM that we have a custom element. Then, in the constructor, we do the initial set up for our component with the default markup and fallback background color. We used DOM methods that existed for quite some time that you might already be familiar with. Lastly, we made use of one of the built-in lifecycle methods of web components, in this case, the attributeChangedCallback which will fire any time one of our attributes is set or updated.

When I was looking into web components, I was surprised at how simple it was. It's not comparable to an entire framework, it's just a relatively small API that you can learn much quicker than Angular or React. However, the syntax can feel a bit clunky if you just get started. Also, it really helps if you are well versed in DOM manipulation (querySelector, createElement, innerHTML, innerText, that sort of stuff) because there will be a lot of that once you start writing web components.

In the end, it may be well worth learning. I'm seeing some large companies adopt this technology more and more. They can share components across teams, no matter the framework used. That is a big win for many. Imagine having to keep three component libraries up to date with the same components, but different frameworks.

If you want to learn more about web components, I'd recommend checking out the following resources:

The Ultimate Guide to Web Components

Lifecycle Hooks in Web Components

webcomponents.org

The Story Behind Snippet Shot: A Code Screenshotting Tool

Marco Slooten — Mon, 27 Jul 2020 13:50:27 +0000

I wanted to create my own code screenshotting tool, where I could easily paste a Gist URL and end up with a beautiful image of the code. Over the weekend I made the bare-bones version and during the week I refined it a bit. In this post, I want to explain how I approached it, the choices I made, and how the tool works.

Why no existing solution?

There are excellent tools out there, most notably carbon.now.sh. However, I wanted to make it simpler and have it customized to my personal wishes. For me, pasting a Gist URL and picking a gradient were the most important parts. Yes, I know Carbon supports Gists (you have to append the ID to the URL) but I wanted something more obvious.

Also, this presented me with a good opportunity to brush up on my React-skills. I've been writing Angular professionally for the last year and a half, so I hadn't even worked with React hooks yet!

From idea to execution

I started with create-react-app for the bare bones. Then I added TailwindCSS for styling and started hacking it together. I recently worked with Tailwind on my personal website and really liked it, so I decided I would use it here too.

Soon, I needed to display code. I had used CodeMirror in a previous, unfinished, side-project so I knew that was a good starting point. CodeMirror is basically an online code editor with syntax highlighting. Then I needed something to generate an image from HTML. I looked at Carbon and they were using dom-to-image, which was also one of the packages I could find with a quick Google search. I added it to the stack and was able to download some code screenshots shortly after.

The next part was adding the background gradient. I like the palette that TailwindCSS offers, so I decided that should be the base colors for the gradient. I iterated over the colors names combined with the intensities (100-900). Then I added blocks of color where you could click two in order to generate a gradient.

The rest was lots of testing and tweaking. I needed to make it hi-res so I had to do some scaling on the DOM element to make it 2x. There are also some options which I added. And I needed to pull the contents of a Gist, which I did with fetch().

After running Lighthouse I figured I could gain some more speed by using Next.js. That was true, after integrating it I gained 10 points on performance even though it's a super simple one-pager.

Takeaways

Hopefully, this post sheds some light on how I approach new ideas. I start with things I know but also take some liberties to explore new stuff. If I'm stuck, I will Google and I will look at how competitors solved issues. This way of working is quick and very educational. You're staying with one foot in your comfort zone, giving you confidence and speed, and with the other foot in new territory where you can learn a lot!

I can highly recommend this approach. For launching this as a product, that's another story! On a whim, I threw it on ProductHunt (click here to view or upvote) but I had no plan in place so it's not optimal. If I planned this, I would have asked my friends and colleagues to upvote. Instead, I just did it and got some upvotes organically.

Snippet Shot

I'm curious to hear your thoughts! Here's another example of a Snippet Shot I made:

Feedback is very welcome, and so are collaborators Github.

You can check it out at snippetshot.com.

How to use recursion in JavaScript?

Marco Slooten — Mon, 29 Jun 2020 09:46:32 +0000

What is recursion in JavaScript?

When were talking about JavaScript, recursion means a function that calls itself (again). Note that it's not reserved for programming: you can even do recursion with a little story. There's a pretty good example of that floating around the internet:

A child couldn't sleep, so her mother told her a story about a little frog,
    who couldn't sleep, so the frog's mother told her a story about a little bear,
         who couldn't sleep, so the bear's mother told her a story about a little weasel...
            who fell asleep.
         ...and the little bear fell asleep;
    ...and the little frog fell asleep;
...and the child fell asleep.

Source: https://everything2.com/title/recursion

This is a sentence that keeps repeating itself, with just the animal changed. Once it reaches a certain condition (being asleep), it passes that value back to the parent function, until it's reached the final (first) function. You can view it as a function that keeps on doing a thing, until the desired outcome is reached. Then it passes that outcome back to the initial function.

Don't worry if this sounds vague. Just remember that recursion is a function calling itself from within the function.

When to use recursion?

Can't I just use a loop?

In almost every case, you can use a while loop instead of recursion. There are some situations that are more suited to recursion than others though. For now, the important take away is: yes, in many cases you can use a loop, but in some cases recursion is preferred. Once you get the hang of it, you will find that recursion can be a pretty elegant concept that's often clearer than a while loop (in my opinion anyway).

A recursion example with JavaScript

Let's look at an example where I think recursion shines. We have to generate a list of (pseudo) random numbers with 5 digits. It will be the passcode you have to say at the door to get into this exclusive party! The bouncer can never remember all the codes, but he's got a calculator. He asks you to make sure each number is divisible by 11. That way, he can always check if he is given a valid number.

There may be math tricks to come up with seemingly random numbers that are divisible by 11, but we're going to brute force it. One out of 11 numbers randomly generated will be divisible by 11, right?

First, create a function that returns a random number with 5 digits. That means it has to fall between 10,000 and 99,999:

Generating a random number between two values

function generateNumber() {
  return Math.floor(Math.random() * 90000) + 10000;
}

Here, we generate a random number between 0 and 1 and multiply it by the difference between our min and max + 1. The highest value is just below 90,000 (Math.random() will never return 1) and the lowest is 0 (it can return 0). We round it down because we don't need any decimals and add the missing 10,000 back. Now we have a number between 10,000 and 99,999.

We need 100 passcodes for the party, so let's generate them and store them in an array:

const passcodes = [];

for (let i = 0; i < 100; i++) {
  passcodes.push(generateNumber());
}

This will give us 100 numbers, but not the just the correct ones. We need to check if the random number meets our condition. Let's modify the generateNumber function:

function generateNumber() {
  const number = Math.floor(Math.random() * 90000) + 10000;
  if (number % 11 === 0) {
    return number;
  }
}

Now it uses the modulus to check if the number is divisible by 11. The modulus keeps dividing by 11 until the remainder is smaller than 11, and returns that value. So for a number to be divisible by 11 (no decimals), it needs to return 0. Want to know more about the modulus? I wrote about creating random avatar colors with the help of the modulus.

The problem with the above function is that when the number isn't divisible by 11, it returns 'undefined' (which is the default return value for any function). So we will end up with an array with a bunch of empty spots and just a handful of numbers. Instead, I want to modify my function so that it returns a number that meets my requirements every time!

Adding recursion to our function

We already have the 'success' condition defined (a number divisible by 11), so we can use the good old 'else' clause to do something if we get the wrong number. If the number isn't correct, I want to generate another one. Even though we're inside of the generateNumber function, we can actually call it again – we can add recursion to it!

function generateNumber() {
  const number = Math.floor(Math.random() * 90000) + 10000;
  if (number % 11 === 0) {
    return number;
  } else {
    return generateNumber();
  }
}

What you see here is that I call the same function, and return it. We're now one level deep.

Let's call the first function call the 'parent' and the second function call, made from within, the 'child'. When the child does generate a number divisible by 11, it will return that number.

The parent function receives that value in the place where the child function was called (on the line return generateNumber()). The parent will then also return the value it was given from the child. Now, in the place where we originally called the function the first time, we will receive that number and we can store it in the array.

So we call one function ourselves, and that one function can call itself again from within, if it's needed. The child will pass back the value to the parent, who will pass it back to where it was called. This goes as deep as it needs to go. If the child does not have the right number, it could do another function call. If that one doesn't have the right number, it could also do another function call. This can go on until we meet our condition (divisible by 11), then we return a value which gets passed back.

Warning: You could easily create an infinite loop here if you don't have any conditions. If we didn't have the if statement, we would keep going until we run out of resources and crash our browser.

If this seems confusing I don't blame you. You don't often see recursive code and it takes some mental gymnastics to grasp it. If it's not clear, I've got another example. Otherwise, feel free to skip to the end!

Another (code and non-code) example of recursion

Let me give you another example to make it more clear:

Imagine yourself at a dinner where you are seated at a large table. You ask the person sitting to your right to pass the breadbasket. If that person has the basket within reach, she will pass it back to you. If she doesn't, she will ask the person sitting to her right. This goes on until we find the person with the breadbasket within reach. They will pass it back the person on their left, who will also pass it on, until it reaches you.

If we were to convert this to code, it might read something like this:

function passTheBreadBasket() {
  if (basketIsInReach === true) {
    passItToThePersonWhoAskedMe();
  } else {
    askAnotherPerson();
  }
}

So each person that is asked for the basket, is a function call. They have to 'decide' if they can pass you the basket directly, or if they have to ask someone else and wait for their response. If it's far away, you may well have five people waiting on the basket to pass it back to you.

The same thing is happening in our function:

we have a task
if we can complete it directly, we will
if not, we will try again (ask another person / run another instance of the function) until we can complete

So instead of thinking of recursion as 'going deeper' or 'nesting', you could also look at it like a horizontal line where you make a request going right, and the response will come back to you (going left).

Summary and takeaways of recursion

If your head hurts right now I don't blame you. Recursion is really something that takes a little while to grasp. That's totally normal. By now you have seen a few examples of it and perhaps you can already envision some use cases. To finish, I'd like to summarize recursion one last time:

recursion is the process of a function calling itself
it has to have a defined end condition that can be reached with certainty, because
it's easy to create an infinite recursion by accident and crash your application
it will pass back the right value immediately, or it will call itself again until it does have the right value

I'd love to hear your use cases for recursion if you can think of any. It would also be a cool exercise to recreate our number-generating function without recursion, using a while-loop for instance.

Use CSS Grid To Create A Stacked Bar Chart

Marco Slooten — Sat, 20 Jun 2020 11:29:04 +0000

I was recently asked to build a (percentage) stacked bar chart. This type of chart is an alternative to the classic pie chart. One of the advantages is that it takes up way less space in one direction. This is what we will build:

Now you could try to make this with an existing chart library, but that feels like overkill. Besides, it's simpler to roll our own in this case. And we get to use a cool 'trick' with CSS Grid! 🔥

Building the chart basics

Let's say we want to track which types of fruit are consumed in the office and how popular they are. First, create some HTML:

<div id="fruit-meter">
  <div id="apples">20</div>
  <div id="bananas">5</div>
  <div id="peaches">10</div>
  <div id="cherries">2</div>
  <div id="grapes">12</div>
</div>

For each type of fruit I have a div with the absolute number of those sold, and a wrapper with an id of 'fruit-meter'. The mathematicians amongst us will have noticed these numbers don't add up to 100. Don't panic, that's the point: we're going to fix it with grid later. For now, let's start by giving these boring divs some color (I took these HEX codes from Tailwind CSS, which I used to prototype this):

#fruit-meter {
  border: 2px solid white;
  border-radius: 5px;
  overflow: hidden;
}

#apples {
  background: #48bb78;
}

#bananas {
  background: #ecc94b;
}

#peaches {
  background: #ed8936;
}

#cherries {
  background: #e53e3e;
}

#grapes {
  background: #805ad5;
}

I'm giving the wrapper div ('#fruit-meter') a white border (useful when used on darker backgrounds), a border radius and an overflow of hidden. The last bit is so that it will also round the corners of the colored divs, which otherwise will stick out.

Right now, it should look something like this:

Use CSS Grid to create a horizontal layout

Time to see what CSS Grid can do for us.

#fruit-meter {
  border: 2px solid white;
  border-radius: 10px;
  overflow: hidden;
  /* New code below: */
  display: grid;
  grid-template-columns: 1fr 1fr 1fr 1fr f1r;
}

OK, so now it's starting to look like a stacked bar chart. display: grid enables grid styling. grid-template-columns is responsible for creating columns in our grid. I've added 5 columns (or tracks) with a size of '1fr' each.

fr stands for fraction and it is calculated by CSS Grid. It divides the available width by the sum of all fractions I've defined. That will be the width of '1fr'. So the above code means that all columns will have 20% of the available width as their size.

If I would have had three columns and grid-template-columns: 2fr 2fr 1fr, that would still add up to 5 and it would result in two columns of 40% width each, and one of 20% width.

Here's another example where you can visualize how grid works:

You may have noticed something useful: normally we would have to calculate the percentages in order to get the correct widht. Now, we can let CSS Grid calculate that! I can write grid-template-columns: 23fr 70fr 10fr 123fr and it will work just fine. So let's put the number of fruits sold in fractions:

grid-template-columns: 20fr 5fr 10fr 2fr 12fr;

Lastly, let's style those numbers a bit (or leave them out of your HTML entirely, up to you!):

#fruit-meter div {
  color: white;
  font-family: sans-serif;
  font-weight: bold;
  font-size: 12px;
  line-height: 20px;
  display: flex;
  align-items: center;
  justify-content: center;
}

If you followed along, you should end up with this cool stacked bar chart:

Conclusion

CSS Grid can be used to help you make (stacked) bar charts pretty easily. The magic lies in using the raw numbers as the fractions (fr units) in grid-template-columns to automatically size them. After making this chart, a vertical one is pretty easy too (just replace grid-template-columns with grid-template-rows and give the wrapper a certain width)! What other creative uses for CSS Grid can you think of?

Like to see more tutorials and tips like this? Sign up for my newsletter on my website: marcoslooten.com!

Dealing with spammy newsletter subscribers: The first battle

Marco Slooten — Fri, 05 Jun 2020 22:06:38 +0000

Originally published on https://marcoslooten.com/blog/dealing-with-spammy-newsletter-subscribers/

When I updated my personal website, I added a mailing list signup form. I wanted to be able to update people when I post new stuff and this seemed like a good way. But after the first day I already had a lot of subscribers. Great! What am I complaining about?

They're fake.

I didn't really announce my website update and looking at the analytics, a large portion of visitors signed up for my mailing list. If you do some research on conversion rates, you'll find out quickly that almost everything is below 5% conversion rate (for a newsletter, I'd be extremely happy with 1%). But more than 50% of visitors were signing up for the newsletter!

A quick glance at the subscriber list confirmed my suspicions: most email addresses looked fake. One of the tells is an address with random numbers. So marco9873245@gmail.com is probably fake. marcoslooten.com@somedomain.com obviously too. Some are more realistic though, following a very clean format like [firstname].[lastname]@[gmail or yahoo].com.

It's a fact of life that when you place a form on the internet, some bot is going to find it and fill it with spam. For mailing lists, that's especially bad. Fake subscribers means that the deliverability of your mails may suffer and (if you care about that sort of stuff) metrics such as open rate will be unreliable.

Time to battle these spammers.

Filtering the subscribers out after the fact is hard. Some of the fake email addresses are pretty convincing and the last thing we want is to remove actual subscribers. I wanted to prevent it as much as possible. One tactic is to use a captcha, where the user has to type over letters from an image or click squares with traffic lights. I did not want that. It's a horrible user experience and the code needed may slow down the page. The sign up form is on every page on my blog, so that would be pretty bad.

The Classic Honeypot

As my first tactic, I opted for the classic honeypot.

I remember using plugins that added a honeypot to forms in WordPress almost a decade ago. But the principle is still solid: you add a field in your form, and you make it invisible with CSS (display: none). Anytime that field gets filled in, it must be a bot because no actual person filling in the form will see it.

Depending on how you handle the form, you could stop the form from submitting or you could go to your email software and manually delete anyone who has the honeypot filled in.

This (still) works very well. In order to tell the form is hidden, the bots would have to load the CSS and parse the page in a more expensive way. I suspect this will stop most of the spam. The first results are encouraging. In my mailing list software (I use buttondown.email) I tagged them with the tag named 'confirm'. I named it that way because it also shows up in the form HTML and I want to encourage the bots to definitely check that checkbox!

You can see from the moment I added the honeypot, I started to get subscribers with the spam tag. Since making the screenshot and writing this sentence I already got two more.

What's next?

Now that I have confirmed this is working, the next step would be to prevent the form from submitting altogether. Currently I need to manually clean them out and that is not really nice. But I will monitor this situation a little longer to see just how effective it is.

If you want to stay up to date with my battle against the spambots in my mailing list, you can sign up for that very mailing list on marcoslooten.com 😃

State Machines: A Simple Introduction

Marco Slooten — Mon, 24 Feb 2020 21:20:10 +0000

This post is also published on my website: https://marcoslooten.com/blog/state-machines-a-simple-introduction/

State machines are a very useful concept to help write reliable software. By reducing the number of possible states and controlling transitions between states, your application will be more predictable, reliable and easier to work on. But I can’t help notice that some people are deterred by the name and think it’s all very complicated, or even that it’s not useful for them. I had heard about state machines some time ago and was intrigued, but somehow didn't really think it was that useful for me. Spoiler alert: I was wrong.

What problem are we trying to solve?

Let's highlight an actual issue I ran into a while back (note: this app was not in production yet). I was tasked with adding a form to a page. Simple enough, I added a form and slapped on the button we already had in our component library; happy I was able to reuse something. Everything was fine and we merged it. A couple of days later, our product owner approached the team and showed us something: he was using the form, but instead of saving it once, he kept clicking the button rapidly. I instantly knew I messed up: it kept saving the same data to the backend, which was responding slower and slower every time he'd hit 'save'.

Back to the drawing board then! I added a 'loading' state to the button using a boolean. When we received a response from the backend, only then would 'loading' be false again. In the meantime, I prevented any click event while the button was in the 'loading' state so that it was not possible to submit the form multiple times. Once again my code got reviewed and merged.

About a week later I get approached again. The requirements changed. At first, all form fields had to be optional. Now, you had to have a certain combination of fields filled in. Otherwise, our database would fill up with empty forms. A new ticket was created and I got to work. Now I had to add a 'disabled' state to our button. This is the point where I started to sense that the code was becoming more complex and harder to maintain.

I now had two booleans, yielding four combinations (true - true, true - false, false - true, false - false), but I thought we would probably be adding a 'success' state to the button in the near future. Then I'd have three booleans and eight different combinations. What if we would add a couple more booleans to the button? For instance, another loading state if things were taking really long ('This is taking longer than expected...') and a failure state if the network request failed? The possible combinations of booleans would skyrocket. Six booleans would already yield 64 combinations! Look at the following (pseudo) code that saves the form:

let loading = false;
let success = false;
let disabled = false;
let failure = false;
let loadingLong = false;

submitData() {
  if (
    loading === false && 
    disabled === false && 
    loadingLong === false
  ) {

    loading = true;
    setTimeout(() => {
      loadingLong = true;
    }, 5000);

    // make the actual POST call
    // Check return data

    if (data.success) {
      loading = false;
      loadingLong = false;
      success = true;
    }

    if (data.error) {
      loading = false;
      loadingLong = false
      failure = true;
    }
  }
}

You can see how this can get out of hand: I have to make sure I have the right combination of booleans before doing something, and I have to make sure I modify them all correctly when something changes. It's so easy to introduce bugs here, simply because I might forget to update a boolean or I forget to check one. It also gets unreadable pretty quickly.

State machines can help fix these problems:

it can reduce the number of possible states (no longer 64 possible combinations because we used booleans)
it can control the transitions between states (so that we no longer have to think about resetting all the other booleans)

Let's dive a little deeper into both.

Reducing the number of possibles states

In the above example, I have a button that has a number of states we (explicitly) defined:

loading
loading long
disabled
success
failure

It also has an implicit state: the 'default' state. In the above example, we're in the default state when everything is 'false' and then it's just a regular button.

So that makes six states. Notice how we have defined five booleans. That gives us 2 ^ 5 = 32 combinations of booleans. But note that I'm only interested in six distinct states. I don't really care about the other combinations that might exist. If the button is 'loading', the other states don't matter to me – it simply must look and act like it's loading. When people talk about state machines, they're most likely talking about finite state machines. This is exactly what's going to help us here. I only care about six possible states. Why express that with booleans? Let's just introduce a single state variable and have that be the ultimate source of truth, rather than some arbitrary combination of booleans:

let buttonState = 'loading';

If you're using TypeScript you could give it an enum with the possible state values to enforce the right strings, but even without enforcement, this is way cleaner. Now our application can have much better logic:

switch(buttonState) {
  case 'loading':
    // do stuff, e.g. prevent clicks
    break;
  case 'failure':
    // do stuff, e.g. show error message
    break;
  // ... etc
}

In most cases, we only care for a particular set of states. Defining those and having a single variable holding that state reducing the complexity immensely, in our example going from 32 to six states. Every code that is dependent on that state can be written to be much more simple and robust, thereby prevent bugs and making the development less intimidating.

Controlling state transitions

We talked about the benefits of finite states. But that still leaves the door open for certain errors. For instance, in the button example, can you go from 'failure' to 'success'? From 'loading' to 'disabled'? From 'success' to 'loading'? There's nothing that will keep that from happening in the current situation. That's where the machine can help us.

We can make a state machine responsible for all transitions on the state of our button. For actually implementing this, have a look at the excellent XState. I've created a simplified button state machine with four states (idle, loading, success and failure). Our machine object may look like this:

  const buttonMachine = Machine({
    id: 'button',
    initial: 'idle',
    states: {
      idle: {
        on: {
          CLICK: 'loading'
        }
      },
      loading: {
        on: {
          RESOLVE: 'success',
          REJECT: 'failure'
        }
      },
      success: {
        type: 'final'
      },
      failure: {
        on: {
          RETRY: 'loading'
        }
      }
    }
  });

Don't be intimidated by that, there are just a few things you need to know. This state machine has, on the top level, three properties:

id (to uniquely identify it, irrelevant for now)
initial (the state it starts in)
states (another object holding the different states)

The property 'states' is another object with all of the possible states defined, in this case idle, loading, success and failure. You can make up what they are called here, as long as it's a valid Javascript object property. Within each state, there's an 'on' key. This is where XState will look for transitions. Transitions are the capitalized words and define the next state when that transition happens.

Say we're in the default 'idle' state. Looking at the available transitions, I see 'CLICK' as the only one. The value of 'CLICK' is 'loading'. This means that when I'm in the idle state I can only transition to 'loading', and it only happens when I provide the machine with the right event ('CLICK'). This is done like so:

  const initialState = buttonMachine.initialState;
  const nextState = buttonMachine.transition(initialState, 'CLICK');

Fortunately, there's an easier way to look at this machine. Go ahead and copy the state machine above, and then go to the XState Visualizer, paste it in on the right and click on 'UPDATE'. Now you can see your state machine and even interact with by clicking on the events. Here's how my button state machine looks:

By making XState responsible for all state and state transitions, you can never end up with a state that you haven't explicitly defined. It's also deterministic: the state is a result of the previous state and the event. Given the 'idle' state, the 'CLICK' event will always give us the 'loading' state. There's no ambiguity there, making state transitions relatively painless.

Recap

The problem of having a naive form of state management, for instance by using lots of booleans, can be solved by using state machines. When we define a limited (finite) number of states, we reduce complexity and increase reliability. When you combine that with making the state machine responsible for the transitions, you make it so much more robust. It ensures you only ever have one state at a time, that it's one of your predefined states and that it's only possible to transition from a certain state to another if we explicitly enable that. It also makes testing easier and has a number of other benefits.

I highly recommend checking out XState and trying to use it in your next project if it involves anything more complex than a single boolean!

Recommended reading:

Follow David Khourshid (creator of XState) on Twitter and read everything he publishes if you want to know more about state machines
Enumerate, Don't Booleanate by Kyle Shevlin
State Machines in React by Dave Geddes
Implementing a simple state machine library in JavaScript by Kent C. Dodds

Header image by Franck V. on Unsplash

Want to keep up to date with articles like this? Please subscribe to my newsletter on marcoslooten.com.

Creating Avatars With Colors Using The Modulus

Marco Slooten — Mon, 07 Oct 2019 06:58:31 +0000

This post is also published on my website https://marcoslooten.com/blog/creating-avatars-with-colors-using-the-modulus/

Recently I needed a flexible avatar component for an admin-type dashboard. Administrators should see avatars of all the users under their control. Ideally, the avatars would show pictures of the users, but not everyone will want to upload their photos to the web app. It needed a fallback (that probably will be used more than the photo-version) without images. We will build a basic avatar version that's already pretty cool!

First, we'll be creating a plain HTML and CSS avatar component. Then we will switch to JavaScript and make the color dependant on the initials provided.

HTML and (mostly) CSS

We are going to create the basic structure and styling of the avatar. The HTML is just a div with a class and the user's initials inside: <div class="avatar">AA</div>. It doesn't look like much now, but wait until we apply some CSS!

Let's start with defining a width and height to make them square. Then we'll add a background color (gray, as a fallback), make it round and add some text styling:

.avatar {
  width: 52px;
  height: 52px;
  background-color: #ccc;
  border-radius: 50%;
  font-family: sans-serif;
  color: #fff;
  font-weight: bold;
  font-size: 16px;
}

It's starting to look like an avatar, but the text isn't centered. Now we could use the traditional way to center (using a combination of text-align and setting a fixed line-height), but that technique does not really scale. If we want larger avatars, we'd have to update the line-height again. I decided to use flexbox for this since it will always work regardless of the dimensions. Add the following lines to make it 1. flex, 2. horizontally aligned and 3. vertically aligned:

.avatar {
  /* ... */
  display: flex;
  align-items: center;
  justify-content: center;
  /* ... */
}

You can put it anywhere in the .avatar-class, but as a guideline I prefer to have positioning rules just below the width and height, and before any color or text styling.

Enough talking, how does it look now? I've put a couple of them side by side to have a look:

It looks like an avatar alright, but there's also an issue that becomes apparent: all users look alike except for their initials. I really want them to have different background colors to be able to better distinguish them.

So how do I determine which background color? At first, my reaction was to just make it random. The colors have no special meaning in this case, so in a way it made sense. But do I really want it random though? Every time someone logs in, the colors would be different. That's not a desirable quality in this case. Should I store the generated values to a database then? It seemed like overkill for something like this. Instead, I decided I did not want them to be totally random; I just wanted them to look random. But I want the initials 'AA' to give the same color every time, for every user. Since it's a web app, already using JavaScript, I decided to write a function to assign a color from a predefined list.

Enter JavaScript

We are going to write a pure function. A pure function is a function that given the same input, always gives us the same output. It should also not have side-effects. If you want to know more about pure functions I recommend this article: What Is A Pure Function In JavaScript. For us, the important part is that the function will always return the same value given the the same input. The initials 'MJ' should always return the color '#E3BC00' for instance.

First up, we need to have a list of colors. Here's an array with the HEX color values. You can copy that or create a much larger list if you want. Since we have 26 letters in the alphabet and typically two initials shown in an avatar, that means we have two spots with 26 letters, which yields 26 * 26 = 676 unique combinations. You could provide as many colors like that but it might be a bit overkill. I decided seven was more than enough:

const colors = ["#00AA55", "#009FD4", "#B381B3", "#939393", "#E3BC00", "#D47500", "#DC2A2A"];

In order to set the background color of the avatar, we have to pick a color from that list and return it. To return the second color, we would use colors[1]. Next, we need a way to convert our initials to a number between 0 and 7.

Let's start by converting our text to a number. Luckily, there's a function in JavaScript that converts a character to a character code: charCodeAt(). It only gives one number per character, so we need to iterate over our initials. To do so, we create the following function:

function numberFromText(text) { // numberFromText("AA");
  const charCodes = text
    .split('') // => ["A", "A"] 
    .map(char => char.charCodeAt(0)) // => [65, 65]
    .join(''); // => "6565"
  return charCodes;
};

It's a function that takes one argument, a string which we will name 'text'. Then, we split that string, using split(''). The empty string as argument for split means it will split the string at each character, outputting an array of characters like this: ['A', 'A']. The next step is to transform each array element to a charcode, which we'll do using map. We can chain .map to .split because the latter returns an array. With map we can transform each element in the array. In the arrow function we get the array value and on the right hand side we return a value, which is the character code. Now, we have an array of character codes. Lastly, we join it together using an empty string as the 'glue' that joins the elements together. Now we have "6565". Notice the quotes, it's a string. We can use parseInt to return a number by modifying the last line:

return parseInt(charCodes, 10);

Picking Array Items With The Modulus

Ok, great, that was a lot and now we have 6565. Our array, however, only has 7 items in it. This is where the modulo operator comes in (this one: %).

If we have the following statement: 6565 % 7, the modulo will first check how many times 7 fits into 6565 completely (so no decimals). Then it returns what remains after that division. 6565/7 = 937.8... So 7 fits fully 937 times. That's 6559 (7 times 937). When we subtract that from 6565, we end up with 6 (this is called the modulus). The modulo operator will always return a value between 0 and the value on the right side minus one. In this case, between 0 and 6.

Using the modulo we can use any number we want and make sure it sequentially picks an item from the array. A perfect way to get a color based on your initials! Let's see how we can use that to get a color from the array using initials:

colors[numberFromText('AA') % colors.length]; // => '#DC2A2A'

Let's examine the stuff within the square brackets first: numberFromText('AA') returns 6565. colors.length returns 7. If we take those values and calculate it, using the modulo operator, 6565 % 7 returns 6. The entire statement within the square brackets returns 6. You can now see the similarity to the example at the start (colors[1]); in this case, it's colors[6] and it will return the 7th array element (at index 6), which is #DC2A2A. Check it out with other values, it will always give us an element from the array and it will always be the same given the same input ('AA' always returns #DC2A2A, etcetera).

Awesome! Now we can finish it off by returning a color and modifying the HTML elements:

const avatars = document.querySelectorAll('.avatar');

avatars.forEach(avatar => {
  const text = avatar.innerText; // => "AA"
  avatar.style.backgroundColor = colors[numberFromText(text) % colors.length]; // => "#DC2A2A"
});

First, we're getting the avatars from the DOM. This is now a NodeList, which is similar to an array but we can't use stuff like map. Fortunately, .forEach is available to us. In that function, we read the innerText property of the .avatar DOM-element and store it in a constant called 'text'. This gives us the text of the avatar (in this case the initials). Then we modify the backgroundColor property directly, setting it to the value returned from the function we just created. Now your avatars should have cool colors.

That's it! We're done, our avatars now look like this:

Here's the full code:

HTML:

<div class="avatar">AA</div>

CSS:

.avatar {
  width: 52px;
  height: 52px;
  display: flex;
  align-items: center;
  justify-content: center;
  background-color: #ccc;
  border-radius: 50%;
  font-family: sans-serif;
  color: #fff;
  font-weight: bold;
  font-size: 16px;
}

JavaScript

const colors = ["#00AA55", "#009FD4", "#B381B3", "#939393", "#E3BC00", "#D47500", "#DC2A2A"];

function numberFromText(text) { // numberFromText("AA");
  const charCodes = text
    .split('') // => ["A", "A"] 
    .map(char => char.charCodeAt(0)) // => [65, 65]
    .join(''); // => "6565"
  return parseInt(charCodes, 10);
};

const avatars = document.querySelectorAll('.avatar');

avatars.forEach(avatar => {
  const text = avatar.innerText; // => "AA"
  avatar.style.backgroundColor = colors[numberFromText(text) % colors.length]; // => "#DC2A2A"
});

Recap

We created a custom avatar by starting with HTML markup to give it structure. Then we added CSS to make the div square, round the corners, give it a background color and some text styling. After that, we went on to JavaScript. We made a pure function that returns a number, which is the character codes for the input string glued together. Then, using the modulo operator, we got a color value from the array of colors and assigned it to the avatar in the DOM.

This is one of the many use cases of the modulus. I always find it cool if I get to use it. Do you use the modulus in your code, and what does it do? Let me know in the comments or on Twitter. Thanks for reading!

Want to keep up to date with articles like this? Please subscribe to my newsletter on marcoslooten.com.

Destructuring Objects in JavaScript

Marco Slooten — Wed, 11 Sep 2019 07:31:10 +0000

This post is also published on my website -https://marcoslooten.com/blog/destructuring-objects-in-javascript/

Just like array destructuring, object destructuring is a cleaner and more concise way to assign values from an object to a variable. If you haven't yet, I recommend you check out my previous post on array destructuring (but it isn't necessary to follow along). Let's explore object destructuring.

Assign Values to Variables

const lunch = {
  starter: 'Soup',
  main: 'Avocado toast', // I'm a millenial so I kinda have to =)
  drink: 'Beer'
}

We have a lunch order from a restaurant. The items need to be saved in their own variables for easier use later on. You could use the dot or bracket syntax for that:

const starter = lunch.starter;
const main = lunch['main'];

For this, destructuring is a bit cleaner syntax. In the next example, I'm destructuring the entire object to separate variables. Because it's an object, the left hand side of the declaration needs to resemble an object too, like so:

const { starter, main, drink } = lunch;
// starter => 'Soup'
// main => 'Avocado toast'
// drink => 'Beer'

You are not actually declaring an object, it's just the destructuring syntax. The example above is typical usage of object destructuring, but it's also a little confusing. That's because it uses object shorthand notation, which means the key from the object you are using will also be the name of the variable. What's happening in the example is that we take the value from the key 'starter' (so that's order.starter or order['starter']), and assign that to a variable that's also called 'starter'. This helps you to prevent repeating the same name (const { starter: starter } = order;), which can be convenient, but not always.

Assigning Values to Different Named Variables

Now this might be a little confusing, because the syntax is as follows:

const { keyFromObject: newVariableName } = object;

I think this may take a while to get, at least it did for me. You actually need to have the key from the object as the key in the assignment and the new name as the value of that. Most of us are used to the left hand side of things being a variable name (think of declaring new variables, you'd have const name = 'Marco'). But in destructuring an object, you need the key from the target object first (before the colon) to get the value you want. Then you assign the variable name as the value on that key (after the colon).

const { main: mainMeal, drink: beverage, starter: starterMeal } = lunch;
// starterMeal => 'Soup'
// mainMeal => 'Avocado toast'
// beverage => 'Beer'

One of the advantages of objects over arrays is that the order does not matter. The same goes for the destructuring, as long as the key matches to a key in the object. In the above example I switched around the order and it works just fine. Skipping items is very simple, just omit them!

Assign Only Some Values, Keep The Rest

Like array destructuring, object destructuring supports the rest operator (...) to enable you to store everything you don't want to destructure all at once.

const { starter: starterMeal, ...restOfMeal } = lunch;
// starterMeal => 'Soup'
// restOfMeal => { main: 'Avocado Toast', drink: 'Beer'}

The rest-variable will then contain an object with all the remaining key-value pairs. This is useful if you need some values from the object, but want to keep everything you didn't assign for later use. If you had to use the original object, you would still have the old values you already destructured in it. That makes it hard to keep track of the values that matter to you. Using the rest operator resolves that, giving back an object with just the values that weren't destructured.

Nested Objects

With object destructuring, you have a nicer syntax to get specific values from an object. So how do you destructure from more complex, nested objects? Take a look at the following lunch order. It's an object with a nested object ('food') and an array ('drinks').

const lunch = { 
  food: {
    starter: 'Soup',
    main: 'Avocado toast'
  },
  drinks: [
    'Beer',
    'Water'
  ]
};

Remembering that object destructuring syntax needs to follow the structure of the object, let's try to create that on the left-hand side:

const { food: { starter, main }, drinks } = lunch;
// starter => 'Soup'
// main => 'Avocado toast'
// drinks => ['Beer', 'Water']

What happens here is that food: finds the key 'food' within the object. Now we have access to our sub items 'starter' and 'main'. Then you can access them just like you would a simple, one-dimensional object. Don't forget the closing curly bracket! This syntax can get a bit confusing quickly though. There's always the dot-syntax (or bracket syntax) as a backup:

const { starter, main } = lunch.food;
const { drinks } = lunch;
// starter => 'Soup'
// main => 'Avocado toast'
// drinks => ['Beer', 'Water']

Say we only want to destructure from a specific sub-object, we can do it like the above example. Although it combines destructuring and the old dot-syntax, I prefer it slightly to 100% destructuring for complex objects. I personally think it's a little more readable. But both aren't wrong, so feel free to choose the syntax you're most comfortable with (or the one your team dictates). If you find you're going multiple levels deep, that's probably a sign that you're trying to destructure too many things at once.

Cheat sheet

Object destructuring is pretty cool and I think it might be a little bit simpler than array destructuring. Still, I want to recap with a simple overview of the possibilities:

// Using shorthand notation
const {a, b, c} = {a: 1, b: 2, c: 3};
// a => 1, b => 2, c => 3

// Using named variables
const {a: first, b: second, c: third} = {a: 1, b: 2, c: 3};
// first => 1, second => 2, third => 3

// Storing the rest
const {a, ...others} = {a: 1, b: 2, c: 3};
// a => 1, others => {b: 2, c: 3}

// Nested objects
const obj = { parent: { a: 1, b: 2, c: 3 }, anotherParent: { d: 4, e: 5 } };
const {parent: { a, b, c }, anotherParent: { d, e } } = obj;
// a => 1, b => 2, c => 3, d => 4, e => 5

// Combining shorthand, naming, rest and nesting:
const obj = { parent: { a: 1, b: 2, c: 3 }, anotherParent: { d: 4, e: 5 } };
const { parent: { a: newName, b}, anotherParent: { ...anotherParentValues} } = obj;
// newName => 1
// b => 2
// anotherParentValues => { d: 4, e: 5}

PS. If you'd like to keep up to date with my posts about front-end (HTML, CSS, JS) and career advice, you can subscribe to my newsletter: Subscribe to my newsletter here

Destructuring Arrays in JavaScript

Marco Slooten — Wed, 04 Sep 2019 15:47:03 +0000

This post is also published on my website https://marcoslooten.com/blog/destructuring-arrays-in-javascript/

Chances are you'll run into a situation where you want to store some array values in separate variables. Sounds easy enough, something like const secondValue = array[1] might come to mind. But there's a different way of doing that available to us: destructuring. It's a cleaner syntax, less confusing than the old way of doing it's shorter too. Let's see what we can do with destructuring.

Assign All Values to Variables

Say we have an array with the following elements (which are always in the same order):

const breakfast = ["Coffee", "Croissant", "Sunny side up"]

We need to store the values in separate variables for easier use later on. The 'old' way of doing it uses the index of the items, like so:

const drink = breakfast[0];
const bread = breakfast[1];
const eggs = breakfast[2];
// drink => 'Coffee'
// bread => 'Croissant'
// eggs => 'Sunny side up'

It's not too bad and there's nothing wrong with it, it's just that array destructuring is cleaner, more flexible and you are probably going to see more and more code use the destructuring syntax. Look at this one-liner:

const [drink, bread, eggs] = breakfast;
// drink => 'Coffee'
// bread => 'Croissant'
// eggs => 'Sunny side up'

That's way less code and very readable. You are declaring and assigning your new variables in an array because you are destructuring an array. The first array value will be assigned to the first variable, and so on.

Assign Only Some Items to Variables

Of course, we don't always want to use everything from the array. If we only need the first two items, it's easy enough to omit the last variable declaration and just assign to two variables. But what if you want the first and the third value, skipping the second? Look at this example omitting some values:

const [drink, bread] = breakfast;
// drink => 'Coffee'
// bread => 'Croissant'

const [drink, , eggs] = breakfast;
// drink => 'Coffee'
// eggs => 'Sunny side up'

In order to skip an element, you skip declaring and assigning a variable. In the first case, this is harder to see because the first elements are also the first two array items. But it's actually the same as const [drink, bread, ] = breakfast;, in other words, skipping the last item by having an empty spot in the array. In the second example, it's more clear because we're skipping the middle element. It looks a bit weird at first, but you'll get used to it quickly.

This image can help you visualize skipping items in destructuring:

Assign Some Items, Keep The Rest

Lastly, what if we got a lot of array items where we need to have the first three, but also want to keep the rest of the items in a variable to use later? Let's say we again have an array with the same three items, but also the time you ordered breakfast, the waiter who took your order, the total price and the number of your table:

const breakfast = ["Coffee", "Croissant", "Sunny side up", "08:38", "Sally", 9.15, 7];

We want to have three variables, one each for the first three items. We also need the rest, but without the first three items. We're also not concerned with storing the values in separate variables. In this case we can use the rest-operator (the three dots: ...):

const [drink, bread, eggs, ...meta] = breakfast;
// drink => 'Coffee'
// bread => 'Croissant'
// eggs => 'Sunny side up'
// meta => ["08:38", "Sally", 9.15, 7]

So now, the constant 'meta' will contain an array of all the remaining values of the original array that weren't destructured to their own variables. The rest operator and the variable it's used on need to be the last items in the destructuring. You can see it visualized here:

Bonus

Bonus: you can also swap variables with destructuring:

let x = 10;
let y = 20;

[x, y] = [y, x]
// x => 20
// y => 10

Recap

Here's a quick cheat-sheet of array destructuring:


// Assigning array items to variables
const [a, b, c] = [123, 'second', true];
// a => 123
// b => 'second'
// c => true

// Skipping items
const [,b,] = [123, 'second', true];
// b => 'second'

// Assigning the first values, storing the rest together
const [a,b, ...rest] = [123, 'second', true, false, 42];
// a => 123
// b => 'second'
// rest => [true, false, 42]

// Swapping variables
let x = true;
let y = false;
[x, y] = [y, x]
// x => false
// y => true

Want to keep up to date with articles like this? Please subscribe to my newsletter on marcoslooten.com.