Nick Scialli (he/him)

Posted on Jul 20, 2020

A Collection of JavaScript Tips Based on Common Areas of Confusion or Misunderstanding

#javascript #node #webdev #programming

Please give this post a 💓, 🦄, or 🔖 if it you learned something!

This is a collection of JavaScript tips based on common areas of confusion and misunderstanding. I created this collection based on personal experience and also based on a lot of questions I end up answering both here and on StackOverflow.

If you have any additions, I'd love to hear about them in the comments!

I make other easy-to-digest tutorial content! Please consider:

Subscribing to my DevTuts mailing list
Subscribing to my DevTuts YouTube channel

Value vs. Reference Variable Assignment
Closures
Destructuring
Spread Syntax
Rest Syntax
Array Methods
Generators
Identity Operator (===) vs. Equality Operator (==)
Object Comparison
Callback Functions
Promises
Async Await
DOM Manipulation
Interview Questions
Miscellaneous

Value vs. Reference Variable Assignment

Understanding how JavaScript assigns to variables is foundational to writing bug-free JavaScript. If you don't understand this, you could easily write code that unintentionally changes values.

When JavaScript assigns one of the five primitive type (i.e., Boolean, null, undefined, String, and Number) to a variable, the JavaScript runtime gets to determine whether that primitive is assigned by reference or by value. It doesn't really matter how it's done because primitives can't be mutated (they're immutable). However, when the assigned value is an Array, Function, or Object a reference to the array/function/object in memory is assigned.

Example time! In the following snippet, var2 is set as equal to var1. Since var1 is a primitive type (String), var2 is set as equal to var1's String value and can be thought of as completely distinct from var1 at this point. Accordingly, reassigning var2 has no effect on var1.

const var1 = 'My string';
let var2 = var1;

var2 = 'My new string';

console.log(var1);
// 'My string'
console.log(var2);
// 'My new string'

Let's compare this with object assignment.

const var1 = { name: 'Jim' };
const var2 = var1;

var2.name = 'John';

console.log(var1);
// { name: 'John' }
console.log(var2);
// { name: 'John' }

How this is working:

The object { name: 'Jim' } is created in memory
The variable var1 is assigned a reference to the created object
The variable var2 is set to equal var1... which is a reference to that same object in memory!
var2 is mutated, which really means the object var2 is referencing is mutated
var1 is pointing to the same object as var2, and therefore we see this mutation when accessing var1

One might see how this could cause problems if you expected behavior like primitive assignment! This can get especially ugly if you create a function that unintentionally mutates an object.

Closures

Closure is an important javascript pattern to give private access to a variable. In this example, createGreeter returns an anonymous function that has access to the supplied greeting, "Hello." For all future uses, sayHello will have access to this greeting!

function createGreeter(greeting) {
    return function(name) {
        console.log(greeting + ', ' + name);
    };
}

const sayHello = createGreeter('Hello');

sayHello('Joe');
// Hello, Joe

In a more real-world scenario, you could envision an initial function apiConnect(apiKey) that returns some methods that would use the API key. In this case, the apiKey would just need to be provided once and never again.

function apiConnect(apiKey) {
    function get(route) {
        return fetch(`${route}?key=${apiKey}`);
    }

    function post(route, params) {
        return fetch(route, {
            method: 'POST',
            body: JSON.stringify(params),
            headers: {
                Authorization: `Bearer ${apiKey}`
            }
        });
    }

    return { get, post };
}

const api = apiConnect('my-secret-key');

// No need to include the apiKey anymore
api.get('http://www.example.com/get-endpoint');
api.post('http://www.example.com/post-endpoint', { name: 'Joe' });

Destructuring

Don't be thrown off by javascript parameter destructuring! It's a common way to cleanly extract properties from objects.

const obj = {
    name: 'Joe',
    food: 'cake'
};

const { name, food } = obj;

console.log(name, food);
// 'Joe' 'cake'

If you want to extract properties under a different name, you can specify them using the following format.

const obj = {
    name: 'Joe',
    food: 'cake'
};

const { name: myName, food: myFood } = obj;

console.log(myName, myFood);
// 'Joe' 'cake'

In the following example, destructuring is used to cleanly pass the person object to the introduce function. In other words, destructuring can be (and often is) used directly for extracting parameters passed to a function. If you're familiar with React, you probably have seen this before!

const person = {
    name: 'Eddie',
    age: 24
};

function introduce({ name, age }) {
    console.log(`I'm ${name} and I'm ${age} years old!`);
}

introduce(person);
// "I'm Eddie and I'm 24 years old!"

Spread Syntax

A javascript concept that can throw people off but is relatively simple is the spread operator! In the following case, Math.max can't be applied to the arr array because it doesn't take an array as an argument, it takes the individual elements as arguments. The spread operator ... is used to pull the individual elements out the array.

const arr = [4, 6, -1, 3, 10, 4];
const max = Math.max(...arr);
console.log(max);
// 10

Rest Syntax

Let's talk about javascript rest syntax. You can use it to put any number of arguments passed to a function into an array!

function myFunc(...args) {
    console.log(args[0] + args[1]);
}

myFunc(1, 2, 3, 4);
// 3

Array Methods

JavaScript array methods can often provide you incredible, elegant ways to perform the data transformation you need. As a contributor to StackOverflow, I frequently see questions regarding how to manipulate an array of objects in one way or another. This tends to be the perfect use case for array methods.

I will cover a number of different array methods here, organized by similar methods that sometimes get conflated. This list is in no way comprehensive: I encourage you to review and practice all of them discussed on MDN (my favorite JavaScript reference).

map, filter, reduce

There is some confusion around the javascript array methods map, filter, reduce. These are helpful methods for transforming an array or returning an aggregate value.

map: return array where each element is transformed as specified by the function

const arr = [1, 2, 3, 4, 5, 6];
const mapped = arr.map(el => el + 20);
console.log(mapped);
// [21, 22, 23, 24, 25, 26]

filter: return array of elements where the function returns true

const arr = [1, 2, 3, 4, 5, 6];
const filtered = arr.filter(el => el === 2 || el === 4);
console.log(filtered);
// [2, 4]

reduce: accumulate values as specified in function

const arr = [1, 2, 3, 4, 5, 6];
const reduced = arr.reduce((total, current) => total + current, 0);
console.log(reduced);
// 21

Note: It is always advised to specify an initialValue or you could receive an error. For example:

const arr = [];
const reduced = arr.reduce((total, current) => total + current);
console.log(reduced);
// Uncaught TypeError: Reduce of empty array with no initial value

Note: If there’s no initialValue, then reduce takes the first element of the array as the initialValue and starts the iteration from the 2nd element

You can also read this tweet by Sophie Alpert (@sophiebits), when it is recommended to use reduce

find, findIndex, indexOf

The array methods find, findIndex, and indexOf can often be conflated. Use them as follows.

find: return the first instance that matches the specified criteria. Does not progress to find any other matching instances.

const arr = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
const found = arr.find(el => el > 5);
console.log(found);
// 6

Again, note that while everything after 5 meets the criteria, only the first matching element is returned. This is actually super helpful in situations where you would normally break a for loop when you find a match!

findIndex: This works almost identically to find, but rather than returning the first matching element it returns the index of the first matching element. Take the following example, which uses names instead of numbers for clarity.

const arr = ['Nick', 'Frank', 'Joe', 'Frank'];
const foundIndex = arr.findIndex(el => el === 'Frank');
console.log(foundIndex);
// 1

indexOf: Works almost identically to findIndex, but instead of taking a function as an argument it takes a simple value. You can use this when you have simpler logic and don't need to use a function to check whether there is a match.

const arr = ['Nick', 'Frank', 'Joe', 'Frank'];
const foundIndex = arr.indexOf('Frank');
console.log(foundIndex);
// 1

push, pop, shift, unshift

There are a lot of great array method to help add or remove elements from arrays in a targeted fashion.

push: This is a relatively simple method that adds an item to the end of an array. It modifies the array in-place and the function itself returns the length of the new array.

const arr = [1, 2, 3, 4];
const pushed = arr.push(5);
console.log(arr);
// [1, 2, 3, 4, 5]
console.log(pushed);
// 5

pop: This removes the last item from an array. Again, it modifies the array in place. The function itself returns the item removed from the array.

const arr = [1, 2, 3, 4];
const popped = arr.pop();
console.log(arr);
// [1, 2, 3]
console.log(popped);
// 4

shift: This removes the first item from an array. Again, it modifies the array in place. The function itself returns the item removed from the array.

const arr = [1, 2, 3, 4];
const shifted = arr.shift();
console.log(arr);
// [2, 3, 4]
console.log(shifted);
// 1

unshift: This adds one or more elements to the beginning of an array. Again, it modifies the array in place. Unlike a lot of the other methods, the function itself returns the new length of the array.

const arr = [1, 2, 3, 4];
const unshifted = arr.unshift(5, 6, 7);
console.log(arr);
// [5, 6, 7, 1, 2, 3, 4]
console.log(unshifted);
// 7

splice, slice

These methods either modify or return subsets of arrays.

splice: Change the contents of an array by removing or replacing existing elements and/or adding new elements. This method modifies the array in place.

The following code sample can be read as: at position 1 of the array, remove 0 elements and insert b.
const arr = ['a', 'c', 'd', 'e'];
arr.splice(1, 0, 'b');
console.log(arr);
// ['a', 'b', 'c', 'd', 'e']

slice: returns a shallow copy of an array from a specified start position and before a specified end position. If no end position is specified, the rest of the array is returned. Importantly, this method does not modify the array in place but rather returns the desired subset.

const arr = ['a', 'b', 'c', 'd', 'e'];
const sliced = arr.slice(2, 4);
console.log(sliced);
// ['c', 'd']
console.log(arr);
// ['a', 'b', 'c', 'd', 'e']

sort

sort: sorts an array based on the provided function which takes a first element and second element argument. Modifies the array in place. If the function returns negative or 0, the order remains unchanged. If positive, the element order is switched.

const arr = [1, 7, 3, -1, 5, 7, 2];
const sorter = (firstEl, secondEl) => firstEl - secondEl;
arr.sort(sorter);
console.log(arr);
// [-1, 1, 2, 3, 5, 7, 7]

Phew, did you catch all of that? Neither did I. In fact, I had to reference the MDN docs a lot while writing this - and that's okay! Just knowing what kind of methods are out there with get you 95% of the way there.

Generators

Don't fear the *. The generator function specifies what value is yielded next time next() is called. Can either have a finite number of yields, after which next() returns an undefined value, or an infinite number of values using a loop.

function* greeter() {
    yield 'Hi';
    yield 'How are you?';
    yield 'Bye';
}

const greet = greeter();

console.log(greet.next().value);
// 'Hi'
console.log(greet.next().value);
// 'How are you?'
console.log(greet.next().value);
// 'Bye'
console.log(greet.next().value);
// undefined

And using a generator for infinite values:

function* idCreator() {
    let i = 0;
    while (true) yield i++;
}

const ids = idCreator();

console.log(ids.next().value);
// 0
console.log(ids.next().value);
// 1
console.log(ids.next().value);
// 2
// etc...

Identity Operator (===) vs. Equality Operator (==)

Be sure to know the difference between the identify operator (===) and equality operator (==) in javascript! The == operator will do type conversion prior to comparing values whereas the === operator will not do any type conversion before comparing.

console.log(0 == '0');
// true
console.log(0 === '0');
// false

Object Comparison

A mistake I see javascript newcomers make is directly comparing objects. Variables are pointing to references to the objects in memory, not the objects themselves! One method to actually compare them is converting the objects to JSON strings. This has a drawback though: object property order is not guaranteed! A safer way to compare objects is to pull in a library that specializes in deep object comparison (e.g., lodash's isEqual).

The following objects appear equal but they are in fact pointing to different references.

const joe1 = { name: 'Joe' };
const joe2 = { name: 'Joe' };

console.log(joe1 === joe2);
// false

Conversely, the following evaluates as true because one object is set equal to the other object and are therefore pointing to the same reference (there is only one object in memory).

const joe1 = { name: 'Joe' };
const joe2 = joe1;

console.log(joe1 === joe2);
// true

Make sure to review the Value vs. Reference section above to fully understand the ramifications of setting a variable equal to another variable that's pointing to a reference to an object in memory!

Callback Functions

Far too many people are intimidated by javascript callback functions! They are simple, take this example. The console.log function is being passed as a callback to myFunc. It gets executed when setTimeout completes. That's all there is to it!

function myFunc(text, callback) {
    setTimeout(function() {
        callback(text);
    }, 2000);
}

myFunc('Hello world!', console.log);
// 'Hello world!'

Promises

Once you understand javascript callbacks you'll soon find yourself in nested "callback hell." This is where Promises help! Wrap your async logic in a Promise and resolve on success or reject on fail. Use then to handle success and catch to handle failure.

const myPromise = new Promise(function(res, rej) {
    setTimeout(function() {
        if (Math.random() < 0.9) {
            return res('Hooray!');
        }
        return rej('Oh no!');
    }, 1000);
});

myPromise
    .then(function(data) {
        console.log('Success: ' + data);
    })
    .catch(function(err) {
        console.log('Error: ' + err);
    });

// If Math.random() returns less than 0.9 the following is logged:
// "Success: Hooray!"
// If Math.random() returns 0.9 or greater the following is logged:
// "Error: Oh no!"

Avoid the nesting anti-pattern of promise chaining!

.then methods can be chained. I see a lot of new comers end up in some kind of call back hell inside of a promise when it's completely unnecessary.

//The wrong way
getSomedata.then(data => {
    getSomeMoreData(data).then(newData => {
        getSomeRelatedData(newData => {
            console.log(newData);
        });
    });
});

//The right way
getSomeData
    .then(data => {
        return getSomeMoreData(data);
    })
    .then(data => {
        return getSomeRelatedData(data);
    })
    .then(data => {
        console.log(data);
    });

You can see how it's much easier to read the second form and with ES6 implicit returns we could even simplify that further:

getSomeData
    .then(data => getSomeMoreData(data))
    .then(data => getSomeRelatedData(data))
    .then(data => console.log(data));

Because the function supplied to .then will be called with the the result of the resolve method from the promise we can omit the ceremony of creating an anonymous function altogether. This is equivalent to above:

getSomeData
    .then(getSomeMoreData)
    .then(getSomeRelatedData)
    .then(console.log);

Async Await

Once you get the hang of javascript promises, you might like async await, which is just "syntactic sugar" on top of promises. In the following example we create an async function and within that we await the greeter promise.

const greeter = new Promise((res, rej) => {
    setTimeout(() => res('Hello world!'), 2000);
});

async function myFunc() {
    const greeting = await greeter;
    console.log(greeting);
}

myFunc();
// 'Hello world!'

Async functions return a promise

One important thing to note here is that the result of an async function is a promise.

const greeter = new Promise((res, rej) => {
    setTimeout(() => res('Hello world!'), 2000);
});

async function myFunc() {
    return await greeter;
}

console.log(myFunc()); // => Promise {}

myFunc().then(console.log); // => Hello world!

DOM Manipulation

Create Your Own Query Selector Shorthand

When working with JS in the browser, instead of writing document.querySelector()/document.querySelectorAll() multiple times, you could do the following thing:

const $ = document.querySelector.bind(document);
const $$ = document.querySelectorAll.bind(document);

// Usage
const demo = $('#demo');
// Select all the `a` tags
[...$$("a[href *='#']")].forEach(console.log);

Interview Questions

Traversing a Linked List

Here's a javascript solution to a classic software development interview question: traversing a linked list. You can use a while loop to recursively iterate through the linked list until there are no more values!

const linkedList = {
    val: 5,
    next: {
        val: 3,
        next: {
            val: 10,
            next: null
        }
    }
};

const arr = [];
let head = linkedList;

while (head !== null) {
    arr.push(head.val);
    head = head.next;
}

console.log(arr);
// [5, 3, 10]

Miscellaneous

Increment and Decrement

Ever wonder what the difference between i++ and ++i was? Did you know both were options? i++ returns i and then increments it whereas ++i increments i and then returns it.

let i = 0;
console.log(i++);
// 0

let i = 0;
console.log(++i);
// 1

Contributing

Contributions welcome over on the associated Github repo! All I ask is that you open an issue and we discuss your proposed changes first.

Top comments (13)

pentacular • Jul 20 '20

Since this is about common areas of confusion ... :)

whether that primitive is assigned by reference or by value.

Assignment in Javascript is always by value, never by reference.

That is, a = b assigns the value produced by evaluating b to a.

This is important, since if it b were assigned a by reference, it would refer to the value of a and given a++, a === b would remain true.

What you could say is that an object evaluates to a value that holds a reference to the object, but that's kind of long winded.

And in Javascript a reference is a resolved name or property binding.
e.g., in delete a.b; a.b produces a reference type.

I think it's simpler to say that evaluation in Javascript produces the value, rather than a copy of the value, and this is true of both primitives and objects.

Let's not bring assignment by reference into the picture to confuse things further. :)

Closure is an important javascript pattern to give private access to a variable.

Closures do not give private access to variables.

They allow the variable to be in multiple scopes, and to persist for the extent of those scopes.

// Nothing private about a.
let a = 0;

const foo () => {
  // Have a closure over a, foo.
  foo(() => a);
  // Have a closure over a, bar.
  bar(() => a);
};

Rather, closures provide a mechanism which allows delegation of access to a variable via a function call.

Variables are pointing to references to the objects in memory, not the objects themselves!

Variables are pointers now?
And they point at references?

Why not just say that the value of a variable is the object itself, like the ecmascript standard does?

So, when you compare two object values, you're seeing if they're the value of the same object.

The critical point here is that the value of an object is the object itself, not a copy of the object.

And so, saying a = b; assigns the value of b to a, which is the object itself, and so a.c accesses the same property as b.c, while a and b are independent variables which currently have the same value.

Identity Operator (===) vs. Equality Operator (==)

Let's start by saying that === is the Strict Equality Comparison, and == is the Abstract Equality Comparison, and neither of them are an identity operator.

Let's take a look at the Strict Equality Comparison

1. If Type(x) is different from Type(y), return false.
2. If Type(x) is Number or BigInt, then
  a. Return ! Type(x)::equal(x, y).
3. Return ! SameValueNonNumeric(x, y).

Case 2.a is the important one.

Let's take a look at Number::equal

1. If x is NaN, return false.
2. If y is NaN, return false.
3. If x is the same Number value as y, return true.
4. If x is +0 and y is -0, return true.
5. If x is -0 and y is +0, return true.
6. Return false

And there's where it falls short of being an identity operator.

Did you know both were options? i++ returns i and then increments it whereas ++i increments i and then returns it.

This introduces a confusing model of time into evaluation.

i++ returns i, then increments? But a return is a transfer of control ... what's going on here ?!?

Instead we can say that both i++ and ++i increment i.

The difference is that i++ evaluates to the old value of i, and ++i evaluates to the new value of it.

John Wright • Jul 21 '20

that was really helpful

pentacular • Jul 21 '20

Glad to be of help :)

z2lai • Jul 22 '20 • Edited

Woah, that was a lot of elaboration, but in the end it all made sense. Some of the further elaboration did confused me a little though.
For example, you say:

The critical point here is that the value of an object is the object itself, not a copy of the object.

and before that you say:

What you could say is that an object evaluates to a value that holds a reference to the object

So combining these two thoughts: the value of an object is the object itself, which evaluates to a value that holds a reference to the object.
Conceptually, it makes sense to me - the value of an object evaluates to a value that holds a reference to the object - which evaluates to a value that holds a reference to the object - which... But then again, the latter quote forms an infinite loop of logic with itself! What's the term for that...

Personally, I find explaining code in English to be extremely hard because I tend to get into infinite loops of logic.

pentacular • Jul 23 '20

I think that you're trying to impose the understanding of JS semantics on top of an assumed implementation model.

Let's imagine that there's a kind of value called an 'object type value'.

And having this 'object type value' lets you access the same set of 'object properties'.

Now, if I pass you my 'object type value' by value, you have an equivalent 'object type value' which lets you access the same 'object properties' that I access using my copy of the 'object type value'.

And the two 'object type values' will compare equal.

And so we can say that these two 'object type values' are the same object.

But actually, the 'object' is in the relationships that the 'object type value' makes available.

We don't need to talk about references or pointers or anything else -- the above is sufficient.

z2lai • Jul 23 '20 • Edited

Hey, thanks for the reply. So what you're saying is that the implementation of 'object type values' being just reference values (pointers) to the memory location containing the object is an assumption rather than a fact? If that's the case, what is the actual implementation? This would be a huge revelation as most educational material online explain the implementation this way.

I'm trying really hard to understand your high level explanation of the implementation but I'm honestly confused because of how high level it is and the new terminology used. For example, you say "when I pass you my 'object type value' by value", that doesn't equate to some code that I can visualize, which forces me to infer that you mean when you assign your 'object type value' to a new variable, but my inference might be wrong. Then you say, "the 'object' is in the relationships". I've never heard of this relationship term used in Javascript before, so I have no idea what that sentence means. Please correct me if I'm wrong and if relationships is an actual term used in the implementation model instead of an abstract concept.

It could just be me though, since I understand explanations much easier from a low level rather than abstract explanations. Ultimately, I think I already understand 'how it works' at a high level and it seems to be the same as what you're explaining (regardless of whether we're using the term relationship or reference). However, I'm inclined to understand how things work under the hood (coming from a math and physics background), which why these high level explanations don't work well with me.

pentacular • Jul 23 '20

Let us consider a simple program.

const a = { size: 10 };
const b = a;
const aSize = a.size;
const bSize = b.size;

Now imagine an implementation of Javascript in Javascript, where objects are represented as numbers, and we have Get and Set methods.

We might represent the above like so.

const a = 0;
Set(a, "size", 10);
const b = a;
const aSize = Get(a, "size");
const bSize = Get(b, "size");

The value of the object is its identity, which enables us to access the object's properties.

Sharing this identity allows others to access the same properties.

So we don't need to talk about pointers or references -- we just need the object value and some way to use that to access the object's properties.

There's nothing special about numbers for object values in the example, it might as well have been strings, or dates, or anything that can provide an identity.

As for "under the hood", there isn't any -- unless you're assuming a particular implementation, in which case you're no-longer reasoning about the language, but some particular implementation of it.

If you come from a math background it should be natural to understand things in terms of relationships, rather than mechanics.