Forem: Todd Carlson

Introduction to Agile

Todd Carlson — Fri, 18 Dec 2020 21:19:52 +0000

If you have looked for a software engineering position within the last 20 years, you have no doubt come across the word "Agile" in a job description. However, for people just getting into the field, this might be a foreign concept. If this sounds like you, you have come to the right place. I am devoting this week's blog post to the basic tenets of Agile project management.

So what exactly is Agile? According to https://www.atlassian.com/agile, "Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a "big bang" launch, an agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly." You can also read the original Agile Manifesto here, https://agilemanifesto.org/. Agile is a deep topic, but at its core it values four basic tenets which are: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a strict plan.

So what does valuing individuals and interactions over processes and tools look like? To me this means building projects around motivated individuals, and giving them the trust and support they need to do their jobs. It's not that there is no value in processes/tools, but when the two come into contact individuals and interactions should win out. An example of this might be that a team wants to use Node.js for their current project because they feel that it would be the best tool for the job. However, the project manager refuses claiming that the company is a "Rails shop." That is prioritizing process and tools over individuals.

In general, a lot of agile development is about removing the barriers between the developers, and the customers that they are building the software for. That's where valuing working software over comprehensive documentation comes in, or as I like to call it, "thin vertical slices." When we value working software instead of getting bogged down in waterfall bureaucracy, we keep the risk low and have it go with the value. With agile, we do some work which carries some risk, and then we deliver the value. After each new working feature is implemented the risk goes down because we have a working piece of software. This step by step, or thin vertical slices approach allows us to mitigate our risk by breaking it up into small and manageable pieces. This approach also allows for us to make changes to the project early on. Say you build out a feature, present it to the customer, and they completely change their mind. It's much nicer to find that out early on in the development process, instead of at the tail end of it. It's a lot easier to talk with the customer about what the software should be with the software right in front of you.

This segues nicely into customer collaboration over contract negotiation. What is meant by contract in this context is the actual contract between the client and the company, and also any kind of "get it writing" processes. An example of this would be a company that utilizes something like change request forms. Customer collaboration is the answer to this kind of telephone game. Instead of getting bogged down in an endless sea of phone tag and bureaucratic forms, the customer is in direct contact with the people building their software. The result is that while you are working with the customer they no doubt get new ideas. However, instead of being hindered by formalities, we value the organic evolution of the product with the customer in realtime. We want to be teammates with the customer, not micromanagers of every step of the development process.

I've saved the best for last. Responding to change over following a plan is the true heart of the agile philosophy. It's so important that you almost can't even talk about the the other agile tenets without talking about responding to change. To me this basically means that you have to address reality as you find it. A great example of this in action was when I was a student at the Flatiron School. Our lead instructor, who taught me everything I know about agile, would not plan the courses that he and the rest of the instructors would teach in advance. Instead, they would go into every standup completely fresh, and they would ask us where we were at, and what we needed help with. Only after finding out where we were on that particular day would they plan our courses for the day. The instructors may have had some ideas about what needed to happen, but they would throw those ideas out in a heartbeat the second that the reality of where the students were in their learning journey didn't coincide with their plans. That's what it means to respond to change over following a plan.

Agile is a deep, and very cool, topic. I hope this introduction has helped shed some light on the agile philosophy for those who may not have had any direct experience with it.

The Four Pillars of Object Oriented Programming

Todd Carlson — Fri, 11 Dec 2020 00:16:45 +0000

Whether you love, or hate, object oriented programming, "What are the four pillars of OOP?" will be a question you get asked on interviews again and again. I know this because a good friend of mine, who is a newly minted CS grad, messaged me upset because she completely blanked on this question during one of her interviews, and I was literally asked this question yesterday during a technical interview.

Just a quick disclaimer, this post is not an exhaustive and deep dive into the four pillars. I am merely providing quick "in a nut shell" explanations of the four pillars, with the sole aim of helping people answer this question when it inevitably comes up during an interview.

So what are the four pillars of OOP? They are Inheritance, Encapsulation, Polymorphism, and Abstraction. I will start with Encapsulation, which I believe is the real heart of OOP.
Basically, Encapsulation is keeping your state and behavior in the same place. I also like to think of it as a public contract with private implementation. For example, say you have a class called Customer:

class Customer
   def initialize(id, name, addr)
      @cust_id = id
      @cust_name = name
      @cust_addr = addr
   end
   def display_details
      puts "Customer id #@cust_id"
      puts "Customer name #@cust_name"
      puts "Customer address #@cust_addr"
   end
end

So, we have this class called Customer, with some instance variables, and a method that displays those instance variables. Those instance variables describe the state of our class, while the method describes the behavior. They are both "encapsulated" inside of our class. The public contract aspect of this that I mentioned earlier, means that this class is guaranteed to have this state and behavior. However, the private implementation aspect that I mentioned comes into play with how I choose to use the class. I could write new methods that display only one of the instance variables, or I could write new methods that add additional behavior. However, the main concept of Encapsulation is that state and behavior are in the same place.

Inheritance is a relation between two classes. We know that all dogs are animals. The benefit of inheritance is that classes lower down the hierarchy get the features of those higher up, but can also add specific features of their own. If all animals breathe, then all dogs breathe. In Ruby, a class can only inherit from a single other class. Some other languages support multiple inheritance, a feature that allows classes to inherit features from multiple classes, but Ruby doesn't support this.

class Animal  
  def breathe  
    puts "inhale and exhale"  
  end  
end  

class Dog < Animal  
  def speak  
    puts "Woof!"  
  end  
end  

doug = Dog.new  
doug.breathe  
doug.speak

Polymorphism comes form the greek words "polys" meaning much or many and "morphe" meaning form or shape. In programming this means that you can have methods that all share the same name, but have different implementations. For example, say you have this class called Person:

class Person
    def initialize(first, last, age)
         @first_name = first
         @last_name = last
         @age = age
    end

    def birthday
         @age += 1
    end

    def introduce
          puts "Hi everyone. My name is #{@first_name} #{@last_name}."
    end
end

This is all well and good, but let's also say that you want to get more specific with your person, say you also have a class of Teacher, and a class of Student. We want to keep the state and behavior of our Person class, so we will have our Teacher and Student classes inherit from the Person class. The beauty of Polymorphism is that we can keep the original "introduce" method that we get from our person class, and give it new behavior for each of the other two classes like this:

class Person
    def initialize(first, last, age)
         @first_name = first
         @last_name = last
         @age = age
    end

    def birthday
         @age += 1
    end

    def introduce
          puts "Hi everyone. My name is #{@first_name} #{@last_name}."
    end
end

class Student < Person
    def introduce
          puts "Hello teacher. My name is #{@first_name} #{@last_name}."
    end
end

class Teacher < Person
    def introduce
          puts "Hello class. My name is #{@first_name} #{@last_name}."
    end
end

The Teacher and Student classes both have a method called "introduce," but it behaves differently, or it has a different implementation thanks to polymorphism. We have overridden the original method behavior, but we have kept the same name.

Lastly we have abstraction, which is basically the idea of only showing essential attributes to the user, and hiding any unnecessary details/information. Abstraction is selecting data from a larger pool, and only showing the relevant details of the object to the user. It helps reduce programming complexity. An example that helps me wrap my head around the concept is fetching data from an API. Say you make a fetch request that gives you back 100 blog posts in the form of an array of objects. Each object contains the properties of, title, body, author, publication date, publisher etc. For the purposes of your website, you want to display the first four posts on your page, and only include the title and body. So you write some JavaScript and do some DOM manipulation that allows you to do just that. In this case you have abstracted away all of the posts that you don't want to display, and all of the other object properties that you don't need as well. You still get all of that information when you make your initial fetch request, but you have hidden, or abstracted it away from your user.

I hope this post has helped someone understand the basics of the four pillars of OOP. Other OOP languages may do things a little differently than the examples I have shown in Ruby, for example you can't overload in Ruby because it isn't a strongly typed language, but the rest of the concepts are pretty much the same across the board.

Reusable Code with "this" Keyword

Todd Carlson — Fri, 04 Dec 2020 20:30:28 +0000

If you are familiar with JavaScript objects, you know that you can access the value of an object property using dot notation like this:

let dog = {
    name: "Doug",
    breed: "pug",
    sayName: function() {return "The name of this dog is " + 
    dog.name + "."}
}
console.log(dog.sayName())
// "The name of this dog is Doug."

This is a fine way to access a property, but, if we want to future proof our code and account for the fact that variable names sometimes change, this is not the best way to access object properties. If we were to change the variable name from "dog" to "animal," any other code that references the original variable name of "dog" would need to be updated to the new variable name of "animal." You could see how this could quickly escalate if the original variable is referenced in a lot of other places.

However, this problem can be easily avoided if we were to use the "this" keyword. The "this" keyword is a very deep topic that is beyond the scope of this short blog post. I am merely showing you one way to use it. However, "this" is something that I implore all of you to look deeper into.

In its present context, "this" refers to the object that is associated with it, which, in this case, is "dog." We can access the same name property, only this time we use the "this" keyword instead of the "dog" variable:

let dog = {
    name: "Doug",
    breed: "pug",
    sayName: function() {return "The name of this dog is " + 
    this.name + "."}
}
console.log(dog.sayName())
// "The name of this dog is Doug."

We achieve the same result as before, only now if we were to change the variable name to "animal" we would not have to find and modify all of the references to "dog" in our code. Our code is now reusable and easier to read.

Difference between an ID and a Class in HTML

Todd Carlson — Sat, 28 Nov 2020 19:51:34 +0000

There was an interesting Tweet circulating recently that really got me thinking. People were sharing what technologies web developers should know as we inch closer and closer to 2021. People were suggesting everything from GraphQl to Svelte, and everything in between. However, there was one person that made an observation that really resonated with me. HTML, CSS, and JavaScript were nowhere to be found on these lists, yet they are the three pillars of web development. Mastering these three in their original form will make you a much better developer when you eventually move on to those trendy new technologies. I think too often we get overwhelmed by all of the available tools and frameworks that we initially neglect how important it is to build a solid foundation in the basics. So that is what I want to focus on this week, something simple and basic like the difference between a HTML class and an ID, and when to use them.

Last week I was practicing building a landing page using only HTML, CSS, and JavaScript. As a self-taught developer and bootcamp grad, this is something I have done many times. However, between the tutorials, Googling, and opinions of different instructors, it dawned on me that I really didn't know when to use a class, or when to use an ID. I had somehow got it into my head that it was largely a matter of personal opinion, but deep down I knew that couldn't be right. So, after I had finished coding my landing page, I looked up the proper way to use HTML classes and IDs.

We use classes and IDs in our CSS to identify particular HTML elements. This is especially useful because it allows us to present the same kind of HTML element differently, depending on which styles we apply to the class or ID. For example, we could have several h1 tags on our page, but we can style each one differently by targeting each element by its unique class or ID. This is all well and good, but when do we use a class, and when do we use an ID?

The difference between an ID and a class is that an ID is only used to identify one single element in our HTML. IDs are only used when one element on the page should have a particular style applied to it. However, a class can be used to identify more than one HTML element. Also, when it comes to specificity in CSS, IDs are more specific than classes. This means that if an element has both a class and an ID applied to it, the ID styles will be the ones the browser displays.

In the case of my landing page, which I had divided into four sections, I gave each section an ID since I only needed to style each individual section once. I also used IDs to style any other elements that needed to have their own unique styles. I used classes to style everything else. I had a section that was displaying four different blog posts, but I wanted each blog post to have the same styling, so I gave each p tag the same class. By doing this I was able to style several elements at once, but only writing styles for one class.

I hope this post has shed some light on, not only the difference between classes and IDs, but also on the importance of taking the time to learn the basics, and revisiting the basics even after you have been developing for awhile. I love using React and other cool tools as much as the next person, but let's not forget that all of our favorite tools are built on top of the core web technologies of HTML, CSS, and JavaScript. If you have a strong foundation, the sky is the limit on the kind of beautiful house that you can build on top of them.

Basic DOM Manipulation

Todd Carlson — Sun, 22 Nov 2020 00:09:13 +0000

I spent this week practicing building a basic landing page with good ole HTML, CSS, and JavaScript. No frameworks, no libraries, no nothing. I also wanted to practice fetching data from an API and displaying it on my page, and that's where my old friend DOM manipulation came in handy. I used https://jsonplaceholder.typicode.com/posts to fetch some fake posts, instead of building an API from scratch.

Once I had finished the layout and styling, I got to work on coding the JavaScript that I would need to fetch and display the data on my page. I wanted to display four of the posts with their heading and copy, which we get from JSONplaceholder. I had already coded the necessary HTML divs with their respective IDs that I would need to target. In my main.js file I coded the variables and set them equal to the ID using document.querySelector() like this:

const $heading1 = document.querySelector('#post-1');
const $blog1 = document.querySelector('#post-text-1');

const $heading2 = document.querySelector('#post-2');
const $blog2 = document.querySelector('#post-text-2');

const $heading3 = document.querySelector('#post-3');
const $blog3 = document.querySelector('#post-text-3');

const $heading4 = document.querySelector('#post-4');
const $blog4 = document.querySelector('#post-text-4');

I then declared a variable and set it equal to the URL of the api that I would be fetching the data from. This isn't necessary, but I think it makes for cleaner and easier to read code. I also declared a variable called posts that I would utilize to store all the posts that I got back from my fetch request. Also, because you get back an array of 100 objects from the fetch request, I declared an index variable and set it equal to 4, since I would initially be displaying the first four posts.

const apiURL = 'https://jsonplaceholder.typicode.com/posts/';

let posts = [];

let index = 4;

fetch(apiURL)
    .then((response) => response.json())
    .then(apiPosts => {
        posts = apiPosts;
    })

At this point I would also need to chain on another .then to display the posts, but I first need to write a function to populate the posts for me. This function will need to take in three arguments: a post, a heading and a blog. The body of the function will need to clear out the initial posts (this is necessary for when I create a button with an event listener to display four more posts), create the necessary elements, create the necessary classes, set the inner HTML of said elements to the appropriate title and heading, and lastly append the newly created elements to the DOM. My final function, which creates new h1 and p tags looked like this:

const populatePost = (post, $heading, $blog) => {
    $heading.innerHTML = "";
    let $h1 = document.createElement('h1');
    $h1.className = 'post-title';
    $h1.innerHTML = post.title;
    $heading.appendChild($h1);
    $blog.innerHTML = "";
    let $p = document.createElement('p');
    $p.className = 'post-body';
    $p.innerHTML = post.body;
    $blog.appendChild($p);
};

Going back to my initial fetch request, we can now call the populatePost() function and pass in the necessary arguments:

fetch(apiURL)
    .then((response) => response.json())
    .then(apiPosts => {
        posts = apiPosts;
    })
    .then(() => {
        populatePost(posts[0], $heading1, $blog1);
        populatePost(posts[1], $heading2, $blog2);
        populatePost(posts[2], $heading3, $blog3);
        populatePost(posts[3], $heading4, $blog4);
    })

Since we need four posts, we call the function four times passing in a post index, a heading variable, and a blog variable which we have already created. After checking my page, I can confirm that the necessary data was appearing.

Lastly, I wanted to create a button that when clicked, would display the next four posts. After creating and styling the button with HTML and CSS, all I had left to do was create an event listener with JavaScript.

document
    .querySelector('#see-more-button')
    .addEventListener('click', () => {
        populatePost(posts[index], $heading1, $blog1);
        populatePost(posts[index + 1], $heading2, $blog2);
        populatePost(posts[index + 2], $heading3, $blog3);
        populatePost(posts[index + 3], $heading4, $blog4);
        index += 4;
        if(index > 95) {
            index = 0;
        };
    });

I targeted my button ID with document.querySelector(), and chained on an event listener. Event listeners take in a type and a callback function. The type I needed was click, and I used an anonymous function as my callback. I again utilized my populatePost() function. I passed in my index variable, which if we recall is set to four in the global scope which is why I add 1, 2, and 3, so I get the next four posts of 5, 6, 7, and 8. I again pass in a heading variable and a blog variable. Lastly I increment the index variable by four, so I get the next four posts on the next click. I also give a condition that if the index variable is greater than 95, the index variable gets sets to zero and we start with the first four posts again.

I hope this post helps you to better understand DOM manipulation, and fetching data from an API a little better.

Happy Coding!

Return a Portion of an Array with .slice()

Todd Carlson — Fri, 13 Nov 2020 20:24:10 +0000

This week I am going to explain the .slice() JavaScript array method. Not to be confused with the .splice() method, .slice() allows you to return a portion, or slice as the name implies, of an array. The .slice() method can take in two arguments. The first argument gives the index of where to begin the slice, while the second is the index for where to end the slice (and is non-inclusive). If no arguments are provided the .slice() method starts at the beginning of the array and continues through to the end, basically making a copy of the entire array. I have seen people use .slice() to make copies of arrays, but if making a copy on an array is what I need to do I prefer to use ... which is the spread operator. Also, .slice() is a non-destructive array method, which means that it does not alter the original array.

Here is an example of .slice() in action:

const arr = ["Lindsay", "Tobias", "Gob", "George Michael"];
let newArray = arr.slice(1, 3);
// Sets newArray to ["Tobias", "Gob"]

In this instance, arr.slice(1, 3) starts at the index in the 1 position, and stops at the index in the 3 position returning a new array with the elements at the 1 and 2 indexes while leaving the original array untouched.

Functional Programming Terminology

Todd Carlson — Sat, 07 Nov 2020 21:57:25 +0000

One thing I have found to be of vital importance when learning something new, is learning and using the correct terminology. Doing this not only helps you as your learn on your own, but it also makes it easier to communicate with, and ask others for help. With that in mind, I would like to devote this week's blog post to some key functional programming terms that you will definitely encounter.

The first term that you have no doubt already used, but maybe didn't know what it is called are "callbacks." If you have used the .filter() array method you have used a callback. In a nut shell, a callback function is a function that is passed into another function to decide the invocation of that function. In the case of .filter(), the callback function sets the criteria for how we filter an array.

There are also "first class functions," which are functions that can be assigned to a variable, passed into another function, or returned from another function just like any other normal value. The beauty of JavaScript is that all functions are first class functions.

There are also "higher-order functions," which are the functions that take a function as an argument, or return a function as a return value. Again, you have most likely already been using higher-order functions like .filter(), .map(), and .reduce().

The last term I want to touch on are "lamda" functions. Lamda functions are when the functions are passed in to another function or returned from another function, then those functions which gets passed in or returned can be called a lambda.

Functional programming is a vast topic, but I hope that this introduction to some of the key terms aides you in your quest to learn JavaScript.

JavaScript Currying

Todd Carlson — Sun, 01 Nov 2020 21:04:39 +0000

This week, as I was learning about functional programming with JavaScript, I came across the concept of currying. As per usual I got to learn a cool new programming term that I had never heard before. This weeks' fun new word was "arity." If you hear someone refer to the "arity" of a function, they are talking about the number of arguments that the function requires. With this in mind, currying a function means to convert a function of X "arity" into X functions of "arity" 1. Let's look at an example to get a better understanding of what this means.

const normalFunction = (a, b) => {
    return a + b;
}

Here we have an example of an un-curried function with an "arity" of 2, since it takes in two arguments a, and b.

const curriedFunction = a => b => a + b;

curriedFunction(2)(4)

// returns 6

If, for some reason, you are unable to supply all of the arguments for a function at one time, this could come in handy. You could save each function call into a variable, which would hold the value of the returned function which could then take the next argument when it becomes available.

let funcB = curriedFunction(1);

console.log(funcB(2));

// Returns 3

And there you have it, a short and sweet introduction to JavaScript currying. I encourage you all to explore this topic in more depth, since I have heard it is a fairly common question to encounter during technical interviews.

Pass the Test with Array.prototype.every()

Todd Carlson — Fri, 23 Oct 2020 22:27:44 +0000

I learned so much this week during my ongoing quest to become a JavaScript ninja. While attempting to solve an algorithm problem I came across the .every() method, which I found to be especially useful. What does the .every() method do? I'm so glad you asked. The .every() method allows you to check and see if every element in an array passes a test. If all the elements pass the test it returns true, and false if they don't.

For example, the following code checks to see if all of the elements in the array are strings.

let arr = ["1", "2", "3"];

const checkString = (arr) => {
    return arr.every((item) => {
       if(typeof(item) === 'string') {
          return true;
    }
  });
  return false
}
console.log(checkString(arr))
// logs true to the console

Since all of the elements inside of our array are strings, the function returns true.

If we wanted to check and see if the array contained at least one string we could use the .some() method.

let arr = ["1", 2, 3];

const checkString = (arr) => {
    return arr.some((item) => {
       if(typeof(item) === 'string') {
          return true;
    }
  });
  return false
}
console.log(checkString(arr))
// logs true to the console

And there you have it, two useful array methods for the price of one blog post. I hope you found this useful, and, as always, happy coding!

JavaScript Mixins

Todd Carlson — Fri, 16 Oct 2020 20:23:41 +0000

My tumble down the rabbit hole continues. This week I have been focusing on object oriented programming concepts in JavaScript. Having learned Ruby as my first language, I found that I was able to pick up and understand the JavaScript approach to OOP without too much difficulty. One such concept that I found to be especially useful were mixins.

So what are mixins exactly? Well, in a nutshell, a mixin is a class containing methods that can be used by other classes without a need to inherit from it. For example, if you are working with unrelated objects inheritance is probably not the best solution. Let's say you have a cheetah object, and a trackStar object. They both can run, but they are not the same species. So if you wanted both of these objects to be able to use the same run function, a mixin would serve you well. The reason for this is because mixins allow unrelated objects to use the same collection of functions.

let runMixin = function(obj) {
  obj.run = function() {
    console.log("Running fast!");
  }
};

The runMixin takes in any object that you pass into it and gives it the run method.

let cheetah = {
  name: "Chester",
  topSpeed: "80 mph"
};

let trackStar = {
  name: "Steve Prefontaine",
  homeTown: "Coos Bay, OR"
};

runMixin(cheetah);
runMixin(trackStar);

We pass in the cheetah object and the trackStar object. They both get assigned the run function. We can now call the run function on either unrelated object resulting in both objects now being able to run fast.

cheetah.run(); // prints "Running fast!"
trackStar.run(); // prints "Running fast!"

So a mixin is basically a class that that contains methods for other classes to use.

I hope this post has shed some light on how to use mixins in JavaScript. OOP in JavaScript is a vast topic that I encourage you all to explore more deeply. The more I learn about JavaScript, the more I appreciate just how powerful it is.

Object Destructuring with ES6

Todd Carlson — Fri, 09 Oct 2020 22:07:56 +0000

This week I am focusing on object destructuring with ES6. I was first introduced to object destructuring while a student at the Flatiron School during our module on React. Object destructuring is something I use almost daily, especially as a React developer, and I would like to take this opportunity to share how it works with you. So, without further ado, let's dive in.

Destructuring JavaScript objects is similar to destructuring JavaScript arrays. It allows us to pull multiple values at a time, and to store each of those values inside their own variable. To fully appreciate how useful this is, I think it might be helpful to look at the old way of pulling values from objects and assigning them to their own variables. Let's say we have an object that contains these key/value pairs:

const dog = {
  name: 'Doug',
  age: 4,
  breed: 'Pug',
  temperament: 'friendly'
};
const name = dog.name;
const breed = dog.breed;

Depending on how large the object is, this could get really old really fast. Thanks to ES6 destructuring we can create multiple variables from the information contained inside of an object on a single line. To create the name and breed variables from our dog object we simple write this statement:

const { name, breed } = dog;

You can also assign a default value to the variable when the property of an object doesn’t exist. For example:

const dog = {
  name: 'Doug',
  breed: 'Pug',
  temperament: 'friendly'
};

const { name, age = 'unknown', breed } = dog

Since there is no age key/value pair inside the dog object, were we to log age to the console we would get back the string, "unknown".

In my opinion, the true power and usefulness of object destructuring is made apparent when you have to deal with the kind of nested data that you get back from a JSON API.

const dog = {
  name: 'Doug',
  breed: 'Pug',
  age: 4,
  temperament: 'friendly',
  links: {
    social: {
      twitter: 'https://twitter.com/dougthepug',
      instagram: 'https://instagram.com/realdougthepug',
    },
    web: {
      blog: 'https://dougthepug.com'
    }
  }
};

Let's say that we only want to grab the social media links from this nested object. To achieve this with destructuring we simply write:

const { twitter, instagram } = dog.links.social;

The url for each account is now stored inside the variables twitter, and instagram. Again destructuring is super useful if you are a front-end developer.

I hope this has been useful. I plan to dive more deeply into JavaScript objects in future posts.

Happy coding!

Array Destructuring with ES6

Todd Carlson — Fri, 02 Oct 2020 22:06:45 +0000

One of my favorite side effects of tech blogging, aside from hopefully writing content that other people find useful, is that it helps me to solidify concepts. This week I am focusing on array destructuring with ES6. You can also use destructuring with Objects, but I am going to save that for a future post.

So what exactly is array destructuring? In a nutshell, array destructuring is taking the individual elements inside of an array, and assigning them to individual variables. So, a basic example might look like this:

let letters = ["a", "b", "c", "d", "e"];
let [one, two] = letters;

console.log(one); // "a"
console.log(two); // "b"

Here we have declared a variable, letters, and assigned its value to an array of strings containing the first five letters of the alphabet. Next we have declared another variable, which is an array containing the variables one and two. We then set those values equal to variable letters, whose value is our array of strings. What this does is allow us to set the variables one, and two equal to the first two elements in our letters array, which we have verified with our two console.log() statements. Keep in mind that in JavaScript we are not allowed to use integers as variable names, so this code would have thrown a syntax error:

let letters = ["a", "b", "c", "d", "e"];
let [1, 2] = letters;

console.log(one); // "a"
console.log(two); // "b"

Another powerful feature of array destructuring is the ability to use Rest syntax. If we take our previous code example and add another variable called three preceded by Rest syntax, which looks like this '...' we get the following result:

let letters = ["a", "b", "c", "d", "e"];
let [one, two, ...three] = letters;

console.log(one); // "a"
console.log(two); // "b"
console.log(three) // ["c", "d", "e"]

Using Rest syntax allows us to take the values that come after one, and two and spread, or copy, those values into a new array stored in the variable three.

Array destructuring is also useful if you want to swap out the values of variables:

let a = "cat"; 
let b = "dog";

[a, b] = [b, a];

console.log(a); // "dog"
console.log(b); // "cat"

Lastly, you can also use destructuring with functions that return arrays of data:

const retArray = () => {
    return ["a", "b", "c", "d", "e"];
}

let [one, two] = retArray();

console.log(one); // "a"
console.log(two); // "b"

As you can see, array destructuring is a powerful feature of ES6. It is especially useful when working with JavaScript frameworks like React and Vue. Stay tuned for my next post where I will explain how to use destructuring with JavaScript Objects.

Until then,
Happy Coding!