Is this really a valid way of creating a class method? - "React 26: Bind 'this' with an ES6 Arrow Function"

[Greenheart]

Given the following experiment,

is the following really a valid ES6 class method?

class MyComponent extends React.Component {
  /* ... */
  setMessage = () => this.setState({ message: 'Goodbye!' })
  /* ... */
}

I thought methods only could be function declarations with the methodName () {} syntax.

[Greenheart]

I guess this could be some kind of syntactical sugar of the React library?

[bonham000]

hmmm.......... interesting so this is now more clear after I've investigated: apparently the use of arrow functions as class methods requires the use of this technically experimental ES7 property initializers feature, which can be enabled with babel stage-2 preset or this class transform preset.

Here is some (not complete) info and some more.

Babel's view and the React Docs to the rescue — this and the following 'Autobinding' section: "However, when we have the future property initializers, there is a neat trick that you can use to accomplish this syntactically" — this is from notes from an older version of React though... I can't seem to find anything more up to date (within the last year-ish) about this.

@no-stack-dub-sack and @Greenheart what do you think we should do about this? At the moment there are a few challenges using this syntax.

[no-stack-dub-sack]

@bonham000 @Greenheart It's a good catch, but it's incredibly common these days, valid in CodePen and CreateReactApp both, which are the 2 most common places our campers will be writing React code. I think as long as we note it, we can prob keep it - it's valid in the challenges, its supported by the React team, and is a common way of writing react methods that's valid where our campers will likely be coding.

A prominent note would probably be helpful

[Greenheart]

@bonham000 @no-stack-dub-sack Thanks for the info! If it's a common practice, I'd say we should go with it.

I'm just too used to vanilla JS I guess :smile:

[bonham000]

Leaning toward providing a note at this point since doing otherwise would change several challenges, and, realistically, using arrow functions is a lot easier than binding them all explicitly in the constructor (i.e. it's very useful to have so worth showing people).

[Greenheart]

@bonham000 I like the idea of having a note.

If this gets accepted as a standard JS feature, it could be removed.

[no-stack-dub-sack]

@Greenheart Agreed

[bonham000]

Great I've made a note and revised the challenge description. Would you all @Greenheart @no-stack-dub-sack mind taking a quick look and seeing if this looks sufficient?

[Greenheart]

@bonham000 Excellent! :smile: