Big news seems to be removal of `React.createClass()` in favor of:
class HelloWorld extends React.Component {
} class HelloWorld extends React.Component {
}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.
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.
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.
class Foo extends Component {
bar = () => {
// ...
}
}constructor(props) { super(props); this.func = this.func.bind(this); }
Is better if you care about performance.
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.
And by this logic, we shouldn't use JSX either.
I think the complaints you have are valid but should be solved by js, not react.
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.
It's sad to see how new generation can't learn lessons of the past.
https://facebook.github.io/react/docs/composition-vs-inherit...
>So What About Inheritance?
>At Facebook, we use React in thousands of components, and we haven't found any use cases where we would recommend creating component inheritance hierarchies.
We dislike inheritance as much as you do, but we also dislike ad hoc class systems that have worse performance.