[thatswrong0]

Mild rant:

I'm not convinced ES6 classes are better than components created the old way.

First, the lack of autobinding callback functions for child props is not ideal. I don't even have to think about it with createClass, and it requires at least one extra step with ES6. It's less convenient.

Second, I don't think HOCs are necessarily easier to reason about than mixins in many situations. React is already quite deficient in its own testing utilities (esp. when it comes to functional stateless components and HOCs such that I'd recommend everyone use enzyme), and testing a multi-wrapped HOC can be a PITA whereas whereas a component with multiple mixins is simpler to reason about in comparison. What I care about is testing the output of a component; I don't want to have to understand the internal structure of a component in order to test it in a shallow manner.

Id love to see an argument as to why they are better, but I haven't seen anything convincing. Plus our app uses a ton of non-invasive mixins and the upgrade away from them would complicate the app and make testing way more complicated.

[peterhunt]

I was the guy who came up with autobinding in older Reacts and I'm glad to see it gone. It might save you a few keystrokes but it allocates functions that'll never be called in 90% of cases and has noticeable performance degradation. Getting rid of autobinding is a good thing.

[wesleytodd]

As much as I agree with the performance side here, I believe the usability for devs is an important factor. Let the users who really need that last bit of perf opt-in, and let everyone else just go along in blissful ignorance. And I am honestly alright if "opt-in" means use preact or some other project.

Think about the reasons jQuery and WordPress were popular, despite performance issues, they JUST WORKED for people. React is the jQuery of vdom projects, don't try to make it the something it is not.

[peterhunt]

Don't you think the fact that React.createClass() behaves differently than JS makes it less usable (i.e. more surprising) for experienced developers? The goal of React is not to fix JavaScript's warts, nor is its goal to make programming easier for non-programmers. I believe if this is the goal of your project the end result would look very different from React (probably would look more like Vue).

[thatswrong0]

Where did we mention making programming easier for non-programmers? I think libraries should strive to be as usable as possible to _all_ programmers, which in this case means reducing or eliminating very common operations (such as binding callback functions). When we're talking about working on a large codebase, useless boilerplate is a legimate cost both in productivity and maintenance.

And by this logic, we shouldn't use JSX either.

[peterhunt]

The wordpress analogy.

I think the complaints you have are valid but should be solved by js, not react.

[gavinpc]

I felt the same way and avoided `class` for mostly the same reasons.

For better or worse, there are many ways to make pseudo-classes using Javascript. Is prototype configurable? Writable? Enumerable? What about the properties of prototype? Are they configurable? Enumerable? Writable? And there are still people who clobber the default prototype, killing its `constructor` and changing the above.

And that's just one level. When it comes to calling super constructors and super methods, things get much wilder.

I've come to terms with the view that ES6 classes are just a way for us to move on with our lives. We do a common thing in a common way, and never think for a second about what subclassing approach to use, what method is compatible with what other method, and whether it's implemented correctly.

Yes, you need a build step to target older browsers. But you needed a dependency anyway, to support whatever ad-hoc method you were using.

I never used mixins, but I agree that HoC's present a special problem for testing.

[algesten]

I'm one of those people that still use coffeescript (if I'm going to transpile anyway, I'd rather use a language I like).

I use coffeescript classes as components without any problem and that inserts an "extends" function into every compiled .js-file that has a class.

I suspect people that need ES5/ES6 compatibility that currently rely on React.createClass as a peer dependency can switch to maintaining their own createClass function local to the project. Suboptimal, but not a lot of code.

[tlrobinson]

If you don't want to think about binding, just use the arrow function syntax:

    class Foo extends Component {
      bar = () => {
        // ...
      }
    }

[acemarke]

Requires the Stage 2 Class Properties syntax to be enabled (via Babel plugin), but yes, that's the "nicest" way to do it, and the current approach recommended by the React team. There's also various binding utilities, like https://github.com/cassiozen/React-autobind . I've got discussion of the various binding approaches listed at https://github.com/markerikson/react-redux-links/blob/master... .

[amk_]

I use and recommend this syntax, but you do have to have babel-preset-stage-2 to enable the class properties transform.

https://babeljs.io/docs/plugins/transform-class-properties/

[TheSisb2]

This compiles poorly and has a performance cost, it turns out. Doing:

constructor(props) { super(props); this.func = this.func.bind(this); }

Is better if you care about performance.

[ConAntonakos]

Just curious: are there tests proving this?

[peterhunt]

w.r.t. mixins vs HOCs

Mixins don't compose safely and were always kind of a hack.

HOCs are also kind of a hack, but at least they behave predictably (i.e. they do compose).

I don't really get the argument that React lacks testing infra. I know a lot of people say this but no one has talked me through an example yet.