DEV Community: Ryan Ameri

Think Like JavaScript

Ryan Ameri — Wed, 09 Sep 2020 17:00:24 +0000

JavaScript is peculiar

JavaScript is a peculiar and unique language. Peculiar because on the surface, it's a scripting language with a syntax which largely resembles languages such as Java and C#. Deep down however, it's got more in common with programming languages such as Scheme and Self; languages that are mostly unknown outside of computer science academic circles or niche specialties. Most of us approaching JavaScript with a background in Java or PHP are initially deceived by JavaScript's Java-like syntax into thinking we know how it works. Then we scratch the surface, come across prototypes or how to determine the scope of this, and our mental model breaks down. Suddenly JavaScript looks weird, and our code has inexplicable bugs.

But JavaScript is universal

But JavaScript is the world's most used programming language. It is also the lingua franca of the biggest platform ever created: the Web. In terms of reach, number of users or number of applications developed, the web is larger than iOS, Android and Windows combined; and JavaScript has been pretty much its only programming language since first introduced in 1995. Many have tried to dislodge it from its place, Sun with Java applets, Adobe with Flash and ActionScript, Microsoft with JScript and Active X, and later on again with .Net and Silverlight, Google with Chrome Native Client. All have failed. I am a big fan of Wasm and very hopeful that it can succeed in bringing other programming languages to the web, but I have no doubts that twenty years from now, as was the case twenty years ago, the main language of the web will still be JavaScript.

Not that JavaScript's use is limited to frontend web development of course; with node.js and Deno it runs on the backend, with Electron it runs desktop applications, and with React Native (amongst others) it can be used to create mobile apps. No matter which area we practice in, it is upon us as practitioners to learn our tools well. If our tool is JavaScript and we want to learn how to write code with less bugs, we need to understand how to think like JavaScript.

Kyle Simpson says:

Whenever there's a divergence between what your brain thinks is happening, and what the computer does, that's where bugs enter code

Who is this series for

In this series, we'll do a deep dive into the foundations of JavaScript. This series is geared towards the intrepid developer who has a fair understanding of using JavaScript and wants to delve a bit more into its internals to see how it really works. If you have around a year of JavaScript programming under your belt, or are able to follow the exercises in my Mastering Hard Parts of JavaScript series, you're good to go!

In particular, if you've ever wondered:

What exactly is the difference between == and ===? (hint: if you think that == doesn't check the types, you are mistaken!)
Why were let and const introduced and what do they actually do that's different to var?
What's the difference between a function declaration and function expression? What is this "hoisting" you keep seeing?
Where should you use arrow functions and where should you avoid them?
Should you use this? Or should you architecture your code to avoid using it?
Is there a place for factory functions in modern JavaScript with ES Modules?
How are classes implemented with prototypes? And what's a prototype anyway?

This series will hopefully prove useful.

A note on JavaScript's backwards compatibility

I won't repeat the rather unique history of JavaScript here, which has been well covered elsewhere; but throughout the series we will come across historical bugs (hello typeof null === 'object'!) or features that were fixed in later years by adding more features, and it's important to understand why JavaScript is developed the way it is.

From its birth by Brendan Eich at Netscape, JavaScript has gone through periods of neglect (1999 to 2009) as well as rapid advancement (2015 til present). What has remained constant however has been the JavaScript designers' absolute commitment to backwards compatibility. Every line of code written by a developer in 1997 that conformed to the first standardised version of JavaScript (ES1) will run exactly as its author intended in the latest versions of Chrome and Firefox, even on devices that could not have been imagined in 1997.

Most other popular languages of the past twenty something years can't boast the same claim. Python programs written in say 2005 would have been written in Python 2, and they would need to be ported to Python 3 (which is not backwards compatible with Python 2) to continue working today. The PHP folks similarly went through huge pains going from PHP 5 to PHP 6 (which was abandoned) and now PHP 7. Perl 6 similarly diverged from Perl 5 so much that the people behind it decided to spin it off as a different programming language. This is not to disparage these programming communities. Breaking backwards compatibility has huge benefits: it allows the language designers to clear out the bad parts of a language, or to re-architect it to move with the times.

JavaScript however has not had the luxury of breaking backwards compatibility due to its unique place as the language of the web. The designers of JavaScript have always been aware that changing JavaScript in a backwards incompatible way would mean that some old, neglected, but still useful website out there would break and never be fixed again. As such they've had to evolve JavaScript with this huge constraint around their neck. They even take this commitment so seriously that when introducing new features to the language, they try to make sure that whatever keyword they pick up breaks the least number of websites and libraries out there (this is how we end up with inelegant names such as globalThis).

It's important to keep this unique history in mind as we learn to think like JavaScript, which involves being aware of its historical bugs and peculiarities. On the other hand, as a JavaScript developer, you are blessed knowing that whatever code you write will probably run as you intend it, twenty years from now.

Structure of the series and credits

The "Think Like JavaScript" series will cover the following pillars of JavaScript:

Types
- Primitive Types
- Abstract Operations
- Coercion
- Equality
- Statically typed supersets e.g., TypeScript
Scope
- Nested Scope
- Hoisting
- Closure
- Modules
Objects
- this
- Class
- Prototypes

Each section will end with a practice exercise to solidify the topics covered in the post. In the latter sections, we will develop a library checkout system and implement the same program using various different structures: using functions, modules, classes and prototypes. This will enable us to clearly see the pros and cons of each, and where each structure might be preferred.

Though this blog series' content and presentation are my own and original, I owe a heavy debt to Kyle Simpson for his excellent Deep JavaScript Foundations v3 course on Frontend Masters. I'd highly encourage those who want to dive more in-depth to take the course and to read his You Don't Know JS book series. This does not imply that the content here is in any shape or form endorsed or approved by Kyle Simpson.

Mastering Hard Parts of JavaScript: Prototype & Class V

Ryan Ameri — Wed, 26 Aug 2020 17:00:24 +0000

Subclassing & Mixins

Exercise 10

Create an object adminFunctionStore that has access to all methods in the userFunctionStore object, without copying them over individually.

const userFunctionStore = {
  sayType: function () {
    console.log("I am a " + this.type);
  },
};

Solution 10

const adminFunctionStore = Object.create(userFunctionStore);

Exercise 11

Create an adminFactory function that creates an object with all the same data fields (and default values) as objects of the userFactory class, but without copying each data field individually.

function userFactory(name, score) {
  let user = Object.create(userFunctionStore);
  user.type = "User";
  user.name = name;
  user.score = score;
  return user;
}

Solution 11

function adminFactory(name, score) {
  const admin = Object.create(adminFunctionStore);
  admin.name = name;
  admin.score = score;
  return admin;
}

Exercise 12

Then make sure the value of the 'type' field for adminFactory objects is 'Admin' instead of 'User'.

Solution 12

adminFunctionStore.type = "Admin";

Exercise 13

Make sure that adminFactory objects have access to adminFunctionStore methods, without copying them over.

function adminFactory(name, score) {
  // Put code here
}

Solution 13

function adminFactory(name, score) {
  const admin = Object.create(adminFunctionStore);
  admin.name = name;
  admin.score = score;
  return admin;
}

Exercise 14

Created a method called sharePublicMessage that logs 'Welcome users!' and will be available to adminFactory objects, but not userFactory objects. Do not add this method directly in the adminFactory function.

const adminFromFactory = adminFactory("Eva", 5);
adminFromFactory.sayType();
// -> Logs "I am a Admin"
adminFromFactory.sharePublicMessage();
// -> Logs "Welcome users!"

Solution 14

userFunctionStore.sharePublicMessage = function () {
  console.log("Welcome users!");
};

Exercise 15

Mixins are a tool in object-oriented programming that allows objects to be given methods and properties beyond those provided by their inheritance. For this challenge, complete the missing code, giving all of the robotMixin properties to robotFido. Do this in a single line of code, without adding the properties individually.

class Dog {
  constructor() {
    this.legs = 4;
  }
  speak() {
    console.log("Woof!");
  }
}

const robotMixin = {
  skin: "metal",
  speak: function () {
    console.log(`I have ${this.legs} legs and am made of ${this.skin}`);
  },
};

let robotFido = new Dog();

robotFido = /* Put code here to give Fido robot skills */;
robotFido.speak()
// -> Logs "I am made of metal"

Solution 15

Object.assign(robotFido, robotMixin);

In JavaScript, each object's [[prototype]] can only refer to one other object (in traditional OOP speak, each class can only extend from one class). How do we give an object extra methods declared elsewhere? Object.assign allows us to to that, the first argument is an object, and the second argument is also an object which has a bunch of methods. It adds those methods to the first object.

This brings to an end our Mastering Hard Parts of JavaScript tutorial series. If you have followed each section and implemented your own solutions, take a moment to reflect just how much you have learnt and how far you have come in your understanding of the hard parts of JavaScript!

I am sure my tutorial series is not without its faults. If you find any errors or a better way of solving any of these exercises, please do leave a comment, or send a PR to the github repo. Thanks!

Mastering Hard Parts of JavaScript: Prototype & Class IV

Ryan Ameri — Tue, 25 Aug 2020 20:40:26 +0000

Using ES6 Classes

Exercise 8

Create a class PersonClass. PersonClass should have a constructor that is passed an input of name and saves it to a property by the same name. PersonClass should also have a method called greet that logs the string 'hello'.

class PersonClass {
  constructor() {
    // add code here
  }

  // add code here
}
const george = new PersonClass();
george.greet();
// -> Logs 'hello'

Solution 8

class PersonClass {
  constructor(name) {
    this.name = name;
  }

  greet() {
    console.log("hello");
  }
}

An exact recreation of Exercise 2 and 5, here using the class pattern. More readable for people who come from other languages, though many JS diehards complain that this pattern just doesn't look native to JS. In effect the JS engine is doing exactly what it did in Exercise 5.

Exercise 9

Create a class DeveloperClass that creates objects by extending the PersonClass class. In addition to having a name property and greet method, DeveloperClass should have an introduce method. When called, introduce should log the string 'Hello World, my name is [name]'.

const thai = new DeveloperClass("Thai", 32);
console.log(thai.name);
// -> Logs 'Thai'
thai.introduce();
//-> Logs 'Hello World, my name is Thai'

Solution 9

class DeveloperClass {
  constructor(name, age) {
    this.name = name;
    this.age = age;
  }
  introduce() {
    console.log(`Hello World, my name is ${this.name}`);
  }
}

This of course is exactly like exercise 7, but uses the class syntax instead of adding a method to the prototype property directly. Again, behind the scenes, the JS engine performs exactly the same operation.

Mastering Hard Parts of JavaScript: Prototype & Class III

Ryan Ameri — Fri, 21 Aug 2020 20:54:28 +0000

Using the `new` keyword

Exercise 5

Create a function PersonConstructor that uses the this keyword to save a single property onto its scope called greet. greet should be a function that logs the string 'hello'.

function PersonConstructor() {
  // add code here
}

const simon = new PersonConstructor();
simon.greet();
// -> Logs 'hello'

Solution 5

function PersonConstructor() {
  this.greet = function () {
    console.log("hello");
  };
}

Wait, what's happening here? Actually nothing we have not seen before. The new keyword is a modifier, it makes some changes to the function that follows it (in this case the PersonConstructor function). What changes you ask? Nothing we haven't seen in previous exercises. It basically creates a new empty object, sets its [[prototype]] correctly, assigns it to the value this and returns this object. We can of course add new properties to this this object, which will be methods. And we're adding a greet method here to our object.

new doesn't do anything magical. It just automates what we've been doing manually until this point, create an empty object, set its [[prototype]] and return it. That's it!

Exercise 6

Create a function personFromConstructor that takes as input a name and an age. When called, the function will create person objects using the new keyword instead of the Object.create method.

function personFromConstructor(name, age) {
  // add code here
}

const mike = personFromConstructor("Mike", 30);
console.log(mike.name); // -> Logs 'Mike'
console.log(mike.age); //-> Logs 30
mike.greet(); //-> Logs 'hello'

Solution 6

function personFromConstructor(name, age) {
  const person = new PersonConstructor();
  person.name = name;
  person.age = age;
  return person;
}

A combination of using new to create a new object, but then giving it extra properties (which are passed as parameters) and returning this object. Nothing terribly new happening here, just a combination of the two patterns we've seen before.

Exercise 7

Without editing the code you've already written, add an introduce method to the PersonConstructor function that logs "Hi, my name is [name]".

mike.introduce();
// -> Logs 'Hi, my name is Mike'

Solution 7

PersonConstructor.prototype.introduce = function () {
  console.log(`Hi, my name is ${this.name}`);
};

Notice that this is very similar to Exercise 4, we are adding a method to an object. But which object? In Exercise 4, we had manually defined the name of our object as personStore so we simply added introduce as a property of that object. Here we don't have the name of the object that the JS engine automatically creates for us using the new keyword, so where can we store our functions? The answer is the (confusingly named) property prototype, which itself is an object.

Remember that all functions are objects in JavaScript? So PersonConstructor is a function which we can execute when we use (). But it's also an object, and we can access its properties like any other object using the dot notation. So in order to add any methods to our personConstructor function, we access its prototype property and add our methods there.

Spend some time to compare and contrast exercises 2, 3 and 4 with exercises 5, 6 and 7. You'll see that they are fundamentally doing the same thing. This comparison should make clear what the keyword new does and what the property prototype refers to.

Mastering Hard Parts of JavaScript: Prototype & Class II

Ryan Ameri — Thu, 20 Aug 2020 21:03:34 +0000

Using Object.create()

Exercise 2

Inside personStore object, create a property greet where the value is a function that logs "hello".

const personStore = {
  // add code here
};

personStore.greet(); // -> Logs 'hello'

Solution 2

const personStore = {
  greet: function someName() {
    console.log("hello");
  },
};

Here greet is just a property on an object. It's value happens to be a function (that does something). We can access that property like accessing any other property of an object, using the dot notation personStore.greet. And since it's a function, we can run the function by adding the parentheses so personStore.greet() works and runs the function that we have defined.

It turns out the name of this function someName is not important since it's assigned to the property greet and so someName is never directly used. So we can turn it into an anonymous function:

const personStore = {
  greet: function () {
    console.log("hello");
  },
};

And later on in ES6, they introduced a new more concise syntax, which allows us to write this example as:

const personStore = {
  greet() {
    console.log("hello");
  },
};

All three solution shown here do exactly the same thing.

Exercise 3

Create a function personFromPersonStore that takes as input a name and an age. When called, the function will create person objects using the Object.create method on the personStore object.

function personFromPersonStore(name, age) {
  // add code here
}

const sandra = personFromPersonStore("Sandra", 26);
console.log(sandra.name);
// -> Logs 'Sandra'
console.log(sandra.age);
//-> Logs 26
sandra.greet();
//-> Logs 'hello'

Solution 3

function personFromPersonStore(name, age) {
  const person = Object.create(personStore);
  person.name = name;
  person.age = age;
  return person;
}

The important thing to note here is that Object.create(), irrespective of the argument passed to it, always returns an empty object. So initially, person is an empty object with no properties.

Every object has a hidden [[prototype]] property (bad name!). Simply put, when you call a property on an object, the JS engine first checks to see if the object has that property. If it can't find such a property, it will look at its [[prototype]] property to see which Object it descends from. const person = Object.create(personStore) tells the JS engine to create a new empty object and return it and call it person, but if we call a property of person and person doesn't have that property, look up to personStore and see if it has that property.

So when sandra.name is called, the JS engine looks at the sandra object to see if it has a name property. It does, so its value is returned. Next when sandra.age is called, the JS engine looks at the sandra object to see if it has an age property. It does, so its value is returned. Next, sandra.greet() is called. The JS engine looks at the object sandra to see if it has a greet property. It does not. Instead of failing, the JS engine then looks at sandra's hidden [[prototype]] property which points to personStore, so it then goes to see if personStore has a greet property. It does, so that function is invoked.

This basically achieves what class-based object oriented languages call inheritance, without using any classes. This is a gross simplification of JavaScript's prototypal architecture, for more information I've found this chapter of the javascript.info very helpful.

Exercise 4

Without editing the code you've already written, add an introduce method to the personStore object that logs "Hi, my name is [name]".

// add code here
sandra.introduce();
// -> Logs 'Hi, my name is Sandra'

Solution 4

personStore.introduce = function () {
  console.log(`Hi, my name is ${this.name}`);
};

We can add methods to our personStore at a later time. And the dynamic nature of JS means that even though sandra was created before we created this method, it still gets to use it. Here we also see our first introduction to the this keyword. In this context, this is always the value of the object to the left of the the function being invoked. So here when introduce() is called, the object to its left is sandra, so this gets assigned to sandra. Now when in the body of the method this.name is equal to sandra.name so its value is returned.

Do not use arrow functions when declaring methods on an object. In arrow functions this is lexically scoped, so in this example, if we had declared

personStore.introduce = () => {
  console.log(`Hi, my name is ${this.name}`);
};

Here this would not refer to sandra. It would look to see if the function introduce has a this, it doesn't. So it would look at its outside scope to see if it has a this. Here the outside scope is the global memory or window, which does have an object called this so it checks to see if that object has a name property. It doesn't, so undefined is returned.

Understanding the prototype chain, what JavaScript's lexical scoping means, and how arrow functions change the behaviour of this are perhaps the most challenging parts of JavaScript for someone new to the language. It requires practice, but it will make sense in the end.

Mastering Hard Parts of JavaScript: Prototype & Class I

Ryan Ameri — Wed, 19 Aug 2020 23:27:54 +0000

How come JavaScript is not Object Oriented but everything in JavaScript is an Object?

You've probably heard that in JavaScript, "everything is an object". This is actually incorrect (primitive types such as String or undefined are not objects), but a lot of things, i.e., everything other than primitive types is an object, for example functions, arrays or data structures such as Set or Map. JavaScript is a strongly Object Oriented language, yet many people coming to it from other languages such as Python or Java find JavaScript's OO design baffling. Why is that? It's because JavaScript was traditionally a prototypal, classless Object Oriented language.

Prototypal and class-based object oriented languages both implement OOP principles but in strikingly different ways. Each have their own pros and cons and neither is inherently superior to the other. However if you come from a background in Java or Python or C#, spending some time to coming to grips with JavaScript's prototypal structure will pay huge dividends.

In recent times (ES6), a class keyword was added to JavaScript that closely mimics the class-based OOP of other languages. But class is simply syntactic sugar in JS, and under the hood it still implements OOP using prototypal concepts. Even if you prefer using the class structure, understanding JS's prototypes is required to be able to properly debug your code or understand how it works.

In the first part of this section, we'll solve our exercises using object literals, which is the original/old-fashioned way of implementing OOP in JS. Next we'll use the Object.create() method that was added to ES5. In the third section we'll see how the use of the new keyword simplifies object creation (but doesn't fundamentally change anything). Finally we'll see the class structure that was introduced in ES6.

Just to clarify, the heading of this section was written in jest. JavaScript is an Object Oriented language, and not everything in JavaScript is an object.

Using Object Literals

Exercise 1

Create a function that accepts two inputs (name and age) and returns an object. Let's call this function makePerson. This function will:

create an empty object

add a name property to the newly created object with its value being the 'name' argument passed into the function

add an age property to the newly created object with its value being the 'age' argument passed into the function return the object.

function makePerson(name, age) {
  //add code here
}

const vicky = makePerson("Vicky", 24);
console.log(vicky.name);
// -> Logs 'Vicky'
console.log(vicky.age);
// -> Logs 24

Solution 1

function makePerson(name, age) {
  const person = {};
  person.name = name;
  person.age = age;
  return person;
}

Creating an object the "old fashioned" way using a function. No one uses this pattern anymore, but everything that comes later (such as Object.create() or new) is still doing this in the background, so it's important to spend some time to study how this function works.

Mastering Hard Parts of JavaScript: Asynchronicity III

Ryan Ameri — Tue, 18 Aug 2020 21:56:12 +0000

Exercise 6

Write a function called everyXsecsForYsecs that will accept three arguments: a function func, a number interval, and another number duration. everyXsecsForYsecs will execute the given function every interval number of milliseconds, but then automatically stop after duration milliseconds. Then pass the below sayHi function into an invocation of everyXsecsForYsecs with 1000 interval time an 5000 duration time. What do you expect to happen?

function everyXsecsForYsecs() {}
function theEnd() {
  console.log("This is the end!");
}
everyXsecsForYsecs(theEnd, 2, 20);
// should invoke theEnd function every 2 seconds, for 20 seconds): This is the end!

Solution 6

function everyXsecsForYsecs(func, interval, duration) {
  const id = setInterval(func, interval * 1000);
  function clear() {
    clearInterval(id);
  }
  setTimeout(clear, duration * 1000);
}

This turns out to be very similar to the previous exercise, another way of practicing setInterval and clearInterval. Here the function to be executed is passed on as an argument, but other than that everything should look familiar.

Exercise 7

Write a function delayCounter that accepts a number (called 'target') as the first argument and a number of milliseconds (called 'wait') as the second argument, and returns a function.

When the returned function is invoked, it should log to the console all of the numbers between 1 and the target number, spaced apart by 'wait' milliseconds.

function delayCounter() {}

const countLogger = delayCounter(3, 1000);
countLogger();
//After 1 second, log 1
//After 2 seconds, log 2
//After 3 seconds, log 3

Solution 7

function delayCounter(target, wait) {
  function closureFn() {
    let i = 1;
    const id = setInterval(() => {
      console.log(i);
      i++;
      if (i > target) clearInterval(id);
    }, wait);
  }
  return closureFn;
}

We're putting all the concepts we've practiced on callbacks, closure and asynchronicity to good use here! The description demands that our function should return another function, so we're talking closure. We're also calling clearInterval in the callback function given to setInterval. Every time setInterval is invoked, we increment our counter i that's declared in the outside scope (our memory). We check to make sure that our counter is still lower than our target, and when it goes above that, we execute clearInterval.

Exercise 8

Write a function, promised, that takes in a value. This function will return a promise that will resolve after 2 seconds.

function promised() {}

const createPromise = promised("wait for it...");
createPromise.then((val) => console.log(val));
// will log "wait for it..." to the console after 2 seconds

Solution 8

function promised(val) {
  return new Promise((resolve) => {
    setTimeout(() => resolve(val), 2000);
  });
}

If you are not familiar with the syntax of a Promise (hint: there's always MDN) this can look a bit confusing. The important thing to remember is that a promise can take one or two parameters, the first is the function to be called when the promise is resolved, and the second (optional, not shown here) is the function to be called when the operation fails.

So in this exercise, we are creating a Promise and returning it. The resolve function is given to the Promise when the .then method is called on it. Here we just execute that function with a setTimeout set to 2 seconds.

Exercise 9

Write a SecondClock class, with two methods: start and reset.
start: upon invocation, invokes a callback (this.cb, defined in the constructor) on an argument every second, with the argument to the callback being the current seconds "value".

In other words, the callback gets invoked every second on the "seconds hand" of the clock. Always start with 1 and don't utilize the seconds value of the current computer clock time.

The first "tick" with value 1 occurs 1 second after the initial "secondClock" invocation.
The second "tick" with value 2 occurs 2 seconds after the initial "secondClock" invocation.

The sixtieth "tick" with value 60 occurs 60 seconds after the initial "secondClock" invocation.
The sixty-first "tick" with value 1 occurs 61 seconds after the initial "secondClock" invocation. The sixty-second "tick" with value 2 occurs 62 seconds after the initial "secondClock" invocation.
etc.

reset: upon invocation, completely stops the "clock". Also resets the time back to the beginning Hint: look up setInterval and clearInterval.

class SecondClock {}

const clock = new SecondClock((val) => {
  console.log(val);
});
console.log("Started Clock.");
clock.start();
setTimeout(() => {
  clock.reset();
  console.log("Stopped Clock after 6 seconds.");
}, 6000);

Solution 9

class SecondClock {
  constructor(cb) {
    this.cb = cb;
    this.seconds = 0;
    this.id = undefined;
  }
  start() {
    this.id = setInterval(() => {
      this.seconds++;
      this.cb(this.seconds % 60);
    }, 1000);
  }
  reset() {
    this.seconds = 0;
    clearInterval(this.id);
  }
}

The description again looks a bit daunting, but as always the challenge in solving the problem requires breaking it down into simpler parts. Solving this exercise requires a bit of a knowledge of the class syntax as well, which we will practice a lot in the next section of this series.

What this exercise is trying to show us is how to implement something very similar to exercise 7, but here using class structure instead of closure. So instead of having an outer variable that acts as our memory, here our memory is a class field. We've got two class methods, start and reset that basically manipulate our counter using a callback function that's first given to us in the constructor.

Exercise 10

Write a function called debounce that accepts a function and returns a new function that only allows invocation of the given function after interval milliseconds have passed since the last time the returned function ran.

Additional calls to the returned function within the interval time should not be invoked or queued, but the timer should still get reset.

For examples of debouncing, check out this CSS Tricks article.

function debounce() {}

function giveHi() {
  return "hi";
}
const giveHiSometimes = debounce(giveHi, 3000);
console.log(giveHiSometimes());
// should output 'hi'
setTimeout(function () {
  console.log(giveHiSometimes());
}, 2000);
// should output undefined
setTimeout(function () {
  console.log(giveHiSometimes());
}, 4000);
//should output undefined
setTimeout(function () {
  console.log(giveHiSometimes());
}, 8000);
// should output 'hi'

Solution 10

function debounce(callback, interval) {
  let counter = 0;
  let hasRan = false;
  function closureFn() {
    let id = undefined;
    if (!hasRan) {
      ///this is the first run
      id = setInterval(() => counter++, 1);
      hasRan = true;
      return callback();
    } else {
      //for subsequent runs
      if (counter < interval) {
        // Not enough time has elapsed
        counter = 0;
        clearInterval(id);
        id = setInterval(() => counter++, 1);
        return undefined;
      } else {
        //Enough time has elapsed
        counter = 0;
        clearInterval(id);
        id = setInterval(() => counter++, 1);
        return callback();
      }
    }
  }
  return closureFn;
}

Debouncing and throttling are important concepts in modern web development (this functionality is provided by many libraries). Here we're implementing a simple debounce using closure and callbacks. We need a counter and a flag to indicate whether the function has ran before before, these variables need to reside in our memory, so in the outer scope. We then increment the counter using setInterval, and in subsequent runs we check to see if enough time has passed or not (based on interval). If enough time has not passed, we need to reset the counter and return undefined. If enough time has passed, we again reset the counter but this time execute and return the callback.

This brings our asynchronicity chapter to a close. Next we'll take a closer look at class and the prototype.

Mastering Hard Parts of JavaScript: Asynchronicity II

Ryan Ameri — Mon, 17 Aug 2020 21:05:03 +0000

Exercise 1

Thinking point (no writing code necessary for this challenge): Inspect the code given to you in Challenge 1. In what order should the console logs come out? Howdy first or Partnah first?

function sayHowdy() {
  console.log("Howdy");
}

function testMe() {
  setTimeout(sayHowdy, 0);
  console.log("Partnah");
}
testMe();

Solution 1

The output is Partnah first, followed by Howdy. As discussed, setTimeout is a callback function so its execution gets placed in the task queue, it is invoked only after everything in the call stack is executed.

Exercise 2

Create a function delayedGreet that console logs welcome after 3 seconds.

function delayedGreet() {}

delayedGreet();
// should log (after 3 seconds): welcome

Solution 2

function delayedGreet() {
  setTimeout(() => console.log("welcome"), 3000);
}

A gentle introduction, but an important foundation. This is how to wrap a callback function (which in reality is not a browser API) in our own function.

Exercise 3

Create a function helloGoodbye that console logs hello right away, and good bye after 2 seconds.

function helloGoodbye() {}

helloGoodbye();
// should log: hello should also log (after 3 seconds): good bye

Solution 3

function helloGoodbye() {
  console.log("hello");
  setTimeout(() => console.log("good bye"), 3000);
}

Notice that we could have also written

function helloGoodbye() {
  setTimeout(() => console.log("good bye"), 3000);
  console.log("hello");
}

The order doesn't matter in this example, as console.log will always get executed first before setTimeout is called.

Exercise 4

Create a function brokenRecord that console logs hi again every second. Use the End Code button to stop the console logs when you are satisfied that it is working.

function brokenRecord() {}
brokenRecord();
// should log (every second): hi again

Solution 4

function brokenRecord() {
  function printHi() {
    console.log("hi again");
  }
  setInterval(printHi, 1000);
}

If you haven't seen setInterval before, you might be tempted to use a loop here but that won't get you the desired output. setInterval is a method of the Web APIs that the browser/environment provide. As always MDN is a fantastic way of delving into them all.

Exercise 5

Create a function limitedRepeat that console logs hi for now every second, but only for 5 seconds. Research how to use clearInterval if you are not sure how to do this.

function limitedRepeat() {}
limitedRepeat();
// should log (every second, for 5 seconds): hi again

Solution 5

function limitedRepeat() {
  function printHi() {
    console.log("hi again");
  }
  function clear() {
    clearInterval(id);
  }
  printHi();
  const id = setInterval(printHi, 1000);
  setTimeout(clear, 5000);
}

And here is setInterval's counterpart: clearInterval. When we call setInterval, it returns an Interval ID which uniquely identifies the interval. We can pass that to clearInterval to stop the interval.

Mastering Hard Parts of JavaScript: Asynchronicity I

Ryan Ameri — Mon, 17 Aug 2020 00:37:19 +0000

The Event Loop

Understanding asynchronicity in JavaScript requires understanding one fundamental concept: what will the JS engine execute next? This is a very simplified overview of how to answer this question, more formally known as the Event Loop.

JavaScript is (for the most part) single threaded, so if everything in JavaScript was synchronous, The JS engine would execute every statement one by one as they appear in the source code, wait for the execution to finish, and go to the next line.

However that would be incredibly limiting when it comes to web development. To solve this problem, some APIs that the browser/node.js provide are asynchronous, which basically means that they don't execute when the JS engine first runs into them. Instead they get put in a queue, to be executed once all the synchronous statements have finished. Let's consider:

function printHello() {
  console.log("Hello");
}
setTimeout(printHello, 0);
console.log("Me first!");

Because setTimeout is told to execute printHello at 0 milliseconds, one could reason that the output should be:

Hello
Me first!

But in fact the the output is

Me first!
Hello

This is because setTimeout is an asynchronous API (a callback function), so its execution gets placed in the "task queue". Anything in the task queue is only executed after all synchronous code has already run.

Note: console.log is in fact itself an asynchronous function but I'm glossing over that detail for the sake of simplicity and clear demonstration of the concept.

Promises

Promises, introduced in ES6, add one additional queue to the mix. Consider:

function display(data){console.log(data)}
function printHello(){console.log("Hello");}
function blockForLong(){
    const arr = [];
    for (let i = 0; i < 3_000_000_000; i++>){
        arr.push(i)
    }
 }
setTimeout(printHello, 0);
const futureData = fetch('https://twitter.com/AmeriRyan/status/1291935897076641792')
futureData.then(display)
blockForLong()
console.log("Me first!");

This code won't run correctly as this is not exactly how fetch() works, but for the sake of simplicity, let's assume that fetch is a function that takes a URL as a string and returns a Promise. blockForLong is a function that doesn't do anything important for our purposes but is a synchronous function that takes a long time to execute. We first call setTimeout that runs printHello at 0 milliseconds. Then we handle the Promise and pass it to a function display that just prints it to console. Then we execute blockForLong and finally we execute console.log. Can you guess what gets printed first?

First, all synchronous code is executed. That means blockForLong is called first, and then Me first! is printed to console. Promises get placed in a queue called the "micro task queue", which has priority over the "task queue" where callback functions are placed. So even though setTimeout appears first in the source code, we first call the display function with the returned data, and only call the printHello function last.

So, the Event Loop in JavaScript, in a nutshell, is:

Synchronous code
Anything in the micro task queue (Promises)
Anything in the task queue (callback functions)

If you can follow the execution order in the this example, you should be able to solve all the upcoming exercises (perhaps with a bit of help from MDN).

In the next section, we'll practice 10 exercises that should help us master asynchronicity as well as introduce us to Promises.

Mastering Hard Parts of JavaScript: Closure IV

Ryan Ameri — Sat, 15 Aug 2020 21:34:32 +0000

Exercise 16

Create a function average that accepts no arguments, and returns a function (that will accept either a number as its lone argument, or no arguments at all). When the returned function is invoked with a number, the output should be average of all the numbers have ever been passed into that function (duplicate numbers count just like any other number). When the returned function is invoked with no arguments, the current average is outputted. If the returned function is invoked with no arguments before any numbers are passed in, then it should return 0.

function average() {}

const avgSoFar = average();
console.log(avgSoFar()); // => should log 0
console.log(avgSoFar(4)); // => should log 4
console.log(avgSoFar(8)); // => should log 6
console.log(avgSoFar()); // => should log 6
console.log(avgSoFar(12)); // => should log 8
console.log(avgSoFar()); // => should log 8

Solution 16

function average() {
  let counter = 0;
  let total = 0;
  function closureFn(num) {
    if (num === undefined) {
      return counter === 0 ? 0 : total / counter;
    }
    counter++;
    total += num;
    return total / counter;
  }
  return closureFn;
}

Again the example output should make the required functionality clear. We are creating averages, so we need two variables in our outside scope, a counter to keep count and a variable to keep track of the total of arguments that have been passed total. Our inside function then exhibits different functionality based on whether it receives an argument or not.

Exercise 17

Create a function makeFuncTester that accepts an array (of two-element sub-arrays), and returns a function (that will accept a callback). The returned function should return true if the first elements (of each sub-array) being passed into the callback all yield the corresponding second elements (of the same sub-array). Otherwise, the returned function should return false.

function makeFuncTester() {}
const capLastTestCases = [];
capLastTestCases.push(["hello", "hellO"]);
capLastTestCases.push(["goodbye", "goodbyE"]);
capLastTestCases.push(["howdy", "howdY"]);
const shouldCapitalizeLast = makeFuncTester(capLastTestCases);
const capLastAttempt1 = (str) => str.toUpperCase();
const capLastAttempt2 = (str) => str.slice(0, -1) + str.slice(-1).toUpperCase();
console.log(shouldCapitalizeLast(capLastAttempt1));
// => should log false
console.log(shouldCapitalizeLast(capLastAttempt2));
// => should log true

Solution 17

function makeFuncTester(arrOfTests) {
  function closureFn(callback) {
    return arrOfTests.every((couple) => callback(couple[0]) === couple[1]);
  }
  return closureFn;
}

We are mixing closure and callbacks, so it can be a little confusing here, but basically passing an array (of arrays) to our outer function, and then when we provide a callback as an argument to the inside function, we want to make sure that the result of the callback is correctly stored as the second element in our original array.

Notice the use of Array.prototype.every() method here, a very useful Array method that returns true only if the callback returns true for every element of the array. It simplifies our code quite a bit.

Exercise 18

Create a function makeHistory that accepts a number (which will serve as a limit), and returns a function (that will accept a string). The returned function will save a history of the most recent "limit" number of strings passed into the returned function (one per invocation only). Every time a string is passed into the function, the function should return that same string with the word 'done' after it (separated by a space). However, if the string 'undo' is passed into the function, then the function should delete the last action saved in the history, and return that deleted string with the word 'undone' after (separated by a space). If 'undo' is passed into the function and the function's history is empty, then the function should return the string 'nothing to undo'.

function makeHistory() {}

const myActions = makeHistory(2);
console.log(myActions("jump"));
// => should log 'jump done'
console.log(myActions("undo"));
// => should log 'jump undone'
console.log(myActions("walk"));
// => should log 'walk done'
console.log(myActions("code"));
// => should log 'code done'
console.log(myActions("pose"));
// => should log 'pose done'
console.log(myActions("undo"));
// => should log 'pose undone'
console.log(myActions("undo"));
// => should log 'code undone'
console.log(myActions("undo"));
// => should log 'nothing to undo'

Solution 18

function makeHistory(limit) {
  const memory = [];
  function closureFn(input) {
    if (input !== "undo") {
      if (memory.length >= limit) memory.shift();
      memory.push(input);
      return input + " done";
    } else {
      if (memory.length === 0) return "nothing to do";
      let remove = memory.pop();
      return remove + " undone";
    }
  }
  return closureFn;
}

Implementing "undo" was an interesting challenge. Turns out we basically need our usual memory in the outer scope (this time in the form of an array) but our memory should only stretch limit items. So we need to keep count of how many items is in our memory array, and if we input more elements in it, implement a sliding window as in a FIFO way to only keep the correct number of items in it.

Exercise 19

Inspect the commented out test cases carefully if you need help to understand these instructions.

Create a function blackjack that accepts an array (which will contain numbers ranging from 1 through 11), and returns a DEALER function. The DEALER function will take two arguments (both numbers), and then return yet ANOTHER function, which we will call the PLAYER function.
On the FIRST invocation of the PLAYER function, it will return the sum of the two numbers passed into the DEALER function.

On the SECOND invocation of the PLAYER function, it will return either:

the first number in the array that was passed into blackjack PLUS the sum of the two numbers passed in as arguments into the DEALER function, IF that sum is 21 or below, OR
the string 'bust' if that sum is over 21.

If it is 'bust', then every invocation of the PLAYER function AFTER THAT will return the string 'you are done!' (but unlike 'bust', the 'you are done!' output will NOT use a number in the array). If it is NOT 'bust', then the next invocation of the PLAYER function will return either:

the most recent sum plus the next number in the array (a new sum) if that new sum is 21 or less, OR
the string 'bust' if the new sum is over 21.

And again, if it is 'bust', then every subsequent invocation of the PLAYER function will return the string 'you are done!'. Otherwise, it can continue on to give the next sum with the next number in the array, and so forth.
You may assume that the given array is long enough to give a 'bust' before running out of numbers.

BONUS: Implement blackjack so the DEALER function can return more PLAYER functions that will each continue to take the next number in the array after the previous PLAYER function left off. You will just need to make sure the array has enough numbers for all the PLAYER functions.

function blackjack() {}
// /*** DEALER ***/
const deal = blackjack([
  2,
  6,
  1,
  7,
  11,
  4,
  6,
  3,
  9,
  8,
  9,
  3,
  10,
  4,
  5,
  3,
  7,
  4,
  9,
  6,
  10,
  11,
]);

// /*** PLAYER 1 ***/
const i_like_to_live_dangerously = deal(4, 5);
console.log(i_like_to_live_dangerously());
// => should log 9
console.log(i_like_to_live_dangerously());
// => should log 11
console.log(i_like_to_live_dangerously());
// => should log 17
console.log(i_like_to_live_dangerously());
// => should log 18
console.log(i_like_to_live_dangerously());
// => should log 'bust'
console.log(i_like_to_live_dangerously());
// => should log 'you are done!'
console.log(i_like_to_live_dangerously());
// => should log 'you are done!'

// /*** BELOW LINES ARE FOR THE BONUS ***/

// /*** PLAYER 2 ***/
const i_TOO_like_to_live_dangerously = deal(2, 2);
console.log(i_TOO_like_to_live_dangerously());
// => should log 4
console.log(i_TOO_like_to_live_dangerously());
// => should log 15
console.log(i_TOO_like_to_live_dangerously());
// => should log 19
console.log(i_TOO_like_to_live_dangerously());
// => should log 'bust'
console.log(i_TOO_like_to_live_dangerously());
// => should log 'you are done!
console.log(i_TOO_like_to_live_dangerously());
// => should log 'you are done!

// /*** PLAYER 3 ***/
const i_ALSO_like_to_live_dangerously = deal(3, 7);
console.log(i_ALSO_like_to_live_dangerously());
// => should log 10
console.log(i_ALSO_like_to_live_dangerously());
// => should log 13
console.log(i_ALSO_like_to_live_dangerously());
// => should log 'bust'
console.log(i_ALSO_like_to_live_dangerously());
// => should log 'you are done!
console.log(i_ALSO_like_to_live_dangerously());
// => should log 'you are done!

Solution 19

function blackjack(array) {
  let dealerCount = 0;
  function dealer(a, b) {
    let playerCount = 0;
    let total = a + b;
    function player() {
      if (total === "bust") return "you are done!";
      dealerCount++;
      playerCount++;
      if (playerCount === 1) return total;
      total += array[dealerCount - 2];
      if (total > 21) {
        total = "bust";
        dealerCount--;
      }
      return total;
    }
    return player;
  }
  return dealer;
}

By this point, the code should be pretty self-explanatory so I won't explain it line by line. The most important concept here is that we have two closures here, one inside the other. The outer function can be thought of as the deck of cards, the function inside that can be thought of as the dealer, and the one inside that can be thought of as the players. Thinking logically about blackjack, a dealer can deal many players, and a single deck of cards can be used in many dealings. Thinking like this should clarify where each variable that acts as memory should reside.

Implementing the bonus part just required realising that we needed two different counters, one for the dealer and one for the players, and then to modify the logic very slightly to count correctly.

I know I've harped on this time and time, but I have implemented blackjack exercises quite a few times in different languages, generally using OOP paradigms. It has always required a lot more code than this. Using closure and realising the power that having memory gives functions is quite amazing.

We're done with closure exercises. Next up: Asynchronous JavaScript!

Code is for Humans

Ryan Ameri — Sat, 15 Aug 2020 02:45:48 +0000

These are some of the gems that can be found watching Kylie Simpson's Code is for Humans presentation at Frontend Masters. The talk is available for free and in my opinion, a must watch for new web developers. Here is my brief overview.

If you don't know why your code works, you have no hope of fixing it when it breaks. --getify's law #42

The inability to understand how code works so that it's quicker to rewrite is a universal problem. The difficulty of understanding code stems from our inability/unwillingness to insist that our code communicate our ideas clearly.

There are infinite number of ways to write the same program. But in the 60+ year history of computer science, we've prioritised writing code primarily for computers instead of optimising for the people who are going to read them.

Code is for communicating ideas with other people.

Instead of prioritising writing the fastest code, we should prioritise other metrics. For example, how many of our lines of code are going to survive the next cycle of when someone in future will refactor our code (that someone could be our own future self)? The only way to ensure our code is going to survive is to make it readable. If our code has to be rewritten to be fixed, we have failed.

Refactoring to make the code more readable is, not just a great idea, but essential. Take 10% of your time, 6 minutes out of every hour, to make your code more readable. Every moment we invest in making code readable will directly pay off, and impacts our ability to do our job. Readability is not just something good to have, it's the whole point.

The one thing that we will always be better than computers is how to communicate with other people. We should focus on that.

Code that you do not understand is code that you cannot trust, and code that you cannot trust is code that you do not understand

Mastering Hard Parts of JavaScript: Closure III

Ryan Ameri — Fri, 14 Aug 2020 20:13:19 +0000

Exercise 11

Create a function dateStamp that accepts a function and returns a function. The returned function will accept however many arguments the passed-in function accepts, and return an object with a date key that contains a timestamp with the time of invocation, and an output key that contains the result from invoking the passed-in function. HINT: You may need to research how to access information on Date objects.

function dateStamp() {}
const stampedMultBy2 = dateStamp((n) => n * 2);
console.log(stampedMultBy2(4));
// => should log { date: (today's date), output: 8 }
console.log(stampedMultBy2(6));
// => should log { date: (today's date), output: 12 }

Solution 11

function dateStamp(func) {
  const logTime = {};
  function stamping(input) {
    logTime.date = new Date();
    logTime.output = func(input);
    return logTime;
  }
  return stamping;
}

Another way of giving our function memory, except here instead of counting how many times our function has been called, we are keeping track of when it was called. Since our function needs to have a memory, it needs to have a persistent object in its outside scope, i.e., closure. This object then gets a date attribute that is set to the when the function is invoked, and an output attribute that is set to the return value of the original parameter with the second function's parameter as its argument.

We should be feeling pretty confident about giving our functions memory now, and that basically is the gist of closure.

Exercise 12

Create a function censor that accepts no arguments. censor will return a function that will accept either two strings, or one string. When two strings are given, the returned function will hold onto the two strings as a pair, for future use. When one string is given, the returned function will return the same string, except all instances of first strings (of saved pairs) will be replaced with their corresponding second strings (of those saved pairs).

function censor() {}
const changeScene = censor();
changeScene("dogs", "cats");
changeScene("quick", "slow");
console.log(changeScene("The quick, brown fox jumps over the lazy dogs."));
// => should log 'The slow, brown fox jumps over the lazy cats.'

Solution 12

function censor() {
  const phrases = new Map();
  function actualFn(...args) {
    if (args.length === 2) {
      phrases.set(args[0], args[1]);
    } else {
      let input = args[0];
      for (let [key, value] of phrases) {
        let regex = new RegExp(key, "g");
        input = input.replace(regex, value);
      }
      return input;
    }
  }
  return actualFn;
}

Now our function is getting a little bit more interesting, but when you break this exercise down, it is still very much doing the same things we've been practicing in the previous exercises, i.e., we need to have memory of some sort, and our function needs to have different behaviour based on the number of arguments passed.

For this exercise, I decided to use a Map() for the memory part but an object could also be used. I use rest parameters to capture all the arguments passed to the inside function and then check the array's size to see how many arguments there were. If two arguments were passed, we store them in our phrases map and we're done. If only one argument was passed, we use string.prototype.replace() and replace everything in our string that matches the previously stored values in our phrases map.

I wanted to use the new String.prototype.replaceAll() but at the time of this writing that's not still widely supported (for example it's not supported in the version of node.js 14 that I'm using to run my exercises). Once support for replaceAll() becomes more widespread, we can use that and we wouldn't need to construct a regex.

Exercise 13

There's no such thing as private properties on a JavaScript object! But, maybe there are? Implement a function createSecretHolder(secret) which accepts any value as secret and returns an object with ONLY two methods. getSecret() which returns the secret setSecret() which sets the secret

function createSecretHolder() {}
const obj = createSecretHolder(5);
console.log(obj.getSecret());
// => returns 5
obj.setSecret(2);
console.log(obj.getSecret());
// => returns 2

Solution 13

function createSecretHolder(secret) {
  let num = secret;
  const obj = {
    getSecret() {
      return num;
    },
    setSecret(n) {
      num = n;
    },
  };
  return obj;
}

Ha! An interesting method of implementing getter and setters! We'll cover these in more detail in Chapter 4, Classes and the Prototype, but here we are seeing how they such getters and setters can be implemented behind the scenes because classes in JS are (mostly) syntatic sugar.

I also believe that you now can (kind of) set private properties on an object in JS in the form of private class fields which was added in ES2019 (if these two paragraphs don't make any sense to you, don't worry, you should still be able to solve the exercise!)

So how did I solve this? Instead of returning a function, here I returned an object. However our object has two methods one is the getter which doesn't receive any parameters and instead returns the value of the num variable stored in its outside scope. The other is a setter which which just changes that value. Because the object is persistent and retains its values, this acts similar to how a normal getter and setter act in OOP languages such as Java.

Exercise 14

Write a function, callTimes, that returns a new function. The new function should return the number of times it’s been called.

function callTimes() {}
let myNewFunc1 = callTimes();
let myNewFunc2 = callTimes();
console.log(myNewFunc1()); // => 1
console.log(myNewFunc1()); // => 2
console.log(myNewFunc2()); // => 1
console.log(myNewFunc2()); // => 2

Solution 14

function callTimes() {
  let counter = 0;
  function insideFn() {
    counter++;
    return counter;
  }
  return insideFn;
}

Compared to some of our recent exercises, this is rather simple again, but it's good practice to remember how to count the number of times a function has been called. Good demonstration that we have access to the COVE (the outside variables) and can both retrieve them or change them.

Exercise 15

Create a function russianRoulette that accepts a number (let us call it n), and returns a function. The returned function will take no arguments, and will return the string 'click' the first n - 1 number of times it is invoked. On the very next invocation (the nth invocation), the returned function will return the string 'bang'. On every invocation after that, the returned function returns the string 'reload to play again'.

function russianRoulette() {}
const play = russianRoulette(3);
console.log(play());
// => should log 'click'
console.log(play());
// => should log 'click'
console.log(play());
// => should log 'bang'
console.log(play());
// => should log 'reload to play again'
console.log(play());
// => should log 'reload to play again'

Solution 15

function russianRoulette(num) {
  let count = 0;
  function closureFn() {
    count++;
    if (count < num) return "click";
    else if (count === num) return "bang";
    else return "reload to play again";
  }
  return closureFn;
}

Russian Roulette sounds scary, but this really is a variation of the same problem we've been solving in these past few exercises: count the number of times a function has been called, and perform different task based on that. Here what we do also depends on the parameter that was originally passed to the function (the num).

The flexibility and power of closure should be quite apparent here. To implement this functionality using a traditional OOP language such as Java would require quite a bit more lines of code.

DEV Community: Ryan Ameri

Think Like JavaScript

JavaScript is peculiar

But JavaScript is universal

Whenever there's a divergence between what your brain thinks is happening, and what the computer does, that's where bugs enter code

Who is this series for

A note on JavaScript's backwards compatibility

Structure of the series and credits

Mastering Hard Parts of JavaScript: Prototype & Class V

Subclassing & Mixins

Exercise 10

Solution 10

Exercise 11

Solution 11

Exercise 12

Solution 12

Exercise 13

Solution 13

Exercise 14

Solution 14

Exercise 15

Solution 15

Mastering Hard Parts of JavaScript: Prototype & Class IV

Using ES6 Classes

Exercise 8

Solution 8

Exercise 9

Solution 9

Mastering Hard Parts of JavaScript: Prototype & Class III

Using the new keyword

Exercise 5

Solution 5

Exercise 6

Solution 6

Exercise 7

Solution 7

Mastering Hard Parts of JavaScript: Prototype & Class II

Using Object.create()

Exercise 2

Solution 2

Exercise 3

Solution 3

Exercise 4

Solution 4

Mastering Hard Parts of JavaScript: Prototype & Class I

How come JavaScript is not Object Oriented but everything in JavaScript is an Object?

Using Object Literals

Exercise 1

Solution 1

Mastering Hard Parts of JavaScript: Asynchronicity III

Exercise 6

Solution 6

Exercise 7

Solution 7

Exercise 8

Solution 8

Exercise 9

Solution 9

Exercise 10

Solution 10

Mastering Hard Parts of JavaScript: Asynchronicity II

Exercise 1

Solution 1

Exercise 2

Solution 2

Exercise 3

Solution 3

Exercise 4

Solution 4

Exercise 5

Solution 5

Mastering Hard Parts of JavaScript: Asynchronicity I

The Event Loop

Promises

Mastering Hard Parts of JavaScript: Closure IV

Exercise 16

Solution 16

Exercise 17

Solution 17

Exercise 18

Using the `new` keyword