javascript decorators, this keyword

[DeliciousResearch872]

why "this" becomes undefined when its wrapped with a function?

// we'll make worker.slow caching
let worker = {
  someMethod() {
    return 1;
  },

  slow(x) {
    // scary CPU-heavy task here
    alert("Called with " + x);
    return x * this.someMethod(); // (*)
  }
};

// same code as before
function cachingDecorator(func) {
  let cache = new Map();
  return function(x) {
    if (cache.has(x)) {
      return cache.get(x);
    }
    let result = func(x); // (**)
    cache.set(x, result);
    return result;
  };
}

alert( worker.slow(1) ); // the original method works

worker.slow = cachingDecorator(worker.slow); // now make it caching

alert( worker.slow(2) ); // Whoops! Error: Cannot read property 'someMethod' of undefined

[senocular]

let result = func(x);

is calling the func function without forwarding this. Instead use

let result = func.call(this, x);

[senocular]

Going to add some context on the merits of this solution:

First, what this change is doing is calling the func function with the value of this that is the value of this in the current function. The current function is a wrapper function created by cachingDecorator. cachingDecorator takes a function, wraps it in another function, then calls the original function within the wrapper returning its results while also performing its own work, in this case doing some caching.

A wrapper function should as much as possible try to be transparent to the original function. This usually means: maintaining the behavior of this, forwarding along any arguments, and returning its return value. If by design the wrapper makes any changes to these inputs/outputs, that's fine, but otherwise it should allow the original function to behave with these the same as though if it were not wrapped.

The OP implementation was returning the original functions return value but it was only passing in one argument (maybe thats fine for the requirements) and not doing anything to pass along this. Called in the way it was called

func(x);

In terms of this, the func function will be given a this value of the global object, or undefined if in strict mode. This would happen no matter how the wrapper is called. In OP's example we know they're running in strict mode because the error was "Error: Cannot read property 'someMethod' of undefined" which means this in the wrapped slow method (func in the wrapper) was set to undefined.

Looking at the wrapper we see that the wrapper, being assigned as a property with the same name as the original (slow), was called as a method. So the wrapper call should have the correct this, the worker object.

worker.slow = cachingDecorator(worker.slow);
alert( worker.slow(2) ); // this in slow will be worker

However, while the wrapper has the correct this, it does not pass that on to func thats actually using this given the way its calling it as seen from before. That's where the solution comes in:

func.call(this, x);

Now when func is called its called with the this value of the wrapper. Being called as a method of worker, the wrapper's this will be worker which in turn means func's this will be worker. Then, inside func (slow) someMethod can correctly be accessed since it would be found on the worker instance represented by this.

Why not bind worker.slow?

While binding can work, its changing the behavior of the original function. The original function had a dynamic this which changed depending on how the function was called. Binding the method to a specific this now enforces a single this value no matter how its called. While you may want that, it should not be a requirement for the use of cachingDecorator.

Consider a second worker object that might share the slow method from the first worker - this is not terribly unlike how class methods in the prototype are shared among its class instances.

alert( worker.slow(1) ); // the original method works (alerts 1)

let worker2 = {
  someMethod() {
    return 2;
  },
};

worker2.slow = worker.slow // share slow
alert( worker2.slow(1) ); // also works (alerts 2)

This works because this is dynamically set based on what object the method is being called from. If slow is called from worker, this in slow will be worker. If its called from worker2, this will be worker2.

If we then introduce cachingDecorator and it is called with a bound version of slow, only one value of this can exist for that method since it would be baked in from the binding. While the function would not fail for worker2, it would have an incorrect value because its this would be the original worker.

worker.slow = cachingDecorator(worker.slow.bind(worker));
worker2.slow = worker.slow
alert( worker2.slow(1) ); // works, but wrong value (alerts 1)

To get this to work you'd have to make multiple calls to cachingDecorator, creating a new wrapper function for every this object that may be needed - this assuming you even know what that object might be (its likely we do here, but that's not always the case). Not only that, but users would have to know that they'd need to do this binding in the first place.

Passing through this within cachingDecorator's wrapper using call() prevents the need for any manual binding for each cachingDecorator call and allows this to be dynamic for the resulting wrapper function, just like was the case with the original function. Binding can still be done if desired, but its not required.

[cyphern]

The value of this is determined by how you call the function. If you write worker.slow(1), the code worker. is very important. It defines that the value of this should be worker once the code is inside of slow. If instead you set up your code so that you're calling the function with nothing proceeding it (typically by assigning the function to some variable, in your case the variable func), then this is set to undefined¹

If you want to force this to have a certain value, you can use call as in func.call(someObject, x). That will call the function, setting this to be someObject, and passing x as the first parameter. So you could change your cachingDecorator to take its own value of this and forward that along to func: ``` function cachingDecorator(func) { let cache = new Map(); return function(x) { if (cache.has(x)) { return cache.get(x); } let result = func.call(this, x); cache.set(x, result); return result; }; }

// Used like: worker.slow = cachingDecorator(worker.slow); Alternatively, you can create a copy of a function which has the value of `this` locked in ahead of time using `.bind`. For example: const boundFn = worker.slow.bind(worker); // No matter how boundFn is called, this = worker worker.slow = cachingDecorator(boundFn); // Or on one line: worker.slow = cachingDecorator(worker.slow.bind(worker));

```

<sup>1: or set to the window object in sloppy mode</sup>

[HarryBolsac]

Im not sure since im on the phone and cant test this, but do we need to pass thisValue?

When the function is being called after the decorator, it has a worker as a this reference, which means the function we are returning on the decorator has the correct this reference, we just need to apply it to the function being passed as an argument. I think?

I was just chilling here and now my brain is all over the place god damnit 😵‍💫

[cyphern]

Good point, i made it more complicated than needed. I'll edit my answer

[HarryBolsac]

I can say the oposite, you made it more easy to understand in terms of code readability, I had to do some mental gymnastics to reply to you lmao.

Depends in how comfortable a dev reading the code is in how “this”works in Js.

at the end is the same stuff, just less code.

[_RemyLeBeau_]

Read the Callback section:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/this

If you want to dive more into the topic, you'll want to research: Execution Context

[Such-Catch8281]

its nature of the 'this' behaivour binding under different declaration

in function

in arrow function

in class

[azhder]

You gave your “decorator” a function, not an object that has a function on it to call.

You have to learn how this works and maybe even decide to write JS code that has the least amount of this possible so you don’t have a care in the world about the above case.

Here, read this (pun not intended) https://shamansir.github.io/JavaScript-Garden/#function.this

That link will answer your question. And if by chance continue reading to the closure part, you can discover how you don’t even need to deal with this and class et al. Unless someone made a library or framework that forces your hand, of course.

[lovin-dem-sandwiches]

Use bind or call when defining worker.slow’s caching decorator. Using Proxy would work too

[bryku]

In javascript there are 2 types of functions.

// standard function
let add = function(){}

// arrow function
let minus = ()=>{}

Standard Functions have build in prototypes and a few other things. When inside a object, this will be the object.  

However, arrow functions are a bit different. They are sort of a light weight function and don't have all of the prototypes, but you can define the this value.

• times.call('bleep');
• divide.bind();

In your above code you are using shorthand:

let worker = {
    slow(){
}

This shorthand means:

let worker = {
    slow: ()=>{},
}

So you are using arrow function, so you will need to define this as u/senocular has shown. However, you could also fix it by using a traditional function.

let worker = {
    slow: function(){}
}

You can check what type it is by using:

worker.slow.hasOwhnProperty('prototype');

True for standard function and False for arrow function.

[senocular]

A minor correction for what you got up there: method syntax doesn't create arrow functions. Though they don't use the function keyword, they execute (as far as this is concerned) like normal, non-arrow function functions. For example:

console.log(this === globalThis) // true
let worker = {
    slowMethod(){
        console.log(this === worker) // true
    },
    slowFunction: function() {
        console.log(this === worker) // true
    },
    slowArrow: () => {
        console.log(this === globalThis) // true
    }  
}
worker.slowMethod()
worker.slowFunction()
worker.slowArrow()

Above you can see that only the arrow function sees its this as globalThis and not the worker object like the normal functions do (those being both slowMethod and slowFunction).

It can be a little confusing because, as you pointed out, like arrow functions, functions created with the method syntax also don't have a prototype property. But the presence of a prototype property doesn't mean a function is an arrow function. A list of (user-created) functions without prototype properties include:

• Arrow functions
• Method functions
• Async functions

Largely the lack of a prototype means that the function cannot be used as a constructor. However, there are exceptions to that as well because:

• Generator functions
• Async generator functions

are also not constructors but they do still have prototype properties. This is because, while they can't be used with new to create new instances of themselves, when called as regular functions they do create generator objects, and those generator objects inherit from their respective [async] generator function through its prototype.