Live data from Hacker News

React v0.14 Beta 1 released

facebook.github.io

11–20 of 62 posts

Re: React v0.14 Beta 1 released

#11
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

Re: React v0.14 Beta 1 released

#12
post #3

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 no…

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

Re: React v0.14 Beta 1 released

#13
post #11

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 t…

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 !

Re: React v0.14 Beta 1 released

#14
post #12
post #3

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 no…

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 t…

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!

Re: React v0.14 Beta 1 released

#15
post #11

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 t…

Cross platform tools always make compromises. I’d rather write native code than have a framework that does it for me.

Re: React v0.14 Beta 1 released

#16
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 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.

Re: React v0.14 Beta 1 released

#17
post #15
post #11

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 t…

Cross platform tools always make compromises. I’d rather write native code than have a framework that does it for me.

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

Re: React v0.14 Beta 1 released

#18

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…

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.

Re: React v0.14 Beta 1 released

#19

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…

This is only true for DOM components, e.g. an component, which can't have a onWindowShow() method associated with it.

Customer components, e.g. an component that wraps a DOM and provides custom onWindowShow() functionality are unaffected.

Re: React v0.14 Beta 1 released

#20
post #15
post #11

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 t…

Cross platform tools always make compromises. I’d rather write native code than have a framework that does it for me.

I'm not convinced that's true.

I do agree to the extent that things like PhoneGap do result in compromises. But React Native is basically a templating tool for native apps – you're still free to write whatever native components you require, but can compose these using React, which is pretty cool. You can then abstract the higher-level components across platforms.

Post reply on HN