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.
I would say that React is the present but that the future is a circle back to progressive enhancement. I'm seeing more high-profile JS developers jumping off the front-end framework bandwagon and back towards progressively enhancing existing HTML. I think we're going to see frameworks emerge which make progressive enhancement the priority and make it easier. So the whole JS templating engine race that has been going on for the last few years will simply not be important any more.
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 !
If you haven't already, you should be betting on React. It's the future
But last week the future was AngularJS, and the week before that it was Ember or Backbone or Knockout, and a few days earlier it was jQuery. Next week it will be Angular 2.0, maybe, or something with Web Components, and the week after that we're all abandoning JS in favour of some declarative functional language that hasn't been written yet but will be on TodoMVC tomorrow.
Seriously, this is a beta of a pre-release package. The article mentions, as motivation for the major architectural change, some other react-something packages, and literally in the opening section of their README.md they say things like "This project is a work-in-progress. Though much of the code is in production on flipboard.com, the React canvas bindings are relatively new and the API is subject to change."
By all means let's experiment with newer and potentially better ways to build sites and apps, but betting heavily on an ecosystem this immature for a long-term professional project seems like asking for trouble.
Isn't this what we have all been waiting for?
It's certainly not something I've been waiting for, as someone who works in the relevant fields. Rather like "isomorphic" libraries, I feel combined web/native generation is mostly a solution in search of a problem. No doubt a few people really do have that problem, but I'm guessing that for most day-to-day work in the real world this theoretical flexibility adds little practical value. There's no particular reason the same tools should be good choices for writing both web and native apps, any more than we should expect the same tools to necessarily be good choices for writing both server-side and client-side code in a web app.
In this particular case, I'm more concerned by the change in emphasis than the technical changes. To me, the big advantage of React over most other front-end libraries and frameworks is the efficient DOM updating, which in turn makes this kind of component model viable with acceptable performance where various other UI libraries/frameworks have struggled in the past. However, it looks like the React team think that is a secondary benefit and the real advantage is using components.
I can already build a complicated web app rendering layer using the same modular design skills I've spent the last 30 years learning in other programming contexts. After all, that's what I did before we had the modern generation of template/component driven frameworks, when we had to update the DOM manually using plain JS or libraries like jQuery. So did plenty of other people. Maybe I'm missing something, but while React might be a sensible enough choice for part of the UI rendering work, I don't see why it has anything unique or special to offer compared to many other libraries here.
If the React team focussed on the efficient DOM updates, flexible but reasonably simple component model, and then stability so the community could develop the ecosystem around a solid foundation, I could see it becoming a good choice for projects that can't afford to have their dependencies constantly shifting around and the maintenance overheads that incurs. But this separation and increased emphasis on react-native and the like feels like it's leaving behind the very things that made React attractive in a very crowded field of JS UI libraries.
> 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
> 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.
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.
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.
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.
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.
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?
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:
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.
It's not about the HTML-like JSX part using ES6 or using native classes to extend React.component(with limitations), but simpler object literals, fat arrows and { foo: foo } becoming { foo } make React code look much better. I can endure the ending semicolons, parens and brackets.
Now you don't really gain too much by opting for CS over ES6 for React. And with React's adoption of Babel I think ES6 is going to become the primary way of writing React apps.
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.
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".
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.
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?
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.)
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.
aleem|10 years ago
> 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
beefsack|10 years ago
I've heard that too many times to not be cynical about it.
tambourine_man|10 years ago
http://blog.circleci.com/its-the-future/
elorant|10 years ago
Touche|10 years ago
realusername|10 years ago
erokar|10 years ago
It's the now. Elm is the future elm-lang.org
Silhouette|10 years ago
But last week the future was AngularJS, and the week before that it was Ember or Backbone or Knockout, and a few days earlier it was jQuery. Next week it will be Angular 2.0, maybe, or something with Web Components, and the week after that we're all abandoning JS in favour of some declarative functional language that hasn't been written yet but will be on TodoMVC tomorrow.
Seriously, this is a beta of a pre-release package. The article mentions, as motivation for the major architectural change, some other react-something packages, and literally in the opening section of their README.md they say things like "This project is a work-in-progress. Though much of the code is in production on flipboard.com, the React canvas bindings are relatively new and the API is subject to change."
By all means let's experiment with newer and potentially better ways to build sites and apps, but betting heavily on an ecosystem this immature for a long-term professional project seems like asking for trouble.
Isn't this what we have all been waiting for?
It's certainly not something I've been waiting for, as someone who works in the relevant fields. Rather like "isomorphic" libraries, I feel combined web/native generation is mostly a solution in search of a problem. No doubt a few people really do have that problem, but I'm guessing that for most day-to-day work in the real world this theoretical flexibility adds little practical value. There's no particular reason the same tools should be good choices for writing both web and native apps, any more than we should expect the same tools to necessarily be good choices for writing both server-side and client-side code in a web app.
In this particular case, I'm more concerned by the change in emphasis than the technical changes. To me, the big advantage of React over most other front-end libraries and frameworks is the efficient DOM updating, which in turn makes this kind of component model viable with acceptable performance where various other UI libraries/frameworks have struggled in the past. However, it looks like the React team think that is a secondary benefit and the real advantage is using components.
I can already build a complicated web app rendering layer using the same modular design skills I've spent the last 30 years learning in other programming contexts. After all, that's what I did before we had the modern generation of template/component driven frameworks, when we had to update the DOM manually using plain JS or libraries like jQuery. So did plenty of other people. Maybe I'm missing something, but while React might be a sensible enough choice for part of the UI rendering work, I don't see why it has anything unique or special to offer compared to many other libraries here.
If the React team focussed on the efficient DOM updates, flexible but reasonably simple component model, and then stability so the community could develop the ecosystem around a solid foundation, I could see it becoming a good choice for projects that can't afford to have their dependencies constantly shifting around and the maintenance overheads that incurs. But this separation and increased emphasis on react-native and the like feels like it's leaving behind the very things that made React attractive in a very crowded field of JS UI libraries.
swah|10 years ago
kendallpark|10 years ago
rimantas|10 years ago
krat0sprakhar|10 years ago
> 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
> 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.
skrebbel|10 years ago
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.
lukeo05|10 years ago
Customer components, e.g. an <MyInput> component that wraps a DOM <input> and provides custom onWindowShow() functionality are unaffected.
matthewmacleod|10 years ago
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.
spicyj|10 years ago
References to custom component classes work exactly as before.
unknown|10 years ago
[deleted]
unknown|10 years ago
[deleted]
hartator|10 years ago
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|10 years ago
danmaz74|10 years ago
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...
spicyj|10 years ago
There's a CoffeeScript JSX transformer here if you're interested:
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.
iamflimflam1|10 years ago
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.
baddox|10 years ago
octref|10 years ago
It's not about the HTML-like JSX part using ES6 or using native classes to extend React.component(with limitations), but simpler object literals, fat arrows and { foo: foo } becoming { foo } make React code look much better. I can endure the ending semicolons, parens and brackets.
Now you don't really gain too much by opting for CS over ES6 for React. And with React's adoption of Babel I think ES6 is going to become the primary way of writing React apps.
joesb|10 years ago
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|10 years ago
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.
smhg|10 years ago
Sounds good!
If not already, react-dom will probably be easily replaceable by modules like virtual-dom?
ericclemmons|10 years ago
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|10 years ago
It's going to be a boon for libraries which use DSL-like ancestor components.
d0m|10 years ago
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:
Which basically transforms to this.refs.header.refs.search.refs.input (IIRC)spicyj|10 years ago
But that should continue to work fine.
modarts|10 years ago
andy_ppp|10 years ago
Presumably the react/react-dom breaks all current third party packages for now?
spicyj|10 years ago
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.)
huskyr|10 years ago
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'?
colinramsay|10 years ago
This release includes the old methods in the react package with a deprecation warning, but they'll be removed completely in 0.15
jscheel|10 years ago
aaronjgreenberg|10 years ago