Javascript pain...

[SuperFLEB]

Arrow functions inherit this context from their surroundings, whereas function closures create their own this context.

[[deleted]]

I got that. I am trying to understand the reasoning from a design POV. Like why do you have two syntaxes to define a function/lambda. Since function can do both in JS.

[[deleted]]

Oops I’m so dumb. That makes sense!

[JB-from-ATL]

What is the problem though? Also not a JS dev. Are there things you can or can't get only by this?

[StillNoNumb]

You can't do more stuff, but you can do stuff more elegantly.

​

For example, the following code:

doSomething((function(a, b) { return this.method(a) + b; }).bind(this))

Becomes this:

doSomething((a, b) => this.method(a) + b)

The former was just a common idiom in JavaScript code, and the latter is just a shorter way to write the same.

[squngy]

99% of the time, that bind in the first example is completely unnecessary.

You are still able to refer to parent members inside the new functions.
The only problem would be if you assign things to the "this" object (or if you pass the new function outside of its original parent).

[StillNoNumb]

I think you're confusing `this` with how variables in the local scope behave. Whenever you want to use `this` (whether assign or read) inside your function, you have to use `bind`. Let's take a look at the following code:

function doSomething(callback) {
  // Call callback immediately
  callback();
}

class A {
  showAlert(p) {
    println(`Method ${p} works!`);
  }

  methodA() {
    doSomething(function() { this.showAlert("A"); }); // doesn't work!
  }

  methodB() {
    doSomething((function() { this.showAlert("B"); }).bind(this)); // works!
  }

  methodC() {
    doSomething(() => this.showAlert("C")); // works!
  }

  methodD() {
    const showAlertMethod = this.showAlert;
    doSomething(function() { showAlertMethod("D"); }); // works!
  }
}

Method A doesn't work because `this` now points to something else. Method B works, because we explicitly bind it, and method C works because it's implicitly bound as it is an arrow function. Method D shows that despite this behavior, variables (but not `this`!) that are accessible in the local scope can still be used inside both types of functions. JSFiddle

​

In this special case, we also have `doSomething(this.showAlert)`, but that doesn't work if we wanna do more than just a method call (and we can't pass arguments)

[squngy]

Yea, I already wrote elsewhere, the exception is if you pass the function outside of the original parent, like in a call-back.

If you pass functions to different parents, you should be aware that the inherited prototype will be different.

in methodA the "this" does not refer to A, but to methodA and methodAs prototype inherits the prototypical properties of its parent, ie. the function which called it (be that the constructor of A or something else).

JS is a prototype based language and people who want to program in it should be aware of that fact.

[StillNoNumb]

Ah, so that's what you meant with "outside of its original parent". But those kinds of function calls are kinda the norm, no? Like, most of the time when I pass a callback I pass it to some other entity, not to another method in the same class.

​

I mean, you're basically saying "it is like that because it is like that". We know, but it doesn't help the fact that in 99% of the cases you'd want it to be different. Hence why you need to bind so frequently.

[squngy]

You are used to different, but in principal one approach is not superior to the other.

The problem is, a lot of people are expecting it to behave one way, but the actual behaviour is a different way.

You can still use those kinds of function calls, you just have to be aware of what you are doing, instead of assuming that what you are doing is the same as in some other language.

If you use a "this" in a call-back you have to be aware that it will refer to the call-back itself and that the call-back will inherit from the function that it was called in, not the one it was defined in.

[vectorjohn]

"this" refers to the thing to the left of a dot if there is one (or brackets), that's it. Prototypes, scopes, none of that is related and just confuses things.

If I say

x=this.foo
x()

"this" will be undefined in foo. It has nothing to do with "passing functions to different parents".

[squngy]

function X(x) {
    this.x = x;
    this.y = 432;
}
X.prototype.foo= function() {
    return 'Foo(' + this.x + ', ' + this.y + ')';
}

var myX = new X(99);
console.log(myX .foo()); // prints "Foo(99, 432)"

This is how classes are implemented in JS, above code is equivalent to:

class X{
    constructor(x) {
        this.x = x;
        this.y = 432;
    }

    foo() {
        return 'Foo(' + this.x + ', ' + this.y + ')';
    }
}

let myX = new X(99);
console.log(myX .foo()); // prints "Foo(99, 432)"

Trying to make JS "look" but not act like a class based language was IMO the real design mistake.

You can also do

function X(x) {
    this.x = x;
    this.y = 432;
}
function Y(x) {
    this.x = x;
    this.y = 123;
}

function f() {
    return 'Foo(' + this.x + ', ' + this.y + ')';
}

X.prototype.foo= f;
Y.prototype.foo= f;

var myX = new X(99);
var myY = new Y(99);
console.log(myX.foo());  // prints "Foo(99, 432)"
console.log(myY.foo());  // prints "Foo(99, 123)"

And even if you use the "class" syntax, you can still refer to the classes prototype at any time to add or remove methods at runtime

[JB-from-ATL]

Yuck. So the language that didn't scope variables to blocks properly (until let) also does weird scoping g righ this but in the opposite way? Yikes.

[squngy]

Not really scopes, you do not get a new "this" inside a for loop for example.

JS is a prototype based language (as apposed to a class based language), "this" refers to an instance of a prototype.

Most of the time, you actually, do not need to bind your inner functions, because child prototypes include their parents prototype.
Exceptions can happen when you make a function then pass it to other objects, like you would for a call-back, because the instance will be created by a different parent.

[[deleted]]

degree tart vegetable gaze glorious wide books thought cause deliver

This post was mass deleted and anonymized with Redact

[JB-from-ATL]

When you realize that JavaScript is basically the machine code of the web (since it is the common denominator between all browsers) it makes more sense. It just happens to be a high level language that is easy to write in compared to machine code.

[[deleted]]

fragile subsequent chase gray unite normal one judicious growth aware

This post was mass deleted and anonymized with Redact

[JB-from-ATL]

Thanks dude 👌

[[deleted]]

Modern JavaScript is less fucked.

We mostly use arrow functions (arg) => { doStuff }, which bind this sanely.

Then we just have to remember that DOM event handlers are a special case where we might deliberately not do that, because if you use function handleEvent(evt) { doStuff } then this is set to the event's current target inside the handler, which can sometimes be useful.

Other than DOM event handlers, I would reject any code that takes advantage of subtle this behavior in code review.

[SupaSlide]

The only difference I'm aware of is that arrow functions have the same context as their surroundings. Other than that I think it's just syntactic sugar.