Why you should update your JS knowledge (ES6)

Chris Burgin
3 min readFeb 21, 2017

--

Recently I have read several ‘What it feels like to learn javascript in 2017(16)’ articles. Initially I am inclined to believe them, learning Javascript is hard and Javascript fatigue is an all to real thing in todays world. But in no way does that mean we should ignore what’s new and highly beneficial.

The trendy misconception is that many of the concepts introduced in recent versions of Javascript are neat, but hold no real value beyond adding confusion to a code base. While this can be true, I hope to show how ES6 and functional programming can provide us with clean, readable, and re-useable code.

The Standard Way

Imagine this case: you have just learned how to extract all the ducks from an object of animals. First let’s define our object of animals.

var animals = [
{ name: "duck 1", type: "duck", sound: "quack", size: "small" },
{ name: "cat 1", type: "cat", sound: "meow", size: "small" },
{ name: "duck 2", type: "duck", sound: "quack", size: "small" }
]

Now let’s get all the ducks out of this object.

var ducks = [] // hold our ducksfor (var i = 0; i < animals.length; i++) {
if (animals[i].type === "duck") {
ducks.push(animals[i].name)
}
}
console.log(ducks)

You will get the following output of the ducks names.

>> ["duck 1", "duck 2"]

This is a fairly trivial example and incorporates most of the basic aspects of the language. It makes sense to think that there is no reason to change how this is written. It works well, and it was not that hard.

There are several key problems with this example. First its quite non-descriptive; the code runs, but it does not serve as good self-documentation. Additionally our for loop brings about mutation of existing state, which is quite the no-no.

The New Way

By re-writing our duck filtering code, our goal is to make readable self-documenting code that will be easy to maintain. This will benefit our future selves but also the entire team.

The only real change we want to make to the animals object is declaring it as a constant instead of a var. More About Const and Let. Changes can be seen in bold.

const animals = [ >> Same As Above << ]

Next, let’s define a function to check if our animal is a duck.

const isDuck = (animal) =>
animal.type === "duck"
var ducks = [] // hold our ducksfor (var i = 0; i < animals.length; i++) {
if (isDuck(animals[i])) {
ducks.push(animals[i].name)
}
}

Above, isDuck will return true if the animal type is a duck and false if the animal type is anything else. This function is simple, but will lend our code to self-documentation. In short isDuck is clearer than animal.type === "duck" .

Next let’s drop the for loop, which is used to append a duck to the ducks array. Instead, we will use the filter method to directly declare our ducks array. This allows us to simplify our code and remove the nasty mutation caused by the for loop.

const isDuck = (animal) =>
animal.type === "duck"
const ducks =
animals.filter(isDuck)

Currently the value of ducks is the entire duck animal object, not the name of the animals. As you can see below:

>> [AnimalObject, AnimalObject]

Getting the names of the ducks instead of the entire animal object is quite easy using the map method.

const isDuck = (animal) =>
animal.type === "duck"
const getName = (animal) =>
animal.name
const ducks =
animals.filter(isDuck)
.map(getName)

The value of ducks is now only the ducks’ names, no longer the entire animal object.

>> ["duck 1", "duck 2"]

By re-writing this example, we have created code that is easy for anyone to understand. Using methods such as isDuck and getName allow for reusable code that is self-documenting. While the uses of map and filter eliminate the standard for loop, and the subsequent mutation that is associated.

Useful Reading

If you have any question, comments or concerns, please let me know in the comments!

Occasionally I tweet (@chrisburgin95)

Bye!

--

--

Chris Burgin

Christ follower. Dog caretaker. Developer at Generation Tux.