React team is doing an amazing job. I remember when it was first announced, I thought Facebook was crazy. "JSX? That sounds like a bad joke!" I don't think I've ever been so wrong. After hearing so much about React, I eventually tried it out and I realized that JSX wasn't a big deal at all, and in fact it was actually pretty awesome.
Their migration strategy is great for larger actively developed applications. Since Facebook is actually using React, they must have a migration strategy in place for breaking changes. Since breaking anything has such a big impact on the parent company, it makes me feel like I can trust em.
Heck, most of the items in this list of changes won't surprise anyone that's been following the project. Now there's less magic (e.g. React.createClass with its autobinding and mixins), and less React-specific code in your app (e.g. react-addons-update has no reason to live as a React addon when it can clearly live as a small standalone lib).
The only benefit to the template is if you use fancy features (#each, binding, etc) which is worse because now you have two places where the logic happens.
JSX is a macro (it's expended to plain JS at compile time). Almost every other major framework uses DSLs (strings are evaluated and transformed into code at run time).
Basically nobody does this, as far as I know. I think some of the big component authors like Wijmo do, but not most people, it's way too messy.
The composition is usually in the form of higher order components. It's very simple to wrap a function with another one, with more or different functionality. Classes just make it equally as simple when the wrapped component has its own state to manage.
Point is, nobody really cares whether they're ES6 or createClass, because nobody's actually doing inheritance. It's just that we JS devs like to stay on the bleeding edge, and we like to think that we're converging on standards even if that's a silly dream.
Example: show a spinner for 1 second before displaying.
const F = (props) => <div>{props.content}</div>;
class C extends React.Component {
state = { initial: "state" };
render = () => <div>{this.state.initial}</div>;
}
function delayWithSpinner(WrappedComponent) {
return class extends React.Component {
state = { showSpinner: true };
stop = () {
this.setState({ showSpinner: false });
}
render() {
return this.state.showSpinner
? <Spinner duration={this.props.duration} onCompletion={this.stop}/>
: <WrappedComponent {...this.props}/>
}
}
}
// exactly the same composition pattern for
// both classes and functions.
const SlowC = delayWithSpinner(C);
const SlowF = delayWithSpinner(F);
> 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 have a fairly large react codebase with some components using inheritance. It's not the solution to every problem certainly, but sometimes an abstract base component can be useful.
ES6 classes are a complete mess brought by corporate people loving OO, even in a setting that doesn't make sense.
You can "autobind" with this notation:
myMethod = () => {
}
but it doesn't look as good as myMethod() {} and you have to remember this EVERY TIME you add a method.
Also, you never need to use the constructor in React.
Just do: state = {} in the body of the class.
You may need babel presets #918718$$&ééàdi for it to work though.
Classes and inheritance are features of type systems, not OOP. Plenty of functional programming JS libraries use classes for testing types (for example, the Either monads' Left and Right).
Their migration strategy is great for larger actively developed applications. Since Facebook is actually using React, they must have a migration strategy in place for breaking changes. Since breaking anything has such a big impact on the parent company, it makes me feel like I can trust em.
Heck, most of the items in this list of changes won't surprise anyone that's been following the project. Now there's less magic (e.g. React.createClass with its autobinding and mixins), and less React-specific code in your app (e.g. react-addons-update has no reason to live as a React addon when it can clearly live as a small standalone lib).