3 ms·

I wonder why they released it without some support for mixins. Right now you might start with a ES6 class and then you need to go back to the old class system

I wonder why they released it without some support for mixins. Right now you might start with a ES6 class and then you need to go back to the old class system if you want the mixins because of a reusable component you use.

spicyj 12y ago
It's true that ES6 classes don't cover all existing use cases yet, which is why I specifically mentioned in the blog post that we're continuing to support React.createClass fully. The main Facebook site is still using React.createClass everywhere, though we are starting to use ES6 class components for some smaller projects here. As I mentioned in another comment on this thread, many mixins can be implemented as higher-order components that we call "containers". Many others relate to data fetching, so we're looking at adding first-class support for data subscriptions which can replace even more uses of mixins. (And in my experience, it's rare to add mixins to a component after it's written.) ES6 classes aren't suitable for everyone yet ("Ask your doctor if ES6 classes…") but they're a new API which is more convenient for some use cases, so we chose to add it now instead of waiting until we're at perfect feature parity to give people the chance to use the new syntax.
- the_mitsuhiko 12y ago
  The thing is that I would like to use ES6 classes. There are some situations where it just feels so bad to do "if (this.doFoo !== undefined) { this.doFoo(); }" because you can't really define empty interfaces in mixins. Subclassing would help a ton here.
petrbela 12y ago
Mainly to support ClosureScript and other languages. There are ways to go around the need for a mixin, usually through composition, so with a certain coding style you might not need mixins at all.
- the_mitsuhiko 12y ago
  The problem are mixins from elsewhere. But yeah, most of them can be replaced.

spicyj 12y ago

It's true that ES6 classes don't cover all existing use cases yet, which is why I specifically mentioned in the blog post that we're continuing to support React.createClass fully. The main Facebook site is still using React.createClass everywhere, though we are starting to use ES6 class components for some smaller projects here. As I mentioned in another comment on this thread, many mixins can be implemented as higher-order components that we call "containers". Many others relate to data fetching, so we're looking at adding first-class support for data subscriptions which can replace even more uses of mixins. (And in my experience, it's rare to add mixins to a component after it's written.) ES6 classes aren't suitable for everyone yet ("Ask your doctor if ES6 classes…") but they're a new API which is more convenient for some use cases, so we chose to add it now instead of waiting until we're at perfect feature parity to give people the chance to use the new syntax.

the_mitsuhiko 12y ago
The thing is that I would like to use ES6 classes. There are some situations where it just feels so bad to do "if (this.doFoo !== undefined) { this.doFoo(); }" because you can't really define empty interfaces in mixins. Subclassing would help a ton here.

petrbela 12y ago

Mainly to support ClosureScript and other languages. There are ways to go around the need for a mixin, usually through composition, so with a certain coding style you might not need mixins at all.

the_mitsuhiko 12y ago
The problem are mixins from elsewhere. But yeah, most of them can be replaced.