Exploring the - inconstant - this in JS
Background
- Oh, boy! let me see...
- Every function in "js" assumes it has access to an instance of an object, be it global, or a particular object.
- So functions often refers to variables using "this.x"
- But there are many kinds of function in JS
- functions - defined at a global context
- methods - functions that belong to a class or an object, or inside other functions
- anonymous functions - functions that end up as only variables without names
- callback functions - when used to call back from other functions
- arrow functions - functions defined inline and simplified in many ways along with their caveats
- extracted functions - functions that are passed around by their reference without their parent object, where they start behaving like regular functions and not methods
- There are a few factors the literature says, that can effect what the "this" variable points to inside the body of a function. These are:
- Where is the function called
- Where is the function defined
- How is the function called
- So.....
- Hope to clarify some of these nuances here.
- Who is calling the function
The meaning of "how is the function" called....
- In literature this phrase is often used "how is the function called" distinct from who is calling it, or where is it being called...
- If one is to ignore the special cases of the explicit new, bind, call, etc, there are only 2 ways a function is "classified" to be called.
- They are...
- Direct call: Call it as just a function, with no reference to the object that is a member of, if it is
- Method call: Always called with a prefix of the object.method()
- So....
- when one says how it is called, they are referring to one of these 2
Examples
//Direct call
f()
//As a method call
o.f()
So all call backs usually falls under the Direct calls
some-function(callback-function) {
callback-function()
}
Notes
- Notice it doesn't matter if the call-back function is a standalone function, or an extracted method name from an object
- It also doesn't matter if the calling function is direct, or inside an object, or in a deep hierarchy
- It only matters the invocation "reference", the direct method or it is on top of another object.some-method
Here is an illustration of this
// A simple function defined in the global scope
function greet() {
console.log("Hello, world!");
}
// An object with a method
const person = {
name: "John",
greet() {
console.log(`Hello, my name is ${this.name}`);
}
};
// Another object with methods for testing callback behavior
const anotherObject = {
callGreetDirectly() {
greet(); // Direct call within a method
},
callGreetAsCallback(callback) {
callback(); // Passing and calling the function as a callback
}
};
// Direct Call
greet(); // Direct Call: Output: Hello, world!
// Method Call
person.greet(); // Method Call: Output: Hello, my name is John
// Calling 'greet' from another object's method
// Direct Call: Output: Hello, world!
anotherObject.callGreetDirectly();
// Calling 'greet' as a callback from another object's method
// Direct Call: Output: Hello, world!
anotherObject.callGreetAsCallback(greet);
// Calling 'person.greet' as a callback (context is lost)
// Direct Call:
anotherObject.callGreetAsCallback(person.greet);
//Output: Undefined behavior or
//"Hello, my name is undefined" because 'this' is lost
The behavior of anonymous functions is similar to regular functions when "this" is concerned
- They have similar regarding the variability or invariability of the "this" variable
- Of course, the arrow functions behave differently.. for they are also kind of anonymous, you can say, but have distinct semantics for "this"
Because callbacks loose the "this" parameter
- When a called calls a callback, which is essentially a "function", there is no object reference at that point,
- So the method of invocation becomes "direct" loosing the "this"
- So design the callbacks so that they rely as much as possible on what is passed in
- Of course "closures" can help some...thats a different topic
- Also know that arrow functions behave a bit differently, yet, you want to minimize the dependency and expect them to behave like stateless functions.
Now to arrow functions....a key design element, necessary and good, read on
Now to arrow functions....a key design element, necessary and good, read on
Few assertions first on the arrow functions
- The "this" of an arrow function is fixed. It cannot be changed unlike most other types of functions, methods, etc.
- In other words, when an arrow function is invoked, it carries with it, where ever it goes, the original this where it is defined.
- To put this in common words, if an arrow function is defined inside an object's method as a callback, that callback method carries with it the "this" pointer of its parent object!
Lets start with a harmless example of a method as the target of a call back
const obj = {
name: "Sathya",
greet() {
console.log(`Hello, ${this.name}!`); // `this` refers to `obj` if called directly
},
delayedGreet() {
setTimeout(this.greet, 1000); // Passing the method as a callback
},
};
obj.delayedGreet(); // What happens to `this` in `greet`?
Commentary
- Idea is we send an object method into a callback
- Being an object method, it expects to use the instance properties of that object
- But if you notice....
- Being a callback, the method, being now an extracted method as far as the caller is concerned, looses the "this"
- So that method when called back can not use any instance variables!! ouch!
- There are some strange syntactic work arounds to this but we won't go into that here...
You can fix this by explicitly telling JS to remember it by using bind
const obj = {
name: "Sathya",
greet() {
console.log(`Hello, ${this.name}!`);
},
delayedGreet() {
setTimeout(this.greet.bind(this), 1000);
// Explicitly bind `this` to `obj`
},
};
obj.delayedGreet(); // Output (after 1 second): "Hello, Sathya!"
Here is how to fix this using an arrow function
const obj = {
name: "Sathya",
greet() {
console.log(`Hello, ${this.name}!`);
},
delayedGreet() {
setTimeout(() => this.greet(), 1000);
// Arrow function inherits `this` from `delayedGreet`
},
};
obj.delayedGreet(); // Output (after 1 second): "Hello, Sathya!"
So, an arrow function call back is like a call back on the object itself
- When a regular function is called back, it looses its parent object (unless a closure is used, which is a different topic)
- where as when an arrow function from an object is used as a callback, it is as if the object itself is tagged along, and participates in the callback
By extension you can think of the arrow function like a closure on the object where it is defined
- In JS a function is a bit strange
- Unlike in other languages when a function is passed around, it carries with it the local sister variables to that function, in other words, its neighborhood
- this is what is called a closure
- However a function DOES NOT CARRY the Object instance along with it by default
- Where as when that function is an arrow function, it DOES, allowing a much more natural experience
Few more notes on arrow functions
- They borrow their this from their parent contexts
- Their this cannot be altered
- When their parent is an object, they carry their object around
- They also carry their parent functions argument list (not to be confused with the explicit arguments that are passed into them in their definition)
- You cannot change their this via call or bind
- You can use these properties to pass the whole object to respond to a call back
They are
- Arrow functions
- Methods with explicit binding with .bind[often used]
- Use static methods
- Use closures
- inline anonymous functions when reference to this is not needed and can use just the input params
When
- In cases like event listeners where the caller like the button wants to pass their own this to the function,... you cannot do that if that is an arrow function
- When you need to use the "arguments" object
- when you want to force a method to use a particular object as its this
See this curios example
function logName() {
console.log(this.name);
}
const person = { name: "Sathya" };
[1, 2, 3].forEach(logName.bind(person)); // Binds `this` to `person`
Can I call new on a stand alone function even if it doesn't use the "this" variable?
- Say I have a (sf) stand alone function outside of an object and in the main line
- Say further it may or may not refer to this in its body
- ...
- What happens if I call new on that function?
- Yes you can call new on that sf
- As the function does not use the "this" that gets passed in
- The resulting this at the end of the function call is an empty object {}
So what makes a function a "cf"
- Every "sf" can be called as if it is an "sf"
- Usually a "cf" wants to define some "structure" or body to the passed in "this"
- This structure include attributes and functions
- General indication is that if an "sf" is referencing a "this", it is likely meant to be used as a cf
Are sub functions always members of an object instance?
- Usually cfs or classes define sub functions, other functions that are properties of an object
- These are often called methods
- ....
- Can a mainline non-cf define sub functions?
- What does it mean to do so?
- Who is the parent to such sub functions if there is no object to hold them?
- Whose attributes are they?
- ....
- The answer is this
- Like a function that has local variables like integers and strings
- It can also have a baby function inside with inputs and outputs, including visibility and access to the parent functions local variables
- ....
- So the baby child function is just a variable in the local scope
- It can be called by other baby functions inside
- It cannot be accessed by anything outside the parent sf unlike when they are from a cf and part of an object
- ....
- Another nuance of JS is that these child functions follow closure rules
- So when you return one of these local functions out, they carry the context of the parent! This is also often called closure
- So you CAN access the internal function if and only if, it is returned by the parent function as a response
The three common lexical scopes in JS
- block - like the body of a loop, or an if, {}, let, const etc.
- function - inside the body of a function, variables, params, inner functions
- global - outside of a function, variables, objects, functions at a global level
Difference between lexical scope and lexical context
- One is static and one is run time
- The lexical scope is the most obvious referring to what is inside {}, give and take
- The lexical context is the "run time environment" for a piece of code to run and what variables are available at run time for that code to refer to
- Unspecified run time variables like this, arguments, thread level variables etc all form the context
Why am I going to great lengths to understand these 2 names: scope and context?
- Many rules around how "this" is determined at run time for a variety of functions are described using terms scope and context
- So to understand the documentation you have to know how these two differ
- So...know that there are 3 scopes: block, function, and global. Roughly that's it. Which are explained above and familiar to most programming languages.
- Whereas the lexical context, the run time arguments like this, or more accurately context, varies with in the same scope depending on if it is an arrow function or a non-arrow function
On top of that... the object literal throws a wrench into the context of an arrow function due to scope rules
- An object literal defined at a global level, although uses {} to scope its code, that scope inherits the scope from its parent and does not explicitly create a new run time context (this, arguments etc)
- This is much like the {} for the for loops, if, etc, where there is no new context created but uses the context from its parent scope
This is why an arrow function in an object literal behaves differently than one in a cf
- An arrow function inside a cf, uses the "scope" of the cf, and that scope creates a new context and new this, which is used by the arrow function, and never changes once it is created
- Where as an arrow function in an object literal, the scope is the object literal, but the object literal's scope doesn't create a new execution context (this) but borrows from the scope above it, the global, making the this null.
- In other words some scopes create a new run time context and some don't
The following scopes create a new runtime context
- function scopes - always (except the arrow)
- global scopes - some times (when they are not in strict mode
The following scope(s) DOES NOT create a new context but inherits the context of its parent
- Block quotes like,
- for
- if
- object literal
- etc.
That, in short solves the mystery of the arrow function behavior in an object literal vs cf
- The scope of cf creates a new context (this).
- That gives the af (arrow function) inside the cf its this
- ....
- The scope of an object literal (ol) is more like a block scope and merely uses its parents run time context
- So for an af in an object literal, the "this" is the global "this" which is there sometime and some time not
- .....
- However, if there is a regular function rf() inside the ol, and that rf() creates and passes an af inside itself, then the scope and context is that of the rf() which is the "this" of the rf() and all works ok.
Consider this
ol = {
rf() {
someobj.callback(() => this.x)
}
}
1. is the scope of the arrow function (af) here inside rf() same as rf?
2. And hence the context of the af is the context of rf?
Commentary
- The scope of af is rf as it is defined inside the rf
- Moreover, the rf scope being an executable scope it gets its own context, and that context (this) is what gets fixed to the af as it travels
- ....
- The rf itself is inside ol
- ol is like a variable in the global scope
- ....
- Apparently ol does not create a new lexical scope
- variables outside the ol are accessible inside the ol as they are in the same lexical scope
Consider this
ol = {
rf() {
//call this callback af1()
someobj.callback(() => this.x)
}
af2() = () => this.y
}
Specially the af2()
- It is an arrow function
- Rule says: it inherits the "this" from its parent lexical scope
- ...
- Unlike a function, an object literal ol, does not create its own lexical scope
- so, the lexical scope of af2 is the same as the global scope
- ...
- so af2 is tied to the "this" of the global scope
Scope, lexical scope, and context
- Oh, boy, back to these nuances!
- ...
- lexical scope
- They say, lexical scope is the static scope
- It does walk up the chain
- ...
- blocks create a new lexical scope with let and const but not var
- object literals DO NOT create a new lexical scope (important)
- ...
- scope
- This is considered dynamic
- Also walks up the chain
- Depending on the objects passed in this can change, distinguishing from the lexical scope
- ....
- context
- The run time objects that are available in that scope
A quick note on the closure
- It remembers all the following up the chain...
- ...
- Variables declared in the same block.
- Variables declared in the enclosing function scope.
- Variables declared in any higher scopes, including the global scope.
Back to this code
ol = {
rf() {
//call this callback af1()
someobj.callback(() => this.x)
}
af2() = () => this.y
}
The af2()
- The rule says, the "this" of the "parent lexical context
- ...
- The parent of af2 is "ol"
- ol does not create its own lexical context, so it is the same as the global
- ...
- so the lexical context of af2() is global
- So it is the global "this" and not the "ol" this
The oddness of Object literals and their lexical scope
- Of inside and outside of an ol, is the same lexical scope, question arises how come outside cannot see the internal variables of the ol
- ....
- The suggested answer is, they are NOT variables inside, the WHOLE OBJECT is the variable, and the inner variables are merely the properties of that object and hence getting around the visibility of them being separate variables.
- ...
- nuance, nuance...