It’s probably safe to say that the
this keyword around until my script worked and it confused the hell out of me (and still confuses many other JS developers). It wasn’t until I learned about lexical scope, how functions are invoked, scope context, and a few context changing methods that I really understood it.
Before you dive into this article, here’s a few very important points to takeaway and remember about the
thiskeyword’s value has nothing to do with the function itself, how the function is called determines the
- It can be dynamic, based on how the function is called
- You can change the
There are a few different ways the
this value changes, and as we know it’s usually the call-site that creates the context.
Window Object, global scope
Let’s take a quick example at how simply calling regular functions binds the
this value differently:
What can we expect the
this value to be? By default, this should always be the
window Object, which refers to the root - the global scope. So when we
console.log(this); from our function, as it’s invoked by the window (simply just called), we should expect the
this value to be our
Inside Object literals, the
this value will always refer to its own Object. Nice and simple to remember. That is good news when invoking our functions, and one of the reasons I adopt patterns such as the module pattern for organising my objects.
Here’s how that might look:
window Object didn’t invoke the function - our Object did, so
this will refer to the Object that called it:
Prototypes and Constructors
The same applies with Constructors:
And we can add a Prototype Object as well:
Interestingly, in both cases the
this value will refer to the Constructor object, which will be
When we bind events, the same rule applies, the
this value points to the owner. The owner in the following example would be the element.
this would refer to
The second point I made in the intro paragraph was that
this is dynamic, which means the value could change. Here’s a real simple example to show that:
There are often many reasons why we need to change the context of a function, and thankfully we have a few methods at our disposal, these being
Using any of the above will allow you to change the context of a function, which in effect will change the
this value. You’ll use this when you want
this to refer to something different than the scope it’s in.
You will often hear that “Functions are first class Objects,” which means that they can also have their own methods!
.call() method allows you to change the scope with a specific syntax ref:
Usage would look something like this:
You’ll notice further arguments are all comma separated - this is the only difference between
With any of the above, they immediately invoke the function. Here’s an example:
Without any arguments, the function is just invoked and
this will remain as the
Here’s a more practical usage, this script will always refer to the
forEach method also has the same effect, it’s a function so it creates new scope:
We could change each iteration’s scope to the current element’s value inside a regular
for loop as well, and use
this to access object properties:
This is especially extensible when passing around other Objects that you might want to run through the exact same functions.
Not many developers using
forEach know that you can change the initial scope context via the second argument:
Of course the above example doesn’t change the scope to how we want it, as it changes the functions scope for every iteration, not each individual one - though it has use cases for sure!
To get the ideal setup, we need:
.call(), but instead binds the function’s context prior to being invoked, this is essential to understand the difference. Using
.bind() will not invoke the function, it just “sets it up”.
Here’s a really quick example of how you’d setup the context for a function, I’ve used
.bind() to change the context of the function, which by default the
this value would be the window Object.
This is a really simple use case, they can also be used in event handlers as well to pass in some extra information without a needless anonymous function:
I call this jumping scope, but essentially it’s just some slang for accessing a lexical scope reference (also a bit easier to remember).
There are many times when we need to access lexical scope. Lexical scope is where variables and functions are still accessible to us in parent scopes.
In the above scenario,
this binds perfectly, but what happens when we introduce another function. How many times have you encountered a scope challenge when using a function such as
setTimeout inside another function? It totally screws up any
So what happened there? As we know, functions create scope, and
setTimeout will be invoked by itself, defaulting to the
window Object, and thus making the
this value a bit strange inside that function.
this and the
arguments Object are the only objects that don’t follow the rules of lexical scope.
How can we fix it? There are a few options! If we’re using
.bind(), it’s an easy fix, note the usage on the end of the function:
We can also use the jumping scope trick,
var that = this;:
We’ve cut the
this short and just simply pushed a reference of the scope into the new scope. It’s kind of cheating, but works wonders for “jumping scope”. With newcomers such as
.bind(), this technique is sometimes frowned upon if used and abused.
One thing I dislike about
.bind() is that you could end up with something like this:
A tonne of
.bind() calls, which look totally stupid. Of course this is an exaggerated issue, but it can happen very easily when switching scopes. In my opinion this would be easier - it will also be tonnes quicker as we’re saving lots of function calls:
Do what makes sense!
Yes, the same applies, don’t use
$(this) unless you actually know what it’s doing. What it is doing is passing the normal
this value into a new jQuery Object, which will then inherit all of jQuery’s prototypal methods (such as addClass), so you can instantly do this:
Happy scoping ;)