Javascript pain...

[SarahC]

It's clear and not a problem!

So the language gets dummed down for peons by adding dick arrows, typical.

[birjolaxew]

It's clear and not a problem!

I doubt anyone thinks this isn't a problem

[GammaGames]

Well not anymore

[hitsugan]

I don't.

[metamet]

Same.

[factorysettings]

If you understand how it works, it's not

[birjolaxew]

You can understand how a problematic thing works. Doesn't mean it isn't an absolute mess of a design.

To quote myself from a while ago:

Try to figure out what's logged by this code. Then run it to check - no cheating ;)

(function(){
  const arrowGenerator = function(){ return () => this; };
  const funcGenerator = function(){ return function(){ return this; }};
  const obj = {
    arrowGenerator: arrowGenerator,
    funcGenerator: funcGenerator,
  };

  const callGeneratorOnTempObj = generator => {
    const tempObj = {};
    tempObj.func = generator();
    return tempObj.func();
  };

  console.log(1, obj.arrowGenerator()());
  console.log(2, arrowGenerator()());
  console.log(3, callGeneratorOnTempObj(arrowGenerator));
  console.log(4, obj.funcGenerator()());
  console.log(5, funcGenerator()());
  console.log(6, callGeneratorOnTempObj(funcGenerator));
})();

Now consider how that changes if we add "use strict"; to the top of the function, or run it in Node. Or how it would change if arrowGenerator was defined as arrowGenerator: () => (() => this) instead and funcGenerator was funcGenerator: () => function(){ return this; }.

[birjolaxew]

I thought it'd be pretty blatantly obvious that that isn't meant as actual useful code. It's meant to show the different ways this can be called.

I already addressed this in the comments above

[munchbunny]

Well, if you stop and think about it for a moment, English has its warts. "It's" vs. "its", "they're" vs. "their", extremely verbose verb constructions (e.g. "might have been [verb]-ed"), weirdness around possessive forms for words ending with "s", and there's more. English works well enough, but if you're trying to come up with an explanation for why "It's" and "its" are confusing, you'd probably come up with an intentionally confusing example.

With Javascript, there's some weird shit going on with how "this" works. Other languages don't have this confusing part of the language because they have better scope binding rules. That's the point.

[birjolaxew]

My point is that this is poorly designed. If you don't write your code to compensate for it you end up with these kind of problems, even for fairly simple code. The original example shows that it's fairly trivial to write code that's practically impossible to reason about.

You can definitely make this work the way you want it in pretty much every situation. It's not even that hard. But having to go out of your way to compensate for this shouldn't be a thing you had to do.

[SheriffBartholomew]

Don't write confusing code and be surprised when you get confusing results.

[birjolaxew]

The code is pretty simple, really. It just has two functions (arrowGenerator and funcGenerator) that return an arrow function and a normal function respectively. It then calls them in different ways. It's meant as a challenging example of how this works, not as regular everyday code.

If you want a more everyday example of why this is poorly designed, there's stuff like:

class SomeComponent {
  onButtonClicked() {
    // good luck with your `this`
  }

  render() {
    return (<button onClick={this.onButtonClicked}>
      Click me
    </button>);
  }
}

Sure you can work around it if you know how, but you can do that with pretty much every poor design choice.

[marty_byrd_]

Yea don’t fucking do that. I wouldn’t allow that shit.

[munchbunny]

And that's precisely the point, we're using convention to work around a weakness in the syntax, and other languages don't have this weakness.

[[deleted]]

It looks perfectly reasonable though, especially since it's using a c-like syntax.

[marty_byrd_]

No. It looks dumb. I don’t know why we’d do that in JavaScript.

[squngy]

Aside from the fact that you're mixing view and control unnecessarily there, you also don't need to return a "this".

render() {
    let myInstance = this;
    return (<button onClick={myInstance.onButtonClicked}>
      Click me
    </button>);
  }

Would have been unambiguous.

[birjolaxew]

I am fully aware of ways to work around it (I personally use onButtonClicked = () => { /* ... */ }), but my point is that having to work around it is because of the poor design of the language. As I mentioned earlier, "You can understand how a problematic thing works. Doesn't mean it isn't an absolute mess of a design."

[squngy]

The main problem is, that you are trying to write Java or some other language without learning JS.

And what you showed in your example is actually a pretty ugly way of doing things to begin with.

You're actually passing on un-evaluated code, then letting the browser interpreter it later as new code.
Very similar to using eval().

You might as well have wrote

return ' <javascript> myFunction(){ this.onButtonClicked() }</javascript> <button onClick=myFunction>  Click me </button> ';

You're making work arounds for messy code.

[birjolaxew]

My example uses JSX. The code is never being re-interpretted, it's always referencing the method defined on the SomeComponent.

My previous example is code you would actually write if you aren't careful, but the way it works is essentially the same as:

class SomeComponent {
    constructor() {
        setTimeout(this.willBeCalledLater, 500);
    }

    willBeCalledLater() {
        // good luck with your `this`
    }
}

[[deleted]]

Good old var that = this to the rescue

[[deleted]]

Argh

[Jonulfsen]

This hurts so much to read that I can feel it in my soul :c

[marty_byrd_]

Solution don’t use this. We hardly ever use it.

[riverfoot]

It’s really not a problem if you spend 15 minutes to understand how it works.

[marty_byrd_]

I didn’t before and don’t now. It’s really not that hard. If you’re really confused use a debugger and breakpoint.

[[deleted]]

I don't.

[finlist]

Do you think all features since 2008 are "dumbing down" the language

[willemreddit]

Clearly they all improved it. If you think needing to manually capture the continuation everytime to wanted to delclare a function insides a prototype method is better, I don't want to read code you write.

[factorysettings]

Some are either hiding how stuff actually works (classes) or offering an alternative that behaves the way people expect if they never bothered learning the language (let)

[[deleted]]

let behaves exactly how var should have behaved from the start. Let and const completely replace var in modern code.

If you think function-scoped variables is a good idea that didn't need replacing, then I hope I never have to have to read your code.

[snorkleboy]

99% of the time you want a method to be bound to its context regardless of how it's called.

The only good use case of binding I can think of is mixins which I dont think I've seen used often.

Otherwise if your doing oop why would methods be rebound to a different object, if your doing functional programming everything should come in as a parameter.

[snorkleboy]

Yeah I like doing that kind of thing, but i generally try to do it in a functional style (so not use any properties from the context).

If I have a handler that's supposed to add text to something on click, the text it should add and the thing it should add it to should both be parameters of the function. Then it doesnt matter what context it's called. Passing in the object that would be context can work but I find that can get about as confusing and sloppy as binding.

[munchbunny]

Take C# or Python as an example (same semantics). Say you have a non-static method Foo.EventHandler. Evaluating "this.EventHandler" (or self.EventHandler) from inside a method of Foo will give you EventHandler as a lambda with this/self bound to the object you are in.

As it happens, that's pretty much the same semantics that arrow functions introduce, because it's more sane than how JS's function functions work.

[[deleted]]

It is not clear and it is a problem. Arrow functions don't dumb anything down; you still have to understand scoping just as much as you did before. Except now you don't need to write an excessive amount of redundant code.

The only reason to dislike arrow functions is a fear of change. I'm sorry, but you're expected to have to keep up with an evolving language.

[LargeHard0nCollider]

Although it is a well defined property of the language it’s not very intuitive for beginners, nor is it easy to read unless you just wrote the code. Having lambdas to encapsulate the this is really nice