[vanderZwan]

I lost an entire week of work last year to not knowing that React switched from automatically binding methods, because none of the documents mentioned that. Including the release notes of the version of React where they turned that off, IIRC.

It is easily the most rage-inducing programmer moment I ever had, mainly because it's so fucking stupid and the only reason it took me so long was because the actual tutorial and documentation was fucking lying to me.

Technically speaking they fixed it by now: they mention the bind-thingy under "Handling Events" in the documentation, which you randomly have to stumble upon:

    constructor(props) {
      super(props);
      this.state = {isToggleOn: true};
  
      // This binding is necessary to make `this` work in the callback
      this.handleClick = this.handleClick.bind(this);
    }
  
    handleClick() {
      this.setState(prevState => ({
        isToggleOn: !prevState.isToggleOn
      }));
    }

However, the tutorial is still deceiving:

    constructor() {
      super();
      this.state = {
        squares: Array(9).fill(null),
      };
    }
    
    handleClick(i) {
      const squares = this.state.squares.slice();
      squares[i] = 'X';
      this.setState({squares: squares});
    }

This is fine in this specific situation because the render method uses a closure:

    onClick={() => this.handleClick(i)}

But this is a subtle nuance that can be an incredible pain to figure out. There is no mention of all the this-related pains in the tutorial anywhere.

[0] https://reactjs.org/tutorial/tutorial.html

[1] https://reactjs.org/docs/handling-events.html

[danabramov]

I think you might be mistaken. `React.createClass` always did autobinding, and it still does. The ES6 classes (which the tutorial now uses) never supported autobinding.

React documentation switched from `React.createClass` to ES6 classes because they community already did at that point, and wanted to see the more "mainstream" pattern documented. I'm sorry it wasn't obvious that there is a difference between the function call and the language syntax, but it's definitely not a change in React.

The tutorial you mention works fine because `onClick={() => this.handleClick(i)}` is an alternative way to bind methods that also works. That's what the tutorial uses because it's easier to explain React first without diving into how `this` works in ES6 classes. And you can run that code and verify it works. (Every step of the tutorial has a link with a code example.) So no, it has not been broken for a year.

We also did blog about ES6 class support: https://reactjs.org/blog/2015/01/27/react-v0.13.0-beta-1.htm...

And autobinding of `React.createClass` (which you can still use—it's just in a separate package) is also still documented: https://reactjs.org/docs/react-without-es6.html

That said I'm sorry about your bad experience.

[vanderZwan]

Comment-sniped before I could update my message. Yes, I was mistaken, it has been changed.

> We also did blog about ES6 class support

Not everyone reads blogs all the time. If a new product is released, it's reasonable to expect the documentation to mention the breaking changes.

[danabramov]

That's my point: there was no breaking change :-)

React.createClass() always did (and still does) autobinding.

ES6 classes never supported autobinding.

We couldn't have changed your code from one to the other. There is no "release notes" associated with that change—changing the syntax was a conscious decision you made either when converting or when writing a new components.

[vanderZwan]

If you already know about ES6 classes, what you say is obvious, I'm sure. Or if you're in a place where someone more experienced can teach you. Neither of those things applied to me. I had no prior webdev experience, used to languages where this does not behave like it does in JS, and relying on documentation to guide me.

It can be nearly impossible to Google something if you don't even know what it is that you don't know.

There's a comment by, well, YOU, from March this year[0] on a github issue discussing improvements to documentation, suggesting it is one of the most common troubleshooting issues, so I'm not the only idiot failing to grasp this when first diving into webdev.

It would help tremendously if there was even just a simple sentence in the tutorial like:

> "By the way, we are using an arrow function here because JavaScript has some subtle behaviour when it comes to this, but explaining the details of that here would take too long. See [here], [here] and [here]"

.. with a few links explaining both this and ES6 classes in more detail. Because otherwise you can easily get stuck not even knowing where to look for the cause of the bug.

[0] https://github.com/facebook/react/issues/8060#issuecomment-2...

[always_good]

I think you need to take some personal responsibility here for not knowing how Javascript works.

That you've written so much indicates to me that you expect other people (like a framework's documentation) to introduce you to every language idiosyncrasy in any place you happen to be reading.

That's not what I want people to expect from me as a professional. People should be able to expect me to credentialize in the domain at hand.

[vanderZwan]

I sincerely hope you never have and never will work in education, or in any way have to teach others how something works.

[amk_]

Still, it isn't entirely obvious under what conditions the methods of a React Component class are going to be called. For all you know they might always be called against the instance.

[danabramov]

Would you like to send a PR? I don't mean to sound defensively, but I have spent a huge amount of effort on docs in the past, and as you can see they're still not good. :-) So some help from you (you know the pain points!) would be handy.

[threatofrain]

The subtlety that arrow functions are different would bite you anywhere in javascript, including vanilla. It should come up if you read the MDN documentation on this or arrow functions.

[eyelidlessness]

While you're right that there was no breaking change, it isn't unreasonable for a developer to expect, when a feature is introduced that is analogous to an existing feature, that the new feature's differences will be explained.

[poxrud]

For those who are confused... If you have a click handler "handleClick" that references "this" inside of its definition it will be broken if you do

onClick = {this.handleClick}

This is due to the way "this" is scoped in JS.

Dan mentions that it works fine if you instead do: onClick = {() => this.handleClick()}

This is using the new ES6 arrow functions which fix the "this" scoping problem.

Another alternative is to use bind() inside the onClick and set "this" to the correct value that you want.

onClick = {this.handleClick.bind(this)}