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

91–100 of 116 posts

Re: React v0.14

#91

Post by tracker1 »

aboodman wrote: post #85
k__ wrote: post #4

Earlier quoted context omitted.

Is it possible to build an entire app with them using Redux?

I generally try to do everything in render(). It almost always works out better. Sometimes I end up needing a lifecycle event. Timers (e.g., for manual animations) end up being hard to model without mount/unmount.

Agreed.. using mount/unmount is the exception to the rule.. I can imagine anything using charting libraries, or any third party rendering library would need to do this for performant controls... but it is definitely the exception to the rule.

Re: React v0.14

#92

Post by tracker1 »

Silhouette wrote: post #79
danabramov wrote: post #64

Earlier quoted context omitted.

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

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? Yes, any library that breaks code written according to documented good practices less than six months earlier only cares a little about…

Most breaking changes are including warnings 2 versions ahead of time... In TFA they outlined, iirc, 2 changes that would have less time than this. This isn't a magical, final interface we're dealing with... it's iterative changes over time.

TBH, I don't like getting stuck at one point.. in practice those using React have been embracing the one-way flow that flux-like frameworks bring... This has been distilled down to Redux (imo, the best workflow option for React), which has signalled some distillation in terms of the interfaces React exposes. This is combined with different rendering paths coming to light, and I think it's pretty great.

I'm currently working in an environment that is transitioning from the old-way, to a more current way of doing things. I've been working with node since pretty early on (0.4) and was following it before that. The more I've embraced this continuously updating workflow, the less friction I've experienced as a whole. That doesn't mean no pain, just less of it overall.

The React/Facebook guys have been very good members in this larger community, and I applaud them for their efforts... Dropping their own render in favor of Babel, and reducing some of their mutation enablers only show them to be working with feedback from the community. It may be at a pace that's harder to keep up with, but that doesn't mean that they shouldn't be doing it.

Re: React v0.14

#93

Post by tracker1 »

Touche wrote: post #59
draw_down wrote: post #48

Earlier quoted context omitted.

> Only after a 1.0 release. 0.x implies that breaking changes are always possible Oh, I didn't know that, it's unfortunate. IMO, just bump major version every time compat breaks. Otherwise projects end up mincing around forever trying to decide when the shiny 1.0 ribbon can be affixed.

> IMO, just bump major version every time compat breaks. Some projects do this but most do not. The reason is that if you're using a project that's on version 3 and 6 months from now it's on version 12 that's going to make you think twice about using it. No one wants to go through upgrade pains constantly. The "hack" is to never go 1.0 to hide how often you are really breaking APIs. In reality breaking APIs should be…

I think pre 1.0 should represent that breaking changes are happening more often.. a 3-month release cycle with breaking changes in pretty much every stable release doesn't bode well in that regard. However, they have been very responsive to the larger community and these additions and changes are really a good thing. Mostly they break out rendering pipelines to support multiple renderers, and they reduce opportunities for mutations, which fly in the face of a flux-like workflow.

Re: React v0.14

#94

Post by Gigablah »

Touche wrote: post #72
danabramov wrote: post #64

Earlier quoted context omitted.

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

> cares a little about compatibility? Yes, they care. But they care more about their ability to make breaking changes without the stench of a major version bump. You have to ask, why is it currently not 1.0? The roadmap you linked doesn't mention it. There's a reason. So what is it? By the way, I know you're a huge React cheerleader and that's fine, and you think I'm being critical of React here and you need to defen…

> But I'm not, this is a problem throughout the JavaScript community and really the fault lies there

Did you see the complaints when Node went from 0.12 to 4.0?

Re: React v0.14

#96

Post by tracker1 »

pkozlowski_os wrote: post #73
danabramov wrote: post #71

Earlier quoted context omitted.

Usually people say “dirty checking” when they mean “keep checking in some kind of event loop whether external entity modified some object, and if so, do something”. In React there's no such event loop where it checks virtual DOM—React knows if it needs to compare virtual DOM trees (not arbitrarily check models for changes, for example) because all changes are explicit and happen either due to `setState()`, `forceUpda…

Right. I guess it really depends how people define "dirty checking". What I was trying to say is that at the end of the day you do diffing on some data structure: model in Angular and virtual Dom in React. Loop vs. one pass is an important distinction, agreed. But when we bring Angular we should be noted that Angular 2 doesn't do those checks in a loop but does comparisons in one pass only.

My biggest complaints about angular aren't really the dirty checking system that it uses (though one of them is a side effect).

My biggest complaint is the weird dependency injection system that makes it difficult to track down where something comes from. It's better in 2, but still not as straight forward as React, where your child components are simply import/require statements that you can follow through to either an installed npm module, or a relative path. I try to avoid DI in JS wherever possible, it's almost never needed, and there are almost always simpler ways.

My second largest complaint on angular, is that I find that the way it handles state (though many are moving to a more react-like approach) leads to anything outside of the "angular way" being very complicated to work around. The fact that $scope.apply() is a thing kind of sums it up pretty nicely.

For most applications (we're not all building facebook level interactions), either comparison approach is not a performance issue in practice. What I do find is the flux/react way tends to have a bit more cognitive overhead to get started with, but additional features add less additional complexity than with angular.

Re: React v0.14

#97

Post by cpeterso »

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.

semver version number is not so much a statement of stability, but a contract between the library producer and consumer.

Re: React v0.14

#98

Post by thebigkick »

desuvader wrote: post #6

Wohoo! .getDOMNode() is finally gone! Edit: Haha, I just noticed that someone else was also happy about this. Also, now that classnames is standalone module, I recommend that people start using a standalone implementation of keyMirror (for flux) as well!

Would you mind explaining? As a jQuery believer, to me this looks like a selector method - getElementByID or something. I'm guessing this is against the whole idea of React.

Re: React v0.14

#100

Post by untog »

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.

> It's about the perception that the number provides.

And now we're back to the original question, which was "why do you care about an imaginary number?"

Post reply on HN