Add an explanation here why this.handleEvent won't cause the this t…

[KennethKinLum]

…o be correctly bound

Just a pitfall about the form this.handleEvent looking like this.handEvent(), with the this.handleEvent, when invoked, have the this incorrectly bound, but the form this.handleEvent() in fact does have this correctly bound, and this subtle difference may give a wrong impression.

[reactjs-bot]

Deploy preview for reactjs ready!

Built without sensitive environment variables with commit 9e7f7f3

https://deploy-preview-3500--reactjs.netlify.app

[reactjs-bot]

Deploy preview for reactjs ready!

Built without sensitive environment variables with commit 713c597

https://deploy-preview-3500--reactjs.netlify.app

[rickhanlonii]

Isn't this what the paragraphs above and below explain?

[KennethKinLum]

JavaScript has this property when fn is called

fn()    // first form

then the this is bound to the global object inside of fn

But when

obj.fn()    // second form

is called, then inside of fn, the this is bound to obj

In ReactJS's case, it is onClick={this.fn}

So although it looks like the second form above, it actually is the same as assigning this.fn to g, and then onClick={g}, which is actually the first form above. I am adding the note saying be careful, it is a pitfall that the form looks like obj.fn() but it actually is not the case.

[rickhanlonii]

Right, isn't that what the previous and next paragraphs explain?

You have to be careful about the meaning of this in JSX callbacks. In JavaScript, class methods are not bound by default. If you forget to bind this.handleClick and pass it to onClick, this will be undefined when the function is actually called.

This is not React-specific behavior; it is a part of how functions work in JavaScript. Generally, if you refer to a method without () after it, such as onClick={this.handleClick}, you should bind that method.

[KennethKinLum]

That's because when I saw the code {this.handleClick}, since it is ReactJS specific, I didn't know how it is transpiled to. So I may think in my mind, that it is invoked as this.handleClick(), but it is not. It is actually invoked like let g = this.handleClick and then g()

[rickhanlonii]

Yeah, that's why this section explains how it is JavaScript behavior and not React specific behavior.

[KennethKinLum]

I think that explanation is not so clear as to, if it is this.handleClick(), then it is bound correctly. If it is this.handleClick, then it is not bound correctly. There is a subtle difference there.

[eps1lon]

So in your mind onClick={this.handleClick} would be transpiled to onClick: this.handleClick()? Wouldn't you also expect that it is immediately called instead of calling it only when the click happened?

I understand that this is a hard to explain topic. But I don't think the new paragraph is helping since it introduces new concepts like "the form of this.handleEvent()" and "evaluated to be a reference to a function object".

Would it maybe help to show how this somewhat looks in terms of actual code?

const componentInstance = new Toggle();
const element = { props: { onClick: componentInstance.handleClick } }

document.addEventListener('click', event => {
  const onClick = element.props.onClick;
  // Not equivalent to just `componentInstance.onClick(event)`
  onClick(event);
})

But this can be just as problematic because e.g. react event handlers aren't called with native events.

Aside: I'm sure Ricky knows how this works and how there's a difference between this.handleClick and this.handleClick(). The problem we should be focusing on is how we explain it and where we can avoid confusion.

[KennethKinLum]

I actually worked on some other projects first, and then came back to seeing onClick={this.handleClick}.
Because it was onClick={this.handleClick}, I might have thought at first it might be something that ReactJS transpiles to onclick: () => this.handleClick(). Somebody told me it is not done by addEventListener but by createElement, but either case, I might have thought of onclick: () => this.handleClick() but in fact, it is onclick: handleClick. So if it is onclick: () => this.handleClick() then it actually works, but if it is onclick: handleClick, then it doesn't work.

So I just wanted to add the pitfall and reminder that, when we see this.handleClick, don't think of it as this.handleClick(). It is just something that, if I remember this pitfall, even if I look at the code after some time, I still remember always to bind it first this.handleClick.bind(this).

So I think if I summarize it as three ways: (1) this.handleClick.bind(this) (2) () => this.handleClick() (3) handleClick = () => { ... } using arror function when it is defined in the class, then the pitfall can be avoided. I think when a potion of the reader sees onClick={this.handleClick}, whether they know if it is this.handleClick(), then it is in fact correctly bound. Or some of them may think, it in fact looks like this.handleClick(), so how come it is not bound correctly? So I just wanted to add the explanation there to say, it is in fact the same as onClick={g}.

[eps1lon]

Yeah, so it might make sense to link to the section that explains how JSX is transpiled in case people are wondering. Otherwise I don't see how we can guard against people making unfounded assumptions.

Aside: Transpiling onClick={this.handleClick} to onClick: () => this.handleClick would break memoization. So less transpilation magic is actually beneficial here.

[KennethKinLum]

Yeah, do you suggest adding a short explanation there or adding a link. If the readers see onclick: this.h is the same as onclick: g, and the binding is lost like that, then we have all the readers covered. Those who don't know why the lost binding can go look up other JS blog or tutorial.