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)
Does Immstruct use Immutable's cursors? If so, you'll still need to use .toArray() when dealing with a cursor to an array. React doesn't like what you get after mapping over an IndexedCursor.
Ah, fair enough. I usually deref before handing the data off to the rendering chain, on the basis that future updates will just kick off another render loop.
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)
Is there a good book or website to learn about prototypical inheritance? I've read a lot of Crockford's book and some stuff online about it, but I've never run across the pattern you use above.
It would be great to know what the benefits are vs declaring function literals on an object, or declaring a function directly on Bar's prototype.
Which is ultimately what separates a good language from a bad language. A good language should have ONE best way to do things. With the prototypical inheritance, there are impossible numbers of way to declare/define and inherit a class in JavaScript. That is just a trap for bugs and defects. How could you effectively understand what the code does when you can't read it in one glance? Especially code that is not yours.
Actually it might be easier to screw up. People will think these are real traditional "OO" classes but they are not. Its all prototypal, and you will be in a world of hurt creating bug and performance hits if you treat them as if they are the same. Also, functions inside a ES6 class are hijacked. You cannot bind those functions to work on another context which is a core javascript technique, it will break. Thus in the end, any person familiar with javascript will have to learn even more caveats which will create more confusion. You wouldnt want to use ES6 classes on anything super complex.
it reduces the necessary LoC and forces you to only define methods in the [[Proto]] land. ES7 will let you define properties in it, but it will effectively be as if you defined them in the constructor.
no, it introduces a "super" semantic with late binding ,something you can't do in ES5. So it isn't just syntactic sugar. Furthermore it may evolve in later versions of ES to something even more complicated with access modifiers and things like that.
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.
Thanks - I somehow managed not to look at that (saw it now after Twitter feedback). I can't edit my earlier comments so I'll just amend here instead: There are open source lawyers who consider simple permissive licenses such as Modified BSD and MIT to have an implicit patent grant. The first public discussion I found on this after a quick search is at http://lwn.net/Articles/389016/ - would love to see more and earlier.
If you the licensee also consider Modified BSD to have an implicit patent grant then the React patent grant is much worse for you than if it hadn't existed.
Now, I don't know what makes things "better" for you but from the perspective of most licensees it is probably legally better to have a conditional patent grant than none at all, most of the time. But it will vary depending on, for example, the licensors (their) and licensees (your) patent portfolios and intention to enforce those aggressively as well as your strategies of defense. There's a huge difference between a company such as, say Oracle and Facebook, here.
Granting patents in the context of permissively licensed open source is a generous act and making the grant conditional is a way of not giving up your ability to form the strongest possible defense when you're brought into patent litigation. If you have been following along the recent years events (where is that patent apocalypse, anyone?) then it should be no surprise why companies need to do that.
None of the patent grants you mentioned are as one-sided as Facebook's. My problem is not with a conditional patent grant. My problem is with Facebook preventing React users from defending themselves against lawsuits for unrelated patents.
Apache, GPL, MPL, etc. have retaliation clauses that terminate your patent license only if you sue (or in some cases, countersue) in relation to the covered software. Facebook's patent grant says you can never sue Facebook, while being vulnerable to being sued by Facebook for anything but React.
Thanks for being specific. I agree that Facebook's termination clause is crafted to benefit Facebook more than should they have used similar language to Google's (or APL2.0). A less defensive patent grant would have been more generous.
But I'm not sure I agree with your conclusion though.
Scenario one: MYCOMP uses React in a product, decides to sue FB because FB uses the term "It's complicated" which MYCOMP was granted a patent for by the US patent office (the phrase was translated into a dual-ROT13-machine for the purpose of the patent application). MYCOMP had tried to get FB to pay them a reasonable license fee prior to suing but Facebook neglected. Now MYCOMP does not have a patent grant for their use of React any longer but isn't that then ~similar to as if React didn't have any patent grant to begin with (from a litigation perspective) - like most MIT and BSD licensed software we use? Had I been with BIGCORP I'd have asked the legal folks or our favorite patent attorney but now I'm solo so I'm throwing out the question here for further discussion.
Scenario two: FB sues UCOMP (who uses React in one of their products) for patent infringement of FB's "Send message from client to server" patent (nicely masqueraded in the patent application). UCOMP decides to counter-sue and we have a situation similar to scenario one.
When FB gives you a patent grant, it implies they have patents they could sue people over. An MIT or BSD copyright license alone could mean there are no patents to grant.
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
All react best practices converge on what mercury has done out of the box since day one. React's advantage is it's community. There are more docs, examples and tutorials.
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.
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.
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.
They're just acknowledging that everything is moving forwards, I imagine that they're pleased to have influenced the other frameworks. Ember in particular seem to have learned a lot from React and are adopting a virtual-DOM approach to rendering.
Considering React says that there are things they can do to improve React even more, suggested to me that React is currently as fast or slower than those other frameworks, but React can once again become faster than them.
i can't be sure about Angular but they directly reference Ember, who published recently that they are improving their (notoriously slow) render times by moving to a virtual DOM model like React.
what they're actually saying is, React is getting even faster while other frameworks try are playing catch-up.
Angular has improved performance 30% from 1.2 to 1.3, and is slated to improve it another 30% from 1.3 to 1.4 (1.4 has a release candidate currently) - that is one of many reveals from ng-conf. Angular 2 has been revealed earlier that it is 5-10x as fast as Angular 1.x (depending on the task), which probably makes it notably faster than React.
Performance is still something that every framework is striving to optimize - this is only a good thing when teams announce that they are working to improve their performance, mobile is still hard with the DOM.
Each of the frameworks draw positive influences from each other, and don't hesitate to give each other credit - the React team praised the idea behind ng-animate for programmatic CSS transitions, the Angular team directly drew from React for the idea of unidirectional flow for Angular 2 and built on top of Ember's route-recognizer for the new router.
