8 ms·

React v0.13 released

207 points by tilt 12y ago

the_mitsuhiko 12y ago
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.
donw 12y ago
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.
- spicyj 12y ago
  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-relay-and-graphql.html 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: https://github.com/ericclemmons/react-resolver/issues/8#issuecomment-77765843 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 12y ago
  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. This is the pattern that the Flux library I wrote uses: https://github.com/acdlite/flummox/blob/master/docs/api/FluxComponent.md 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-component-is-better-than-flux-mixin.md https://github.com/acdlite/flummox/blob/master/docs/why-flux...
- funkiee 12y ago
  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 https://twitter.com/reactjs/status/573872611853123584 I'm getting pretty excited to start working with React Native either way.
jbergens 12y ago
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)
- stupidcar 12y ago
  The ES6 class system is literally just syntactic sugar for prototypal inheritance.
  - TazeTSchnitzel 12y ago
    No, it's syntactic sugar for one particular approach to using prototypical inheritance that resembles "traditional" OOP.
    - bloodyowl 12y ago
      no, it's just syntactic sugar
    - Touche 12y ago
      Can you explain? It's sugar for this very common pattern: function Bar() { Foo.call(this); } Bar.prototype = Object.create(Foo.prototype); Bar.prototype.constructor = Bar; Foo.prototype.thing = function() { .... What other "approach" to prototypical inheritance is there in JavaScript? The module pattern doesn't use prototypes.
      - backslash_16 12y ago
        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.
        12y ago
zellyn 12y ago
Sadly, the much-discussed explosive second half of the PATENTS file is still present: https://github.com/facebook/react/blob/91b45641b8bfbdecace941125a7a415aad1ebbce/PATENTS https://github.com/facebook/react/blob/91b45641b8bfbdecace94...
- shabbyrobe 12y ago
  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 https://news.ycombinator.com/item?id=9111849
- loceng 12y ago
  Link to previous discussion(s)? Having a difficult time understanding it in layman's terms.
- loceng 12y ago
  Is it possible for another company to create something like React?
  - mateuszf 12y ago
    Yes.
  - malandrew 12y ago
    Why a company: https://github.com/Raynos/mercury https://github.com/Raynos/mercury 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.
- olov 12y ago
  "much-discussed" by "less-informed" I'd say. 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?
ariabuckles 12y ago
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).
dmnd 12y ago
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 https://github.com/facebook/react/pull/2376)
- donw 12y ago
  Oh god, this. Using Immutable (via Immstruct) has been glorious, but this has been a minor annoyance that I'll be glad to be rid of. Now all I need to do is sort out some issues with dispatch and I'm good to go...
  - amccloud 12y ago
    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.
    - donw 12y ago
      It does, but you can just .deref()
      - amccloud 12y ago
        I'm usually looping over cursors I want to pass as a prop to a child component. Deref-ing there would sorta defeat the purpose of cursors.
        donw 12y ago
        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.
jsprogrammer 12y ago
Why is the second paragraph a shout-out backhand compliment to Ember and Angular?
- Bahamut 12y ago
  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.
  - catshirt 12y ago
    the compliment is that the other frameworks are improving their rendering speeds. the backhanded part is it implies they're slow.
    - Skinney 12y ago
      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.
      - catshirt 12y ago
        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.
        Bahamut 12y ago
        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.
modeless 12y ago
Any news about React Native?
tehpwn69 12y ago
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?
ponytech 12y ago
Any idea why React.addons.classSet is now deprecated? It was really helpful.
- ykka 12y ago
  Not sure but it's very easy to implement it yourself... Check this https://github.com/facebook/react/blob/2aeb8a2a6beb00617a4217f7f8284924fa2ad819/src/utils/joinClasses.js https://github.com/facebook/react/blob/2aeb8a2a6beb00617a421... But I also miss it, yeah, very useful addon.
- colinramsay 12y ago
  From the release notes: > 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 https://www.npmjs.com/package/classnames

207 points by tilt 12y ago

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.

donw 12y ago

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.

spicyj 12y ago
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-relay-and-graphql.html 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: https://github.com/ericclemmons/react-resolver/issues/8#issuecomment-77765843 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 12y ago
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. This is the pattern that the Flux library I wrote uses: https://github.com/acdlite/flummox/blob/master/docs/api/FluxComponent.md 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-component-is-better-than-flux-mixin.md https://github.com/acdlite/flummox/blob/master/docs/why-flux...
funkiee 12y ago
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 https://twitter.com/reactjs/status/573872611853123584 I'm getting pretty excited to start working with React Native either way.

jbergens 12y ago

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)

stupidcar 12y ago
The ES6 class system is literally just syntactic sugar for prototypal inheritance.
- TazeTSchnitzel 12y ago
  No, it's syntactic sugar for one particular approach to using prototypical inheritance that resembles "traditional" OOP.
  - bloodyowl 12y ago
    no, it's just syntactic sugar
  - Touche 12y ago
    Can you explain? It's sugar for this very common pattern: function Bar() { Foo.call(this); } Bar.prototype = Object.create(Foo.prototype); Bar.prototype.constructor = Bar; Foo.prototype.thing = function() { .... What other "approach" to prototypical inheritance is there in JavaScript? The module pattern doesn't use prototypes.
    - backslash_16 12y ago
      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.
      - 12y ago

zellyn 12y ago

Sadly, the much-discussed explosive second half of the PATENTS file is still present: https://github.com/facebook/react/blob/91b45641b8bfbdecace941125a7a415aad1ebbce/PATENTS https://github.com/facebook/react/blob/91b45641b8bfbdecace94...

shabbyrobe 12y ago
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 https://news.ycombinator.com/item?id=9111849
loceng 12y ago
Link to previous discussion(s)? Having a difficult time understanding it in layman's terms.
loceng 12y ago
Is it possible for another company to create something like React?
- mateuszf 12y ago
  Yes.
- malandrew 12y ago
  Why a company: https://github.com/Raynos/mercury https://github.com/Raynos/mercury 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.
olov 12y ago
"much-discussed" by "less-informed" I'd say. 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?

ariabuckles 12y ago

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).

dmnd 12y ago

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 https://github.com/facebook/react/pull/2376)

donw 12y ago
Oh god, this. Using Immutable (via Immstruct) has been glorious, but this has been a minor annoyance that I'll be glad to be rid of. Now all I need to do is sort out some issues with dispatch and I'm good to go...
- amccloud 12y ago
  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.
  - donw 12y ago
    It does, but you can just .deref()
    - amccloud 12y ago
      I'm usually looping over cursors I want to pass as a prop to a child component. Deref-ing there would sorta defeat the purpose of cursors.
      - donw 12y ago
        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.

jsprogrammer 12y ago

Why is the second paragraph a shout-out backhand compliment to Ember and Angular?

Bahamut 12y ago
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.
- catshirt 12y ago
  the compliment is that the other frameworks are improving their rendering speeds. the backhanded part is it implies they're slow.
  - Skinney 12y ago
    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.
    - catshirt 12y ago
      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.
      - Bahamut 12y ago
        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.

modeless 12y ago

Any news about React Native?

tehpwn69 12y ago

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?

ponytech 12y ago

Any idea why React.addons.classSet is now deprecated? It was really helpful.

ykka 12y ago
Not sure but it's very easy to implement it yourself... Check this https://github.com/facebook/react/blob/2aeb8a2a6beb00617a4217f7f8284924fa2ad819/src/utils/joinClasses.js https://github.com/facebook/react/blob/2aeb8a2a6beb00617a421... But I also miss it, yeah, very useful addon.
colinramsay 12y ago
From the release notes: > 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 https://www.npmjs.com/package/classnames