I’ve been meaning to write about days 3-5 of JavaScript week, but I just finished my first build week and I’m too tired to really go into detail, but I need to push it out of the way before I write about Week 4. So, here’s a summary of Week 3, Day 3:

“this” keyword

Day 3 of JavaScript Week brought back an old friend from the pre-course: the [this] keyword. When we learned about it in the pre-course, we learned that when used in an object this refers to the object that its nested inside of. Day 3 dug a little deeper.

As per the Lambda text:

You can think of this, as a Pointer to an object. For example: you can use the this keyword to reference an object without having to refer to that object’s name.

Understanding what this points to requires context. An example we were given is to imagine that we’re at a friend’s house for dinner. At some point, she says, “I don’t like this.” In order to understand what this means, we look at our friend and see that she’s pointing at our cat, scratching at her leg. Without seeing her point, we’d have no context to define what this refers to.

As per the Lambda text:

The first place to start with the this keyword is to understand not how a function is being called, but ‘where’. If you can discover the context in which the function being called is executed, you’ll have a clue as to what the ‘this’ keyword is pointing to.

The Four Rules of Binding

1. Window/Global Object Binding: In the global scope, the value of  this is the window/console object/
2. Implicit Binding: When a function is called by a preceding dot, this is the object before the dot. This is the most common application of this (see what I did there?).
3. New Binding: When a constructor function is used, this refers to the instance of the object that the constructor function created and returned. (Constructor functions were covered the next day in class.)
4. Explicit Binding: When JavaScript’s .call or .apply method is used, this is explicitly defined.

I’ll write a post later and go more into this/this, with code examples of the bindings, but I just don’t have the reserves right now (its 4:51 AM!).

• When not to use arrow functions (this doesn’t bind to arrow functions!)

 

Prototypes

Like this, object prototypes are a concept that was covered the pre-course. I was comfortable with my understanding of it then, and I actually still am now. I think of a prototype as a mold. In manufacturing, many items (or parts of items) are crafted from molds. They can be looked at as a blueprint or template for objects that will be created in their image.

In JavaScript, when an object is created, it automatically gets a prototype. This prototype is applied to all subsequent instances of that object that are created. For example, if we have an “Animal” object and we create an Animal called “dog”, then dog will inherit whatever characteristics Animal has. If we create another Animal called “cat” then it, too, will inherit whatever characteristics Animal has. It gets these from the prototype – the blueprint of the object.

The main function of the prototype is that new methods can be attached to it which are then inherited by all objects in its type. So, to continue with our Animal example, if we add a method (a function that’s attached to an object, array or string) to the Animal prototype called “wagsTail” then our dog and cat objects will gain access to the wagsTail method. (Now that I’m thinking about it, we’ll need to include a property in the Animal object that indicates if the Animal actually has a tail to wag, or we’ll get some disturbing behaviors from gorillas or octopuses or maybe animals that are practically all-tail, like snakes.)

Animal is a constructor function. It creates (constructs) objects that inherit its characteristics and methods. Its a convention to name constructors (shorthand for constructor functions) with a capitalized first letter. This lets other developers know that the function is a constructor.

But, anyway, the point of all of this is that when a constructor creates a new object (using the new keyword) it basically creates a context for this. It returns a this object with properties inherited from the constructor added on.

Why use prototypes for methods?

So, what’s the difference between defining a method in an object directly vs. attaching it to the prototype? My understanding is that its a memory/resource management concern. If we define a method in an object, it’s natively a part of all children of that object. However, its then duplicated across all child objects, so memory is reserved for it. For small programs, that might not be a concern, but for programs with large amounts of object data – lets say a scenario in which 50k children of a constructor function are created – that means that the method was just duplicated 50k times.

Attaching a method to a prototype allows all child objects to access the method, but doesn’t copy it directly into every instance of that object. In essence, dog or cat can reference wagsTail and use it, but its not inherently a part of their makeup.

Ok. I’m beat. I’ll write about inheritance, dunder prototypes and show some prototype code examples later. For now, good morning to all of you, and good nigh for me for the next hour or two.