kad3nce

You Don't Know JS: Scope & Closures

Chapter 1: What is Scope?

One of the most fundamental paradigms of nearly all programming languages is the ability to store values in variables, and later retrieve or modify those values. In fact, the ability to store values and pull values out of variables is what gives a program state.

Without such a concept, a program could perform some tasks, but they would be extremely limited and not terribly interesting.

But the inclusion of variables into our program begets the most interesting questions we will now address: where do those variables live? In other words, where are they stored? And, most importantly, how does our program find them when it needs them?

These questions speak to the need for a well-defined set of rules for storing variables in some location, and for finding those variables at a later time. We'll call that set of rules: Scope.

kad3nce

kad3nce

You Don't Know JS: Scope & Closures

Chapter 1: What is Scope?

One of the most fundamental paradigms of nearly all programming languages is the ability to store values in variables, and later retrieve or modify those values. In fact, the ability to store values and pull values out of variables is what gives a program state.

Without such a concept, a program could perform some tasks, but they would be extremely limited and not terribly interesting.

But the inclusion of variables into our program begets the most interesting questions we will now address: where do those variables live? In other words, where are they stored? And, most importantly, how does our program find them when it needs them?

These questions speak to the need for a well-defined set of rules for storing variables in some location, and for finding those variables at a later time. We'll call that set of rules: Scope.

kad3nce

You Don't Know JS: this & Object Prototypes

Chapter 5: Prototypes

In the Chapters 3 and 4, we mentioned the [[Prototype]] chain several times, but haven't said what exactly it is. We will now examine prototypes in detail.

**Note: All of the attempts to emulate class-copy behavior, as described previously in Chapter 4, labeled as variations of "mixins", completely circument the [[Prototype]] chain mechanism we examine here in this chapter.

Links

Objects in JavaScript have an internal property, denoted in the specification as [[Prototype]], which is simply a reference to another object. Almost all objects are given a non-null value for this property, at the time of their creation.

kad3nce

kad3nce

You Don't Know JS: this & Object Prototypes

Chapter 2: this All Makes Sense Now!

In Chapter 1, we discarded various misconceptions about this and learned instead that this is a binding made for each function invocation, based entirely on its call-site (how the function is called).

Call-site

To understand this binding, we have to understand the call-site: the location in code where a function is called (not where it's declared). We must inspect the call-site to answer the question: what's this this a reference to?

Finding the call-site is generally: "go locate where a function is called from", but it's not always that easy, as certain coding patterns can obscure the true call-site.

kad3nce

You Don't Know JS: this & Object Prototypes

Chapter 6: Behavior Delegation

In Chapters 4 and 5, we addressed the [[Prototype]] mechanism in detail, and why it's confusing and inappropriate (despite countless attempts for nearly two decades) to label it "class" or "inheritance". We trudged through not only the fairly verbose syntax (.prototype littering the code), but the various gotchas (like surprising .constructor resolution or ugly pseudo-polymorphic syntax). We explored variations of the "mixin" approach, which many people use to attempt to smoothe over such rough areas.

It's a common reaction at this point to wonder why it has to be so complex to do something seemingly so simple. Now that we've pulled back the curtain and seen just how dirty it all gets, it's not a surprise that most JS developers never dive this deep, and instead relegate such mess to a "class" library to handle it for them.

I hope if you're reading these "You Don't Know JS" books, you're not content to just gloss ov

kad3nce

You Don't Know JS: this & Object Prototypes

Chapter 5: Prototypes

In the Chapters 3 and 4, we mentioned the [[Prototype]] chain several times, but haven't said what exactly it is. We will now examine prototypes in detail.

**Note: All of the attempts to emulate class-copy behavior, as described previously in Chapter 4, labeled as variations of "mixins", completely circument the [[Prototype]] chain mechanism we examine here in this chapter.

Links

Objects in JavaScript have an internal property, denoted in the specification as [[Prototype]], which is simply a reference to another object. Almost all objects are given a non-null value for this property, at the time of their creation.

kad3nce

You Don't Know JS: this & Object Prototypes

Chapter 5: Prototypes

In the Chapters 3 and 4, we mentioned the [[Prototype]] chain several times, but haven't said what exactly it is. We will now examine prototypes in detail.

**Note: All of the attempts to emulate class-copy behavior, as described previously in Chapter 4, labeled as variations of "mixins", completely circument the [[Prototype]] chain mechanism we examine here in this chapter.

Links

Objects in JavaScript have an internal property, denoted in the specification as [[Prototype]], which is simply a reference to another object. Almost all objects are given a non-null value for this property, at the time of their creation.

kad3nce

You Don't Know JS: this & Object Prototypes

Chapter 6: Behavior Delegation

In Chapters 4 and 5, we addressed the [[Prototype]] mechanism in detail, and why it's confusing and inappropriate (despite countless attempts for nearly two decades) to label it "class" or "inheritance". We trudged through not only the fairly verbose syntax (.prototype littering the code), but the various gotchas (like surprising .constructor resolution or ugly pseudo-polymorphic syntax). We explored variations of the "mixin" approach, which many people use to attempt to smoothe over such rough areas.

It's a common reaction at this point to wonder why it has to be so complex to do something seemingly so simple. Now that we've pulled back the curtain and seen just how dirty it all gets, it's not a surprise that most JS developers never dive this deep, and instead relegate such mess to a "class" library to handle it for them.

I hope if you're reading these "You Don't Know JS" books, you're not content to just gloss ov