Comment by nulagrithom | Hacker News Reader

Comment by nulagrithom | Hacker News Reader

Understanding 'this' in JavaScript is simply table stakes at this point. You and anyone else who touches your JS code should have a decent grasp on 'this'. Citing "complexity of this" while using React is just absurd in my opinion...

You Don't Know JS: this & Object Prototypes cleared it up nicely for me.[0] Love the series in general too.

Also -- and I'm not sure how it's typical done when taking a functional approach -- where do these functions "live"? What if we want to use a Person in another module/component/whatever? Do we basically just have a collection of "static" functions on a helper class that we're going to be using? I'm not sure that's a real gain. Would rather see the functions available on the Person itself (though maybe that's just my OOP ways talking).

And then there's the "pure function" part. Without explicit documentation and no other knowledge of this individual's functional predilections, I would be surprised when the setName function actually creates an entirely new Person and then sets it name.

I don't know. I really do enjoy functional approaches, but I don't think avoiding 'this' is a good reason, and I feel like the example given isn't the best scenario to illustrate.

[0] https://github.com/getify/You-Dont-Know-JS/tree/master/this%...

Nonsense. It's not a question of whether you understand `this` or not, it's a question of whether thinking about the different cases of `this` is really a good use of your time. Alternately: `this` is poorly designed and gets in your way.

Here's an example of a recent production bug:

  async.timeout(server.close, 60000)(exit)

And one way to fix:

  async.timeout(cb => server.close(cb), 60000)(exit)

In case the problem is non-obvious (that's the point!), the first line loses the binding to the specific `server` in question. Lovely. `this` in JS forces the consumer of a module (in this case `server`) to have knowledge of how the module represents its state in order to use it. That's not a good pattern.

> In case the problem is non-obvious (that's the point!),

I think what the gp was saying is that the table stakes for JS is this being obvious. I guess whether it is is subjective, but I have to agree. Your example is glaringly obvious to me. Any assignment of a method on an object, or passing of one as an argument (i.e. any passing/assignment that includes a dot before a method) stands out. This doesn't involve any cognitive overhead if you actually know what `this` is.

> `this` in JS forces the consumer of a module (in this case `server`) to have knowledge of how the module represents its state in order to use it.

No it doesn't... It requires the method to have access to the module it's defined on, which means you can't pass (i.e. reassign) the method on its own. In your example, the module (server) is not being consumed, only one of the modules methods is consumed on its own; the module is left behind and not consumed (i.e. `this` is left behind)

It's kind of funny to hear that the example is 'glaringly obvious', given that if the module in question was implemented as a singleton, the first line would be both correct and preferable...

The fact that your statement includes a qualifier ("if the module... was implemented as...") means it's never going to be preferable. Nothing should depend on a qualifier that isn't self-evident from syntax.

As for what is preferable...

  const closeServer = () => server.close();
  async.timeout(closeServer, 60000)(exit);

Abstracting `server.close()` and naming it `closeServer` may seem to be a bit redundant, but the example given was slightly contrived so this would be almost always preferable in practice.

The more I learn JS the more I am worried that I am not using 'this' right.

I swap back and forth between javascript/python and with JS it always feels like I am one step away from disaster if I accidentally forget to bind this.

I feel you, but sometimes, I am using

    var that = this

just to be sure

Sounds like you are using it right but yeah you can setup the bindings or do an arrow function.

I've been preferring just setting up the bindings in the constructor over arrow functions.

So for the author's example I'd just do: constructor (){ this.increment.bind(this); }

Then the template can stay cleaner with just onClick={this.increment}

Also, if you only use arrow functions you don't even have that problem.

Then you had different problems. You don't always want to capture `this`.

Example?

I almost always want event listeners to have `this` refer to the element on which they were added, not the class from which they came. It's the default case for all but arrow functions, so it takes no extra effort in most cases, and if I really need other state, I find it is clearer if it comes through a closure. Plus, making it a habit makes it easier to keep it straight.

I found this only to be a problem in legacy libraries.

The Gambit he's claiming is straightforward. Given type X, calling object of type X, a's method a.doit() is just sugar on the fundamental doit(a). The way you get the former is to introduce JS concept of _this_ which is accidental complexity that doesn't pull its weight. I tend to agree.

Reply on news.ycombinator.com