DEV Community: arnav-aggarwal

10 JavaScript concepts you need to know for interviews

arnav-aggarwal — Mon, 21 Aug 2017 18:17:45 +0000

Self-Learning

There are thousands of people learning JavaScript and web development in the hopes of getting a job. Often, self-learning leaves gaps in people’s understanding of the JavaScript language itself.

It’s actually surprising how little of the language is needed to make complex web pages. People making entire sites on their own often don’t have a good grasp of the fundamentals of JavaScript.

It’s rather easy to avoid the complex topics and implement features using basic skills. It’s also easy to create a website by relying on Stack Overflow without understanding the code being copied.

If you’re looking to master JavaScript interviews, check out Step Up Your JS: A Comprehensive Guide to Intermediate JavaScript

Interviews

The problem is that questions testing your understanding of JS are exactly what many tech companies ask in their interviews. It becomes clear very quickly when an applicant knows just enough to have scraped by, but doesn’t have a solid understanding the language.

Here are concepts that are frequently asked about in web development interviews. This is assuming you already know the basics such as loops, functions, and callbacks.

Concepts

Value vs. Reference — Understand how objects, arrays, and functions are copied and passed into functions. Know that the reference is what's being copied. Understand that primitives are copied and passed by copying the value.
Scope — Understand the difference between global scope, function scope, and block scope. Understand which variables are available where. Know how the JavaScript engine performs a variable lookup.
Hoisting — Understand that variable and function declarations are hoisted to the top of their available scope. Understand that function expressions are not hoisted.
Closures — Know that a function retains access to the scope that it was created in. Know what this lets us do, such as data hiding, memoization, and dynamic function generation.
this — Know the rules of this binding. Know how it works, know how to figure out what it will be equal to in a function, and know why it’s useful.
new — Know how it relates to object oriented programming. Know what happens to a function called with new. Understand how the object generated by using new inherits from the function’s prototype property.
apply, call, bind — Know how each of these functions work. Know how to use them. Know what they do to this.
Prototypes & Inheritance — Understand that inheritance in JavaScript works through the [[Prototype]] chain. Understand how to set up inheritance through functions and objects and how new helps us implement it. Know what the __proto__ and prototype properties are and what they do.
Asynchronous JS — Understand the event loop. Understand how the browser deals with user input, web requests, and events in general. Know how to recognize and correctly implement asynchronous code. Understand how JavaScript is both asynchronous and single-threaded.
Higher Order Functions — Understand that functions are first-class objects in JavaScript and what that means. Know that returning a function from another function is perfectly legal. Understand the techniques that closures and higher order functions allow us to use.

More Resources

If the links included aren’t enough, there are countless resources out there to help you learn these concepts.

I personally created Step Up Your JS: A Comprehensive Guide to Intermediate JavaScript to help developers advance their knowledge. It covers all of these concepts and many more.

Here are resources which I’ve read or watched at least some of and can recommend.

Good luck on your interviews.

If you found this useful, please give it a clap below so others see it as well.

Feel free to check out some of my recent work.

Step Up Your JS: A Comprehensive Guide to Intermediate JavaScript

What I learned from attending a coding bootcamp and teaching another one

React Ecosystem Setup — Step-By-Step Walkthrough

Master JavaScript Prototypes & Inheritance

arnav-aggarwal — Fri, 18 Aug 2017 04:12:24 +0000

This article is taken from my course, Step Up Your JS: A Comprehensive Guide to Intermediate JavaScript.

Inheritance

Inheritance refers to an object’s ability to access methods and other properties from another object. Objects can inherit things from other objects. Inheritance in JavaScript works through something called prototypes and this form of inheritance is often called prototypal inheritance.

In this article, we’ll cover a lot of seemingly unrelated topics and tie them together at the end. There’s also a TL;DR at the end for those who want the short version.

Object, Array, and Function

JavaScript gives us access to three global functions: Object, Array, and Function. Yes, these are all functions.

console.log(Object); // -> ƒ Object() { [native code] }
console.log(Array); // -> ƒ Array() { [native code] }
console.log(Function); // -> ƒ Function() { [native code] }

You don’t know it, but every time you create an object literal, the JavaScript engine is effectively calling new Object(). An object literal is an object created by writing {}, as in var obj = {};. So an object literal is an implicit call to Object.

Same goes for arrays and functions. We can think of an array as coming from the Array constructor and a function as coming from the Function constructor.

Object Prototypes

proto

All JavaScript objects have a prototype. Browsers implement prototypes through the __proto__ property and this is how we’ll refer to it. This is often called the dunder proto, short for double underscore prototype. Don’t EVER reassign this property or use it directly. The MDN page for __proto__ warns us in big red blocks to never do this.

prototype

Functions also have a prototype property. This is distinct from their __proto__ property. This makes discussion rather confusing, so I’ll spell out the syntax I’ll be using. When I refer to a prototype and the word “prototype isn’t highlighted grey, I’m referring to the __proto__ property. When I use prototype in grey, I’m talking about a function’s prototype property.

If we were to log the prototype of an object in Chrome, this is what we’d see.

var obj = {};
console.log(obj.__proto__);
// -> {constructor: ƒ, __defineGetter__: ƒ, …}

The __proto__ property is a reference to another object that has several properties on it. Every object literal we create has this __proto__ property pointing to this same object.

There are a couple of important points:

The __proto__ of an object literal is equal to Object.prototype
The __proto__ of Object.prototype is null

We’ll explain why soon.

The Prototype Chain

To understand object prototypes, we need to discuss object lookup behavior. When we look for a property of an object, the JavaScript engine will first check the object itself for the existence of the property. If not found, it’ll go to the object’s prototype and check that object. If found, it’ll use that property.

If not found, it’ll go to the prototype’s prototype, and on and on until it finds an object with a __proto__ property equal to null. So if we were to attempt to look up the property someProperty on our obj object from above, the engine would first check the object itself.

It wouldn’t find it and would then jump to its __proto__ object which is equal to Object.prototype. It wouldn’t find it there either and upon seeing that the next __proto__ is null, it would return undefined.

This is called the prototype chain. It’s normally described as a chain going downwards, with null at the very top and the object we’re using at the bottom.

When performing a lookup, the engine will traverse up the chain looking for the property and return the first one it finds, or undefinedif it’s not present in the prototype chain.

__proto__ === null
|
|
__proto__ === Object.prototype
|
|
{ object literal }

This can be demonstrated. Here we’re going to work with __proto__ directly for the purpose of demonstration. Again, don’t ever do it.

var obj = {};
obj.__proto__.testValue = 'Hello!';

console.log(obj); // -> {}
console.log(obj.testValue); // -> Hello!

This prototype chain is depicted below.

__proto__ === null
|
|
__proto__ === Object.prototype -> testValue: 'Hello!'
|
|
obj

When we log obj, we get an empty object because the property testValue isn’t present directly on the object. However, logging obj.testValue triggers a lookup. The engine goes up the prototype chain and finds testValue present on the object’s prototype and we see that value printing out.

hasOwnProperty

There’s a method available on objects called hasOwnProperty. It’ll return true or false based on whether the object itself contains the property being tested. Testing for __proto__, however, will ALWAYS return false.

var obj = {};
obj.__proto__.testValue = 'Hello!';

console.log(obj.hasOwnProperty('testValue'));
// -> false

console.log(obj.__proto__.hasOwnProperty('testValue'));
// -> true

Function prototypes

As mentioned, functions all have a prototype property distinct from their __proto__ property. It’s an object. A function’s prototype's __proto__ property is equal to Object.prototype. In other words:

function fn() {}
console.log(fn.prototype.__proto__ === Object.prototype);
// -> true

Function Prototypes and 'new'

A function’s prototype property shows its usefulness in object oriented programming. When we invoke a function using new, the object bound to this in the constructor function is special. The new keyword sets the object’s __proto__ to be the prototype property of the constructing function.

When we call a function with new, it sets the returned object’s __proto__ property equal to the function’s prototype property. This is the key to inheritance.

We’ve assembled a few points so far:

The __proto__ of an object created by calling a function with new is equal to the prototype of that function
The __proto__ of a function’s prototype is equal to Object.prototype
The __proto__ of Object.prototype is null

This lets us assemble the following prototype chain.

function Fn() {}
var obj = new Fn();

console.log(obj.__proto__ === Fn.prototype);
// -> true

console.log(obj.__proto__.__proto__=== Object.prototype);
// -> true

console.log(obj.__proto__.__proto__.__proto__ === null);
// -> true

Visually drawn:

__proto__ === null
|
|             
__proto__ === Object.prototype
|
|
__proto__ === Fn.prototype
|
|
obj

Implementing Inheritance

We can work with a function’s prototype property directly and safely. By placing methods and other properties on a function’s prototype, we enable all objects created by that function (using new) to access those properties through inheritance.

function Fn() {}

Fn.prototype.print = function() {
    console.log("Calling Fn.prototype's print method");
};

var obj = new Fn();
obj.print(); // -> Calling Fn.prototype's print method

You might be wondering what the point of this is. We can just attach this method inside the constructing function itself, like this.

function Fn() {
    this.print = function() {
        console.log("Calling the object's print method");
    };
}

var obj = new Fn();
obj.print(); // -> Calling the object's print method

You’re right, this works. The difference is that this way, each object created by calling new Fn() will have its own version of print placed directly on the object. They’ll be distinct functions in memory. The problem with this is performance and memory usage.

Performance

There may be times when you need thousands of new objects created from a constructor function. Using this second way of attaching print, we now have thousands of copies of print, each one attached to one of the objects.

Using the prototype chain, no matter how many objects we create out of Fn, we have one print sitting on Fn.prototype.

One method is not a big deal. Large programs, however, often have tens of methods that objects need. If an object needs access to 20 methods and we create 100,000 objects, the JavaScript engine has created 2,000,000 new functions.

If this needs to happen multiple times, this will cause noticeable speed and memory issues. Compare this to having a total of 20 functions and giving each object the ability to use the same functions through the prototype chain. Much more scalable.

Using console.time and console.timeEnd, we can directly show the difference in how long it takes. Here’s the time difference of creating 2 million objects with functions directly on them vs. on the prototype. We’re storing all the objects in an array.

Creating new functions (left) vs. using prototypal inheritance (right)

As we can see, putting the print method on the prototype takes about half the time.

`proto` of Literals

As mentioned, an object’s __proto__ is equal to the prototype of the function that created the object. This rule applies to literals also. Remember that object literals come from Object, arrays come from Array, and functions come from Function.

var obj = {};
var arr = [];
function fn() {}

console.log(obj.__proto__ === Object.prototype); // -> true
console.log(arr.__proto__ === Array.prototype); // -> true
console.log(fn.__proto__ === Function.prototype); // -> true

We can now explain why we’re able to call methods on arrays and objects. If we have an array arr, we can call arr.map() because the method map is present on Array.prototype. We can call obj.hasOwnProperty() because hasOwnProperty is present on Object.prototype. We’ve been using inheritance the whole time and didn’t even know it.

The end of the __proto__ chain of both Array and Function is equal to Object.prototype. They all derive from the same thing. This is why arrays, functions, and objects are all considered first-class objects in JavaScript.

constructor

We’ve thrown the word constructor around a few times. Let’s explain what it is. Every function’s prototype has a constructor property on it that points back to the function itself. This is something the engine does for every function.

function Fn() {}
console.log(Fn.prototype.constructor === Fn);
// -> true

An object created by running new Fn() will have its __proto__ equal to Fn.prototype. So if we were to attempt to log the constructor property of that object, the engine would give us Fn through its lookup process.

function Fn() {}
var obj = new Fn();
console.log(obj.constructor); // -> ƒ Fn(){}

Why it’s Useful

The constructor property on an object is useful because it can tell us how an object was created. Logging the constructor property directly on an object will tell us exactly which function created our object.

function Fn() {};

var normalObj = {};
var fnObj = new Fn();

console.log(normalObj.constructor);
// -> ƒ Object() { [native code] }

console.log(fnObj.constructor);
// -> ƒ Fn() {}

Object.create

There’s a way to set the prototype of an object manually. Object.create. This function will take in an object as a parameter. It’ll return a brand new object whose __proto__ property is equal to the object that was passed in.

var prototypeObj = {
    testValue: 'Hello!'
};

var obj = Object.create(prototypeObj);
console.log(obj); // -> {}
console.log(obj.__proto__ === prototypeObj); // -> true
console.log(obj.testValue); // -> 'Hello!'

This gives us an easy way to extend the prototype chain. We can make objects inherit from any object we like, not just a function’s prototype.

If you’d like more information and examples, the MDN page for Object.create is a great resource.

Phew.

That was a lot. I know. However, you now have a deep understanding of inheritance in JavaScript.

Prototypes Summary

In short, inheritance in JavaScript is implemented through the prototype chain. Every normally created object, array, and function has a prototype chain of __proto__ properties ending with Object.prototype at the top. This is why they’re all considered first-class objects in JavaScript.

Functions have a prototype property in addition to the __proto__ property. When using a constructor function with new, it’s good practice to place methods on the function’s prototype instead of on the object itself. The returned object’s __proto__ will be equal to the function’s prototype so it will inherit all methods on the function’s prototype. This prevents unnecessary memory usage and improves speed.

We can check if an object has its own property by using the hasOwnProperty method. We can manually set up inheritance by using Object.create.

That’s It. If this was helpful, please hit the heart so this story reaches more people. Also feel free to check out my other work.

My Work

Online Course

I’ve created an online course covering intermediate JavaScript topics such as scope, closures, OOP, this, new, apply/call/bind, asynchronous code, array and object manipulation, and ES2015+.
Step Up Your JS: A Comprehensive Guide to Intermediate JavaScript

Recent Articles

Explaining Value vs. Reference in Javascript
React Ecosystem Setup — Step-By-Step Walkthrough

Master value vs reference in JavaScript

arnav-aggarwal — Mon, 14 Aug 2017 19:55:04 +0000

This is taken from my new course, Step Up Your JS: A Comprehensive Guide to Intermediate JavaScript. Feel free to check it out there for interactive code playgrounds and practice problems.

JavaScript has 5 data types that are copied by value: Boolean, null, undefined, String, and Number. We’ll call these primitive types.

JavaScript has 3 data types that are copied by reference: Array, Function, and Object. These are all technically Objects, so we’ll refer to them collectively as Objects.

Primitives

If a primitive type is assigned to a variable, we can think of that variable as containing the primitive value.

var x = 10;
var y = 'abc';
var z = null;

x contains 10. y contains 'abc'. To cement this idea, we’ll maintain an image of what these variables and their respective values look like in memory.

When we assign these variables to other variables using =, we copy the value to the new variable. They are copied by value.

var x = 10;
var y = 'abc';

var a = x;
var b = y;

console.log(x, y, a, b);
// -> 10, 'abc', 10, 'abc'

Both a and x now contain 10. Both b and y now contain 'abc'. They’re separate, as the values themselves were copied.

Changing one does not change the other. Think of the variables as having no relationship to each other.

var x = 10;
var y = 'abc';

var a = x;
var b = y;

a = 5;
b = 'def';

console.log(x, y, a, b); // -> 10, 'abc', 5, 'def'

Objects

This will feel confusing, but bear with me and read through it. Once you get through it, it’ll seem easy.

Variables that are assigned a non-primitive value are given a reference to that value. That reference points to the object’s location in memory. The variables don’t actually contain the value.

Objects are created at some location in our computer’s memory. When we write arr = [], we’ve created an array in memory. What the variable arr now contains is the address, the location, of that array.

Let’s pretend that address is a new data type that is passed by value, just like number or string. An address points to the location, in memory, of a value that is passed by reference. Just like a string is denoted by quotation marks ('' or ""), an address will be denoted by arrow brackets, <>.

When we assign and use a reference-type variable, what we write and see is:

1) var arr = [];
2) arr.push(1);

A representation of lines 1 and 2 above in memory is:

Notice that the value, the address, contained in the variable arr is static. The array in memory is what changes. When we use arr to do something, such as pushing a value, the JavaScript engine goes to the location of arr in memory and works with the information stored there.

Assigning by Reference

When a reference type value, an object, is copied to another variable using =, the address of that value is what’s actually copied over as if it were a primitive. Objects are copied by reference instead of by value. The object itself is unchanged and static. The only thing copied is the reference, the address, of the object.

var reference = [1];
var refCopy = reference;

The code above looks like this in memory.

Each variable now contains a reference to the same array. That means that if we alter reference, refCopy will see those changes:

reference.push(2);
console.log(reference, refCopy);
// -> [1, 2], [1, 2]

We’ve pushed 2 into the array in memory. When we use reference and refCopy, we’re pointing to that same array.

Reassigning a Reference

Reassigning a reference variable replaces the old reference.

var obj = { first: 'reference' };

In memory:

When we have a second line:

var obj = { first: 'reference' };
obj = { second: 'ref2' }

The address stored in obj changes. The first object is still present in memory, and so is the next object:

When there are no references to an object remaining, as we see for the address #234 above, the JavaScript engine can perform garbage collection. This just means that the programmer has lost all references to the object and can’t use the object anymore, so the engine can safely delete it from memory. In this case, the object { first: 'reference' } is no longer accessible and is available to the engine for garbage collection.

== and ===

When the equality operators, == and ===, are used on reference-type variables, they check the reference. If the variables contain a reference to the same item, the comparison will result in true.

var arrRef = ['Hi!'];
var arrRef2 = arrRef;

console.log(arrRef === arrRef2); // -> true

If they’re distinct objects, even if they contain identical properties, the comparison will result in false.

var arr1 = ['Hi!'];
var arr2 = ['Hi!'];

console.log(arr1 === arr2); // -> false

If we have two distinct objects and want to see if their properties are the same, the easiest way to do so is to turn them both into strings and then compare the strings. When the equality operators are comparing primitives, they simply check if the values are the same.

var arr1 = ['Hi!'];
var arr2 = ['Hi!'];

var arr1str = JSON.stringify(arr1);
var arr2str = JSON.stringify(arr2);

console.log(arr1str === arr2str); // true

Note that using JSON.stringify will cause problems if some of the properties are functions or undefined as it skips those values. A safer option would be to recursively loop through the objects and make sure each of the properties is the same.

Passing Parameters through Functions

When we pass primitive values into a function, the function copies the values into its parameters. It’s effectively the same as using =.

var hundred = 100;
var two = 2;

function multiply(x, y) {
    // PAUSE
    return x * y;
}

var twoHundred = multiply(hundred, two);

In the example above, we give hundred the value 100. When we pass it into multiply, the variable x gets that value, 100. The value is copied over as if we used an = assignment. Again, the value of hundred is not affected. Here is a snapshot of what the memory looks like right at the // PAUSE comment line in multiply.

Pure Functions

We refer to functions that don’t affect anything in the outside scope as pure functions. As long as a function only takes primitive values as parameters and doesn’t use any variables in its surrounding scope, it is automatically pure, as it can’t affect anything in the outside scope. All variables created inside are garbage-collected as soon as the function returns.

A function that takes in an Object, however, can mutate the state of its surrounding scope. If a function takes in an array reference and alters the array that it points to, perhaps by pushing to it, variables in the surrounding scope that reference that array see that change. After the function returns, the changes it makes persist in the outer scope. This can cause undesired side effects that can be difficult to track down.

Many native array functions, including Array.map and Array.filter, are therefore written as pure functions. They take in an array reference and internally, they copy the array and work with the copy instead of the original. This makes it so the original is untouched, the outer scope is unaffected, and we’re returned a reference to a brand new array.

Let’s go into an example of a pure vs. impure function.

function changeAgeImpure(person) {
    person.age = 25;
    return person;
}

var alex = {
    name: 'Alex',
    age: 30
};

var changedAlex = changeAgeImpure(alex);

console.log(alex); // -> { name: 'Alex', age: 25 }
console.log(changedAlex); // -> { name: 'Alex', age: 25 }

This impure function takes in an object and changes the property age on that object to be 25. Because it acts on the reference it was given, it directly changes the object alex. Note that when it returns the person object, it is returning the exact same object that was passed in. alex and alexChanged contain the same reference. It’s redundant to return the person variable and to store that reference in a new variable.

Let’s look at a pure function.

function changeAgePure(person) {
    var newPersonObj = JSON.parse(JSON.stringify(person));
    newPersonObj.age = 25;
    return newPersonObj;
}

var alex = {
    name: 'Alex',
    age: 30
};

var alexChanged = changeAgePure(alex);

console.log(alex); // -> { name: 'Alex', age: 30 }
console.log(alexChanged); // -> { name: 'Alex', age: 25 }

In this function, we use JSON.stringify to transform the object we’re passed into a string, and then parse it back into an object with JSON.parse. By performing this transformation and storing the result in a new variable, we’ve created a new object. The new object has the same properties as the original but it is a distinctly separate object in memory.

When we change the age property on this new object, the original is unaffected. This function is now pure. It can’t affect any object outside its own scope, not even the object that was passed in. The new object needs to be returned and stored in a new variable or else it gets garbage collected once the function completes, as the object is no longer in scope.

Test Yourself

Value vs. reference is a concept often tested in coding interviews. Try to figure out for yourself what’s logged here.

function changeAgeAndReference(person) {
    person.age = 25;
    person = {
      name: 'John',
      age: 50
    };

    return person;
}

var personObj1 = {
    name: 'Alex',
    age: 30
};

var personObj2 = changeAgeAndReference(personObj1);

console.log(personObj1); // -> ?
console.log(personObj2); // -> ?

The function first changes the property age on the original object it was passed in. It then reassigns the variable to a brand new object and returns that object. Here’s what the two objects are logged out.

console.log(personObj1); // -> { name: 'Alex', age: 25 }
console.log(personObj2); // -> { name: 'John', age: 50 }

Remember that assignment through function parameters is essentially the same as an assignment with =. The variable person in the function contains a reference to the personObj1 object, so it initially acts directly on that object. Once we reassign person to a new object, it stops affecting the original.

This reassignment does not change the object that personObj1 points to in the outer scope. person has a new reference because it was reassigned but this reassignment doesn’t change personObj1.

An equivalent piece of code to the above block would be:

var personObj1 = {
    name: 'Alex',
    age: 30
};

var person = personObj1;
person.age = 25;

person = {
    name: 'John',
    age: 50
};

var personObj2 = person;

console.log(personObj1); // -> { name: 'Alex', age: 25 }
console.log(personObj2); // -> { name: 'John', age: 50 }

The only difference is that when we use the function, person is no longer in scope once the function ends.

That’s it.

If you enjoyed this, please hit the heart so that it reaches more people.

Again, for interactive code samples, feel free to read this article for free through my course. There are other free articles available to read.