5 ms·

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'. Citi

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%20%26%20object%20prototypes https://github.com/getify/You-Dont-Know-JS/tree/master/this%...

k__ 9y ago
Also, if you only use arrow functions you don't even have that problem.
- moron4hire 9y ago
  Then you had different problems. You don't always want to capture `this`.
  - always_good 9y ago
    Example?
    - moron4hire 9y ago
      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.
      - k__ 9y ago
        I found this only to be a problem in legacy libraries.
RSZC 9y ago
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.
- lucideer 9y ago
  > 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)
  - RSZC 9y ago
    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...
    - lucideer 9y ago
      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.
jtchang 9y ago
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.
- gcoda 9y ago
  I feel you, but sometimes, I am using var that = this just to be sure
  - deleted 9y ago
    [deleted]
- exclusiv 9y ago
  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}
nickbauman 9y ago
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.

k__ 9y ago

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

moron4hire 9y ago
Then you had different problems. You don't always want to capture `this`.
- always_good 9y ago
  Example?
  - moron4hire 9y ago
    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.
    - k__ 9y ago
      I found this only to be a problem in legacy libraries.

RSZC 9y ago

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.

lucideer 9y ago
> 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)
- RSZC 9y ago
  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...
  - lucideer 9y ago
    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.

jtchang 9y ago

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.

gcoda 9y ago
I feel you, but sometimes, I am using var that = this just to be sure
- deleted 9y ago
  [deleted]
exclusiv 9y ago
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}

nickbauman 9y ago

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.