6 ms·

React v0.14 Beta 1 released

150 points by eminh 11y ago

krat0sprakhar 11y ago
I think this is the crux - > We think the true foundations of React are simply ideas of components and elements: being able to describe what you want to render in a declarative way. These are the pieces shared by all of these different packages (react-native, react-art, react-canvas, react-three). The parts of React specific to certain rendering targets aren't usually what we think of when we think of React. I've not played with React-native yet (waiting for Android) but I feel this is a positive step towards their vision of "learn once, write anywhere". From the twitter updates it seems, Sebestian Markbage, gave a pretty cool talk on the same topic at ReactEurope yesterday. Can't wait to check that out. https://twitter.com/chantastic/status/616679794479112193 https://twitter.com/chantastic/status/616679794479112193 > To make this more clear and to make it easier to build more environments that React can render to, we're splitting the main react package into two: react and react-dom. Great to see the react team responding positively to the developments in community and not being afraid to take hard decisions (like this one) Lastly, if you're a web developer and deciding between going the 'web components' route or the React route, this announcement gives you, IMHO, an even more impetus to pick up React.
andy_ppp 11y ago
I am using React and am very happy with it, however I worry about upgrading because of the interdependencies as well as how fast everything is moving in this space... Does anyone know when we'll be able to have a 1.0 release that we can assume stable for a few months and that react-xxx authors can make sure their modules are stable against. Presumably the react/react-dom breaks all current third party packages for now?
- colinramsay 11y ago
  Shouldn't do: This release includes the old methods in the react package with a deprecation warning, but they'll be removed completely in 0.15
- huskyr 11y ago
  a 1.0 release that we can assume stable for a few months Am i the only one getting a bit cynical that we're now hoping that a 1.0 is stable enough 'for a few months'?
- spicyj 11y ago
  These changes require a little work on your part with each release, but we think they make React better overall – the alternative would be to stop improving React, which I think is worse. We're already trying to get to a long-lived release as fast as we can, especially given our commitment to support each change with a warning for an entire release to give people a chance to update their code. One of our goals with this release is actually to help with the problem you mention of interdependencies and component versioning: we expect most components to only depend on the "react" package, which will be more stable and updated less frequently. Thankfully the React community moves fast and package authors are usually quick to update to new React versions. P.S. We've been making releases every 6 months or so, so we're already at "stable for a few months". We might speed this up a little but we never want the pace to be unmanageable. (The four of us on the core team need to make sure the 10,000 components in the Facebook codebase continue to work, so I assure you we don't take breaking changes lightly.)
  - andy_ppp 11y ago
    Fantastic, that's reassuring to know. Given this I'll bite the bullet and move to 0.14 beta seeing as my app isn't publically available yet. Thanks so much for React - it really is an amazing way to work and moving to it has simplified the extremely complex and interactive app I'm building!
- jscheel 11y ago
  It was this way with Backbone a few years ago. Give it time, it will calm down eventually. Breaking changes are often necessary to get a project where it really needs to be.
smhg 11y ago
tl;dr React (core) is evolving into a kind of component spec. Sounds good! If not already, react-dom will probably be easily replaceable by modules like virtual-dom?
danmaz74 11y ago
We're considering trying react for a new project, and just read about the adoption of Babel [1] instead of the internal transpiler previously used for JSX. One question: does this mean that JSX will be able to use ES6 syntax supported by Babel out of the box? If so, will this be the default for this new version of React? I ask the questions also because we would really like to be able to use React with CoffeeScript, but, even if there are many solutions to do so, no one is supported by Facebook and we're worried about future compatibility. Is adopting Babel going to influence the ability to use React with CS? [1] https://facebook.github.io/react/blog/2015/06/12/deprecating-jstransform-and-react-tools.html https://facebook.github.io/react/blog/2015/06/12/deprecating...
- baddox 11y ago
  React's deprecation of JSTransform means that you will (whenever they completely remove it) need to actually use Babel to build your React JavaScript.
- iamflimflam1 11y ago
  I've been using babel instead of the internal transpiler and yes you can use all the ES6 syntax out of the box. I think the JSX transpiler was deprecated some time ago and pretty much all the react starter templates and examples have been using Babel. I don't think adopting babel is going to compromise your use of coffeescript, in then babel is just transpiling down to old style javascript.
  - danmaz74 11y ago
    So you were using babel with a JSX module? Did they just make the JSX module the default? Sorry but I know babel only by name yet!
- spicyj 11y ago
  You don't need to use Babel, though we do recommend it. We're just no longer going to maintain our own JSX transformer since there's no point. (If you want just Babel's JSX transformation without any other features, that's possible too.) There's a CoffeeScript JSX transformer here if you're interested: https://github.com/jsdf/coffee-react https://github.com/jsdf/coffee-react and we'll continue to support using React without JSX, and though we use Babel now internally, we compile React itself to ES5 before putting it on npm so you don't need to use Babel if you don't want to.
aleem 11y ago
If you haven't already, you should be betting on React. It's the future: > More importantly, this paves the way to writing components that can be shared between the web version of React and React Native. This isn't yet easily possible, but we intend to make this easy in a future version so you can share React code between your website and native apps. Isn't this what we have all been waiting for? Writing components that are composable, that are "isomorphic or universal", that can run on Native or DOM without any downsides of it's predecessors. Aside, the article also mentions a migration tool [1] to help you port your code from 0.13 to 0.14. While others may have done so before, it's pretty cool that this is streamlined as part of the beta release. [1]: https://www.npmjs.com/package/react-codemod https://www.npmjs.com/package/react-codemod
- realusername 11y ago
  Sure, it's the future but currently it's still quite far away, React Native is available only for iOS (and in a quite beta state) and the components are not fully sharable between both of them yet. But yes, I agree, I can't wait for this !
  - iofj 11y ago
    It's the javascript future. How long will it last, really ?
- elorant 11y ago
  Cross platform tools always make compromises. I’d rather write native code than have a framework that does it for me.
  - skinnyfoetusboy 11y ago
    Well, that is the point actually. React doesn't put itself as a "write once, run everywhere" kind of solution. What's being offered here is better interoperability between native and web components. The core philosophy is still "learn once, write everywhere".
  - matthewmacleod 11y ago
skrebbel 11y ago
we looked at what you can do with a ref to a DOM component and realized that the only useful thing you can do with it is call this.refs.giraffe.getDOMNode() to get the underlying DOM node. In this release, this.refs.giraffe is the actual DOM node. This only holds if you use Facebook's particular flavour of Flux, I guess. Personally, I use refs a lot to bubble events down the component hierarchy. For example, when the browser window loses focus and gains it again, some sub sub component of the root component might want to do set some local state. Whatever, display a "welcome back!" message or something. I can use refs to do this.refs.subcomponent.onWindowShow() and this makes my code very clean and flexible - it keeps browser event stuff out of my flux stores, and only the actual important user data in there. Similarly, I use refs to ask an <Input> component whether its value is valid according to some validation rule. I could also give the Input an onValueValidityChanged prop, but that just increases the amount of bookkeeping I need to do. If I'm rendering a form with 2 inputs, name and email, calling "this.refs.name.isValid()" in some onButtonClick handler makes a lot of sense to me. I really liked how React was separated from particular architecture patterns, but this change makes that a lot more difficult. I really hope this change can still be reversed.
- matthewmacleod 11y ago
  Personally, I use refs a lot to bubble events down the component hierarchy. For example, when the browser window loses focus and gains it again, some sub sub component of the root component might want to do set some local state. Whatever, display a "welcome back!" message or something Isn't that a bit of an antipattern? It seems that sending events down the hierarchy is something that React goes out of its way to make awkward, and on purpose. In the case you've given, I'm not clear why you wouldn't just bind to the window's focus and blur events from within componentWillMount, anyway.
  - skrebbel 11y ago
    I'm not sure that it is an antipattern. Personally, I feel that attaching event handlers to global window events from all over the place is just as bad, basically a singleton in disguise. Another use case that I came across was where we wanted a search dropdown to open in the header when a user clicked somewhere in the middle of the page content. One option would be to make a PageStateStore and add an isSearchDropdownVisible to it, but I don't like doing flux that way because I don't want UI details to be part of my model later. I think having isVisible in the SearchDropdown state is much more elegant, but that poses the slight problem of how to change that state from the other side of the page. We did that by having the item in the page have an onWantToSearch event, which the page had a handler for that invoked this.refs.header.showSearch(), which in turn invoked this.refs.searchDropdown.setVisible(true), which did a simple this.setState({isVisible: true}). So, in general, the event first bubbles all up the tree (through custom react onSomething, onSomethingElse props), and then bubbles down the tree (through method calls on refs). This exposes a really elegant design, because it made the Header component be "a thing that allows searching" (because it has a showSearch() method), and the page item an "a thing that allows a user to initiate a search action" (because it has a onWantToSearch event). The available methods and onSomething props of all components perfectly matched the possible behaviors of the components, and no behaviour is "hidden" inside a singleton mesh of flux stores.
joesb 11y ago
Aren't these two changes in conflict with each other? One change remove assumption about DOM as rendered target, while another change means DOM must be the rendered target. Requiring ReacDOM.findDOMNode(ref) should be what they do if they want to encourage multiple rendering target.
- spicyj 11y ago
  If you use a ref to a DOM component, you don't need ReactDOM.findDOMNode at all. Calling findDOMNode on a composite drills through abstraction boundaries and breaks encapsulation, so it's rarely what you should do. The removal of .getDOMNode() was intentionally done in concert with this change: previously, all component classes created with React would magically have that DOM-specific method added to them; this way, component classes are less tied to specific rendering environments. If you need to call ReactDOM.findDOMNode then yes, your components will be tied to the ReactDOM renderer.
hartator 11y ago
I am using/loving React a lot and is already in several production apps I am working on (thanks for awesome work Facebook!) but I don't fully get this release. I feel it's a bit premature to separate `react` and `react-dom`. React has proven itself for the web but still has to prove itself as `react-native` and I don't get the friction/complexity being added by break it down into two components for the web. I feel React is more the rendering engine `react-dom` than the class/component system now `react`. What makes React beautiful is to be able to freely mix html into JS and not being limited to the render() call, so I feel the cut is a bit non-organic. Finally, I love the approach `learn once, write anywhere` but having `react` as a thing by itself points (or at least confuses) to a workflow where you can write components by themselves then plug a rendering engine DOM or native, I don't think that's the initial intent and I don't think that's the intent now of this release as well but it's unnecessary confusing. [Edit] Don't fully get why I've been downvoted.
- grandalf 11y ago
  Chances are this clear separation will allow the various teams to submit patches to React without having to worry about time synchronizing with the release of the stuff that is in ReactDOM ... at least once it stabilizes a bit.
aaronjgreenberg 11y ago
It'll be cool to see a WebAssembly implementation of react-dom.
ericclemmons 11y ago
I'm extremely excited about this release because of the change to context from Owner-based to Parent-based. Authoring react-resolver meant jumping through weird hoops to avoid context changing, but this release should mean things will work as expected, rather than having to sort out "gotchas". There goes my July 4th weekend :)
- insin 11y ago
  I'm looking forward to the context change the most too, it makes the feature work the way I've intuitively thought it would/should work when trying to design for it in the past. It's going to be a boon for libraries which use DSL-like ancestor components.
d0m 11y ago
About the refs, I've been using a small helper: h.ref(this, 'some-element.children-element'); and its companion h.$ref(this, 'some-element.children..'); for the jquery version. I don't have a strict rule of when using it, but sometimes it's cleaner than having lots of nested callback on an inner children.. I.e. I can just do: h.$ref(this, 'header.search.input').. Which basically transforms to this.refs.header.refs.search.refs.input (IIRC)
- spicyj 11y ago
  I wouldn't encourage doing that because it breaks encapsulation of your children. Like state, you shouldn't peer into another component's refs. But that should continue to work fine.
  - d0m 11y ago
    I think it's fine when the parent and children are really tied together. I wouldn't use that from the main component to a really nested children for instance. Let's say you have a "SearchComponent" with a "SearchButtonComponent" and "SearchInputComponent", I'm okay with using the strategy I suggested because using "SearchInputComponent" without its parent somewhere else in the code would be too risky so the encapsulation is still kept between parent/children.
- modarts 11y ago
  This doesn't sound like a good idea and seems to defeat the purpose of componentization in the first place.

150 points by eminh 11y ago

I think this is the crux - > We think the true foundations of React are simply ideas of components and elements: being able to describe what you want to render in a declarative way. These are the pieces shared by all of these different packages (react-native, react-art, react-canvas, react-three). The parts of React specific to certain rendering targets aren't usually what we think of when we think of React. I've not played with React-native yet (waiting for Android) but I feel this is a positive step towards their vision of "learn once, write anywhere". From the twitter updates it seems, Sebestian Markbage, gave a pretty cool talk on the same topic at ReactEurope yesterday. Can't wait to check that out. https://twitter.com/chantastic/status/616679794479112193 https://twitter.com/chantastic/status/616679794479112193 > To make this more clear and to make it easier to build more environments that React can render to, we're splitting the main react package into two: react and react-dom. Great to see the react team responding positively to the developments in community and not being afraid to take hard decisions (like this one) Lastly, if you're a web developer and deciding between going the 'web components' route or the React route, this announcement gives you, IMHO, an even more impetus to pick up React.

andy_ppp 11y ago

I am using React and am very happy with it, however I worry about upgrading because of the interdependencies as well as how fast everything is moving in this space... Does anyone know when we'll be able to have a 1.0 release that we can assume stable for a few months and that react-xxx authors can make sure their modules are stable against. Presumably the react/react-dom breaks all current third party packages for now?

colinramsay 11y ago
Shouldn't do: This release includes the old methods in the react package with a deprecation warning, but they'll be removed completely in 0.15
huskyr 11y ago
a 1.0 release that we can assume stable for a few months Am i the only one getting a bit cynical that we're now hoping that a 1.0 is stable enough 'for a few months'?
spicyj 11y ago
These changes require a little work on your part with each release, but we think they make React better overall – the alternative would be to stop improving React, which I think is worse. We're already trying to get to a long-lived release as fast as we can, especially given our commitment to support each change with a warning for an entire release to give people a chance to update their code. One of our goals with this release is actually to help with the problem you mention of interdependencies and component versioning: we expect most components to only depend on the "react" package, which will be more stable and updated less frequently. Thankfully the React community moves fast and package authors are usually quick to update to new React versions. P.S. We've been making releases every 6 months or so, so we're already at "stable for a few months". We might speed this up a little but we never want the pace to be unmanageable. (The four of us on the core team need to make sure the 10,000 components in the Facebook codebase continue to work, so I assure you we don't take breaking changes lightly.)
- andy_ppp 11y ago
  Fantastic, that's reassuring to know. Given this I'll bite the bullet and move to 0.14 beta seeing as my app isn't publically available yet. Thanks so much for React - it really is an amazing way to work and moving to it has simplified the extremely complex and interactive app I'm building!
jscheel 11y ago
It was this way with Backbone a few years ago. Give it time, it will calm down eventually. Breaking changes are often necessary to get a project where it really needs to be.

smhg 11y ago

tl;dr React (core) is evolving into a kind of component spec. Sounds good! If not already, react-dom will probably be easily replaceable by modules like virtual-dom?

danmaz74 11y ago

We're considering trying react for a new project, and just read about the adoption of Babel [1] instead of the internal transpiler previously used for JSX. One question: does this mean that JSX will be able to use ES6 syntax supported by Babel out of the box? If so, will this be the default for this new version of React? I ask the questions also because we would really like to be able to use React with CoffeeScript, but, even if there are many solutions to do so, no one is supported by Facebook and we're worried about future compatibility. Is adopting Babel going to influence the ability to use React with CS? [1] https://facebook.github.io/react/blog/2015/06/12/deprecating-jstransform-and-react-tools.html https://facebook.github.io/react/blog/2015/06/12/deprecating...

baddox 11y ago
React's deprecation of JSTransform means that you will (whenever they completely remove it) need to actually use Babel to build your React JavaScript.
iamflimflam1 11y ago
I've been using babel instead of the internal transpiler and yes you can use all the ES6 syntax out of the box. I think the JSX transpiler was deprecated some time ago and pretty much all the react starter templates and examples have been using Babel. I don't think adopting babel is going to compromise your use of coffeescript, in then babel is just transpiling down to old style javascript.
- danmaz74 11y ago
  So you were using babel with a JSX module? Did they just make the JSX module the default? Sorry but I know babel only by name yet!
spicyj 11y ago
You don't need to use Babel, though we do recommend it. We're just no longer going to maintain our own JSX transformer since there's no point. (If you want just Babel's JSX transformation without any other features, that's possible too.) There's a CoffeeScript JSX transformer here if you're interested: https://github.com/jsdf/coffee-react https://github.com/jsdf/coffee-react and we'll continue to support using React without JSX, and though we use Babel now internally, we compile React itself to ES5 before putting it on npm so you don't need to use Babel if you don't want to.

aleem 11y ago

If you haven't already, you should be betting on React. It's the future: > More importantly, this paves the way to writing components that can be shared between the web version of React and React Native. This isn't yet easily possible, but we intend to make this easy in a future version so you can share React code between your website and native apps. Isn't this what we have all been waiting for? Writing components that are composable, that are "isomorphic or universal", that can run on Native or DOM without any downsides of it's predecessors. Aside, the article also mentions a migration tool [1] to help you port your code from 0.13 to 0.14. While others may have done so before, it's pretty cool that this is streamlined as part of the beta release. [1]: https://www.npmjs.com/package/react-codemod https://www.npmjs.com/package/react-codemod

realusername 11y ago
Sure, it's the future but currently it's still quite far away, React Native is available only for iOS (and in a quite beta state) and the components are not fully sharable between both of them yet. But yes, I agree, I can't wait for this !
- iofj 11y ago
  It's the javascript future. How long will it last, really ?
elorant 11y ago
Cross platform tools always make compromises. I’d rather write native code than have a framework that does it for me.
- skinnyfoetusboy 11y ago
  Well, that is the point actually. React doesn't put itself as a "write once, run everywhere" kind of solution. What's being offered here is better interoperability between native and web components. The core philosophy is still "learn once, write everywhere".
- matthewmacleod 11y ago

skrebbel 11y ago

we looked at what you can do with a ref to a DOM component and realized that the only useful thing you can do with it is call this.refs.giraffe.getDOMNode() to get the underlying DOM node. In this release, this.refs.giraffe is the actual DOM node. This only holds if you use Facebook's particular flavour of Flux, I guess. Personally, I use refs a lot to bubble events down the component hierarchy. For example, when the browser window loses focus and gains it again, some sub sub component of the root component might want to do set some local state. Whatever, display a "welcome back!" message or something. I can use refs to do this.refs.subcomponent.onWindowShow() and this makes my code very clean and flexible - it keeps browser event stuff out of my flux stores, and only the actual important user data in there. Similarly, I use refs to ask an <Input> component whether its value is valid according to some validation rule. I could also give the Input an onValueValidityChanged prop, but that just increases the amount of bookkeeping I need to do. If I'm rendering a form with 2 inputs, name and email, calling "this.refs.name.isValid()" in some onButtonClick handler makes a lot of sense to me. I really liked how React was separated from particular architecture patterns, but this change makes that a lot more difficult. I really hope this change can still be reversed.

matthewmacleod 11y ago
Personally, I use refs a lot to bubble events down the component hierarchy. For example, when the browser window loses focus and gains it again, some sub sub component of the root component might want to do set some local state. Whatever, display a "welcome back!" message or something Isn't that a bit of an antipattern? It seems that sending events down the hierarchy is something that React goes out of its way to make awkward, and on purpose. In the case you've given, I'm not clear why you wouldn't just bind to the window's focus and blur events from within componentWillMount, anyway.
- skrebbel 11y ago
  I'm not sure that it is an antipattern. Personally, I feel that attaching event handlers to global window events from all over the place is just as bad, basically a singleton in disguise. Another use case that I came across was where we wanted a search dropdown to open in the header when a user clicked somewhere in the middle of the page content. One option would be to make a PageStateStore and add an isSearchDropdownVisible to it, but I don't like doing flux that way because I don't want UI details to be part of my model later. I think having isVisible in the SearchDropdown state is much more elegant, but that poses the slight problem of how to change that state from the other side of the page. We did that by having the item in the page have an onWantToSearch event, which the page had a handler for that invoked this.refs.header.showSearch(), which in turn invoked this.refs.searchDropdown.setVisible(true), which did a simple this.setState({isVisible: true}). So, in general, the event first bubbles all up the tree (through custom react onSomething, onSomethingElse props), and then bubbles down the tree (through method calls on refs). This exposes a really elegant design, because it made the Header component be "a thing that allows searching" (because it has a showSearch() method), and the page item an "a thing that allows a user to initiate a search action" (because it has a onWantToSearch event). The available methods and onSomething props of all components perfectly matched the possible behaviors of the components, and no behaviour is "hidden" inside a singleton mesh of flux stores.

joesb 11y ago

Aren't these two changes in conflict with each other? One change remove assumption about DOM as rendered target, while another change means DOM must be the rendered target. Requiring ReacDOM.findDOMNode(ref) should be what they do if they want to encourage multiple rendering target.

spicyj 11y ago
If you use a ref to a DOM component, you don't need ReactDOM.findDOMNode at all. Calling findDOMNode on a composite drills through abstraction boundaries and breaks encapsulation, so it's rarely what you should do. The removal of .getDOMNode() was intentionally done in concert with this change: previously, all component classes created with React would magically have that DOM-specific method added to them; this way, component classes are less tied to specific rendering environments. If you need to call ReactDOM.findDOMNode then yes, your components will be tied to the ReactDOM renderer.

hartator 11y ago

I am using/loving React a lot and is already in several production apps I am working on (thanks for awesome work Facebook!) but I don't fully get this release. I feel it's a bit premature to separate `react` and `react-dom`. React has proven itself for the web but still has to prove itself as `react-native` and I don't get the friction/complexity being added by break it down into two components for the web. I feel React is more the rendering engine `react-dom` than the class/component system now `react`. What makes React beautiful is to be able to freely mix html into JS and not being limited to the render() call, so I feel the cut is a bit non-organic. Finally, I love the approach `learn once, write anywhere` but having `react` as a thing by itself points (or at least confuses) to a workflow where you can write components by themselves then plug a rendering engine DOM or native, I don't think that's the initial intent and I don't think that's the intent now of this release as well but it's unnecessary confusing. [Edit] Don't fully get why I've been downvoted.

grandalf 11y ago
Chances are this clear separation will allow the various teams to submit patches to React without having to worry about time synchronizing with the release of the stuff that is in ReactDOM ... at least once it stabilizes a bit.

aaronjgreenberg 11y ago

It'll be cool to see a WebAssembly implementation of react-dom.

ericclemmons 11y ago

I'm extremely excited about this release because of the change to context from Owner-based to Parent-based. Authoring react-resolver meant jumping through weird hoops to avoid context changing, but this release should mean things will work as expected, rather than having to sort out "gotchas". There goes my July 4th weekend :)

insin 11y ago
I'm looking forward to the context change the most too, it makes the feature work the way I've intuitively thought it would/should work when trying to design for it in the past. It's going to be a boon for libraries which use DSL-like ancestor components.

d0m 11y ago

About the refs, I've been using a small helper: h.ref(this, 'some-element.children-element'); and its companion h.$ref(this, 'some-element.children..'); for the jquery version. I don't have a strict rule of when using it, but sometimes it's cleaner than having lots of nested callback on an inner children.. I.e. I can just do: h.$ref(this, 'header.search.input').. Which basically transforms to this.refs.header.refs.search.refs.input (IIRC)

spicyj 11y ago
I wouldn't encourage doing that because it breaks encapsulation of your children. Like state, you shouldn't peer into another component's refs. But that should continue to work fine.
- d0m 11y ago
  I think it's fine when the parent and children are really tied together. I wouldn't use that from the main component to a really nested children for instance. Let's say you have a "SearchComponent" with a "SearchButtonComponent" and "SearchInputComponent", I'm okay with using the strategy I suggested because using "SearchInputComponent" without its parent somewhere else in the code would be too risky so the encapsulation is still kept between parent/children.
modarts 11y ago
This doesn't sound like a good idea and seems to defeat the purpose of componentization in the first place.