I'm looking forward to deleting all the annoying `.toJS()` conversions everywhere I've used an immutable-js collection rather than a js array. (PR: https://github.com/facebook/react/pull/2376)
I'm curious to see how mixins play out with ES6. While something similar to 'include' in Ruby would be nice, I've got a hard time seeing how that would fly with multiple invocations of getInitialState, for example.
Of course, the big thing we're all waiting for is Native. If that truly offers a bridge, rather than a wrapper, to native APIs from Javascript, then it will be a game-changer.
Most cases of mixins (especially ones that involve state, as you allude to) can be implemented via composition by creating wrapper components instead. This is how Relay (http://facebook.github.io/react/blog/2015/02/20/introducing-...) works and makes different components more contained and easier to reason about. Here's one description of how to develop containers (really, higher-order components) from someone who works on Relay:
Like spicyj said, the wrapper components pattern works really well. Some people have started referring to this as a separation between "smart" and "dumb" components. For instance, "smart" components do things like fetch data, then pass the data as props to "dumb" components. It's a cleaner separation of concerns than having a single component do everything via a mixin.
I strongly feel that React Native is going to come out right around F8, but cannot prove it other than that the React team seems to be speaking there and this comment on twitter https://twitter.com/reactjs/status/573872611853123584
I'm getting pretty excited to start working with React Native either way.
The ES6 class system seems to be done to feel more like java and c# without regard for the mixin/prototype parts. I'm glad React still works with mixins.
(edit spelling and clarification)
1. React source code is licensed under the Modified BSD license.
2. React also comes with a conditional patent grant. Here "conditional" means that the patent grant may terminate under some conditions. It does not terminate 1.
Most BSD and MIT-licensed software you use comes without a patent grant at all.
In spite of being here several times a day, every day, I somehow completely missed this discussion. For anyone else in my situation: https://news.ycombinator.com/item?id=9111849
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.
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.
I'm really excited for `React.cloneElement` and inlining of `React.createElement`! `React.cloneElement` makes a bunch of tricks that used to require hacks much cleaner, and finally promotes cloneWithProps to non-addon API and removes the confusing magic. And if `React.cloneElement` starts getting compiled into object literals it's going to speed up large render calls significantly, and make the overall React API feel a bit simpler (to me).
Wonderful. I love the new ES6 syntax. To continue the discussion of mixins, the 0.13 beta announcement mentioned there are ways to roll own your mixins but can anyone offer examples of how to accomplish this?
How is it a backhanded compliment? The React team is obviously proud of their work, and used it as a point of reference that they believe they can do better than what is there now too.
[+] [-] dmnd|11 years ago|reply
[+] [-] donw|11 years ago|reply
Now all I need to do is sort out some issues with dispatch and I'm good to go...
[+] [-] donw|11 years ago|reply
Of course, the big thing we're all waiting for is Native. If that truly offers a bridge, rather than a wrapper, to native APIs from Javascript, then it will be a game-changer.
[+] [-] spicyj|11 years ago|reply
https://github.com/ericclemmons/react-resolver/issues/8#issu...
(We know people are excited about React Native and we're working hard to get it out the door – keep your eyes peeled!)
[+] [-] acdlite|11 years ago|reply
This is the pattern that the Flux library I wrote uses: https://github.com/acdlite/flummox/blob/master/docs/api/Flux...
I wrote also wrote a bit about why components are generally preferable to mixins: https://github.com/acdlite/flummox/blob/master/docs/why-flux...
[+] [-] funkiee|11 years ago|reply
I'm getting pretty excited to start working with React Native either way.
[+] [-] jbergens|11 years ago|reply
[+] [-] stupidcar|11 years ago|reply
[+] [-] zellyn|11 years ago|reply
[+] [-] olov|11 years ago|reply
There is nothing sad about React PATENTS file.
1. React source code is licensed under the Modified BSD license.
2. React also comes with a conditional patent grant. Here "conditional" means that the patent grant may terminate under some conditions. It does not terminate 1.
Most BSD and MIT-licensed software you use comes without a patent grant at all.
Still sad?
[+] [-] shabbyrobe|11 years ago|reply
[+] [-] loceng|11 years ago|reply
[+] [-] loceng|11 years ago|reply
[+] [-] the_mitsuhiko|11 years ago|reply
[+] [-] spicyj|11 years ago|reply
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.
[+] [-] petrbela|11 years ago|reply
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.
[+] [-] modeless|11 years ago|reply
[+] [-] ariabuckles|11 years ago|reply
[+] [-] tehpwn69|11 years ago|reply
[+] [-] ponytech|11 years ago|reply
[+] [-] ykka|11 years ago|reply
But I also miss it, yeah, very useful addon.
[+] [-] colinramsay|11 years ago|reply
> React.addons.classSet is now deprecated. This functionality can be replaced with several freely available modules. classnames is one such module.
https://www.npmjs.com/package/classnames
[+] [-] jsprogrammer|11 years ago|reply
[+] [-] Bahamut|11 years ago|reply