Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React v0.14

facebook.github.io

Post reply on HN
Print view View original

61–70 of 116 posts

Re: React v0.14

#61

Post by danabramov »

clessg wrote: post #3

A lot of great ideas in this release and it makes me excited for the future of React. I've been on 0.14-rc1 and my favorite feature so far is stateless function components. So much cleaner than class-based components. One downside is that hot reloading doesn't work with it yet (AFAIK). Hopefully that will come soon now that 0.14 is officially released. (And I believe Dan is/was on vacation.) Andrew Clark (core contri…

>One downside is that hot reloading doesn't work with it yet (AFAIK). Hopefully that will come soon now that 0.14 is officially released. (And I believe Dan is/was on vacation.)

There's work in progress on this, and I'll try to release an update to React Transform & friends handling this next week.

Might take longer to retrofit this into React Hot Loader but if there's enough demand I can try doing this too.

Re: React v0.14

#62

Post by danabramov »

epmatsw wrote: post #46
smadge wrote: post #40

Earlier quoted context omitted.

What exactly is different? I've been using "stateless function components" with react 0.12 and 0.13. Just write a function that returns a ReactElement, eg: function renderFoo(props) { return {props.foo} ; } Then use it elsewhere in your code like a normal function: function bar(props) { return {props.foos.map(renderFoo)} ; }

Looks like they've just added first-class support for that pattern, so you get propTypes, defaultProps, etc.

Also in the future this pattern will be faster thanks to React not having to maintain an internal instance for such components.

(How's that different from just a function? It shows up as separate thing in React DevTools, it can have default props or, in the future, shouldComponentUpdate (or built-in memoization strategy?), you can potentially later change it to be stateful without rewriting consuming code, etc)

Re: React v0.14

#63

Post by danabramov »

Touche wrote: post #60
masterj wrote: post #49

Earlier quoted context omitted.

Why do you care about an imaginary number? FB (and many other large companies) heavily use this in production, and have to migrate their own apps. FB even goes farther and uses the master branch (well, synced every week or so). That's a far heavier endorsement than whatever side of a decimal a number falls on.

> Why do you care about an imaginary number? It's not imaginary, it represents stability. By not going 1.0 you are saying it is alpha software and should not be used. Not everyone has Facebook's budget or resources to upgrade every 2 months.

React upgrade path is stabler and smoother than 90% of >1.0 libraries I have seen. Please don't jump to conclusions. ;-)

Re: React v0.14

#64

Post by danabramov »

Touche wrote: post #42
robertfw wrote: post #37

Earlier quoted context omitted.

Only after a 1.0 release. 0.x implies that breaking changes are always possible My experience has been that the React team provides plenty of advance warning with deprecation notices, similar to the experience of others I've never really been caught out by anything The worst case I've dealt with is bringing an app from .12 to .13 after not touching the code for five or six months. It only took me a few hours to bring…

> Only after a 1.0 release. 0.x implies that breaking changes are always possible Yes, which is why so many projects never reach 1.0. There are basically 2 types: 1. Those who don't want to have to care about compatibility at all. 2. Those who care about compatibility a little bit but don't want a large version number. React seems to fall into #2 here. They want a small version number and the perception of stability.…

>2. Those who care about compatibility a little bit but don't want a large version number.

>React seems to fall into #2 here.

Seriously, a library that goes out of its way to provide useful deprecation warnings and always keeping deprecated behavior for a version, with versions coming out once in three months, and released with codemods automating the transition for you, cares a little about compatibility?

React team will eventually jump to bumping major, and it's a good question to ask, but it's a good question to ask the team instead of guessing what and why they do.

https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning

Re: React v0.14

#65

Post by danabramov »

spicyj wrote: post #50
kraig911 wrote: post #47

Anyone find a list that says what is broken by this update? I couldn't find an easy to parse list of functions/methods/etc that have changed ||&& are broken.

Were my "Upgrade Guide" and "Breaking Changes" sections not clear? I tried to make it as clear as possible but you still seem confused…

If you didn't see warnings running code under 0.13, nothing should break per se, right? And if you see warnings now, that's the stuff that will break in 0.15 but works for now.

Re: React v0.14

#66

Post by spicyj »

danabramov wrote: post #65
spicyj wrote: post #50

Earlier quoted context omitted.

Were my "Upgrade Guide" and "Breaking Changes" sections not clear? I tried to make it as clear as possible but you still seem confused…

If you didn't see warnings running code under 0.13, nothing should break per se, right? And if you see warnings now, that's the stuff that will break in 0.15 but works for now.

Yes, with the exception of the React.initializeTouchEvents() removal and the ReactTestUtils change I noted.

Re: React v0.14

#67

Post by quarterto »

danabramov wrote: post #63
Touche wrote: post #60

Earlier quoted context omitted.

> Why do you care about an imaginary number? It's not imaginary, it represents stability. By not going 1.0 you are saying it is alpha software and should not be used. Not everyone has Facebook's budget or resources to upgrade every 2 months.

React upgrade path is stabler and smoother than 90% of >1.0 libraries I have seen. Please don't jump to conclusions. ;-)

It's about the perception that the number provides.

Re: React v0.14

#68

Post by danabramov »

quarterto wrote: post #67
danabramov wrote: post #63

Earlier quoted context omitted.

React upgrade path is stabler and smoother than 90% of >1.0 libraries I have seen. Please don't jump to conclusions. ;-)

It's about the perception that the number provides.

Fixing this is on the roadmap: https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning

Re: React v0.14

#69

Post by danabramov »

eric-hu wrote: post #17
Touche wrote: post #9

> Like always, we have a few breaking changes in this release. We know changes can be painful (the Facebook codebase has over 15,000 React components), so we always try to make changes gradually in order to minimize the pain. Since React is a semver project, from the website: > How do I know when to release 1.0.0? > If your software is being used in production, it should probably already be 1.0.0. If you have a stabl…

I came in here to comment on this. React sounds exciting from what I've read about it, but I didn't realize it was pre-1.0. To teams who are using it in production, did you talk about this? What are arguments for using it despite it not being 1.0?

>To teams who are using it in production, did you talk about this? What are arguments for using it despite it not being 1.0?

That it's stabler than most 1.0+ libraries is a good argument.

Facebook uses React at massive scale, so they're very careful with changes, go out of their way to keep deprecated behavior for at least a version (and a version takes a few months), provide codemods for changes that can be automated, provide useful warnings, run React master in FB production, and catch many issues in internal FB-specific tests before they even reach the React master. This is as stable as you can get without stagnating the platform.

The only problem with React being pre-1.0 is the impression that it isn't stable, which couldn't be further from truth. That said they plan to address this perception eventually: https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning

PS Yeah it's a bit frustrating React doesn't bump majors and bumps 0.x minors instead and yes semver says “production better be 1.x” but realistically I choose real stability over “fully adhering to semver production-is-above-zero doctrine” any day, and stability is what React releases deliver. As long as NPM understands what breaking changes are (and caret gives the intended meaning for 0.x), I don't really care which number as bumped, as long as the migration is relatively painless, and the platform moves into the right direction.

Re: React v0.14

#70

Post by pkozlowski_os »

draw_down wrote: post #55
zkhalique wrote: post #54

I have a question, why is dirty-checking so great? Whether it's Angular doing dirty-checking in the $digest cycle or React walking the virtual DOM and doing dirty-checking? Why not just subscribe to events and update things when the model changes? That would seem to be far more efficient, and also make clear the mapping of dependencies of views on data.

React does not do dirty checking.

Well, it kind of does when comparing virtual DOMs before and after changes.
Post reply on HN