Closed igl closed 9 years ago
At least one reason was to reduce React's API surface area and defer to standard JS conventions when possible (i.e., React is not in the business of providing a class abstraction).
From that, it follows that defining React components is less opinionated, allowing users to use whatever langauge/sugar they like: https://facebook.github.io/react/blog/2015/01/27/react-v0.13.0-beta-1.html#other-languages
Agreed that manual binding is annoying, but that should be solved with ES7+ Property Initializers: https://facebook.github.io/react/blog/2015/01/27/react-v0.13.0-beta-1.html#es7-property-initializers
I'm inclined to agree with @igl. There's a lot of useful automagic that disappears with classes and it becomes very tedious to create an es6 class-compatible flavor of mixin that also implements the shared lifecycle events like componentDidMount
.
I've been using the new syntax in an internal project for a few months and am toying with the idea of going back to the createClass
way because it just feels so much better to work with and requires less manual rigging.
Feel free to continue using createClass
, it hasn't been removed nor deprecated.
This is a great topic for the discussion forums but is purely noise in our issue tracker, please move to https://discuss.reactjs.org/ if you'd like to carry on.
I see there are 0 advantages over
createClass
only disadvantages. Why was this implemented already? I hate doing .bind and dealing with constructors and Foo extends Bar extends extends Baz extends Base. Mixins are nice the way they are. I can mix-in trait-like objects and don't have to deal with constructors messing things up. This is a huge step backwards into the backbone era. This is brainwashing another generations of pre-java noobs to think side effect sputtering class hierarchies are somehow "better" rant over