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

React v16.3.0: New lifecycles and context API

reactjs.org

Post reply on HN
Print view View original

121–130 of 133 posts

Re: React v16.3.0: New lifecycles and context API

#121

Post by nkkollaw »

vbezhenar wrote: post #99
nkkollaw wrote: post #97

Earlier quoted context omitted.

The problem is when--like in my case--people develop a project for a client and then go on with their lives, until the client notices a bug, or wants to implement a new feature months after. I tried to explain the client that I needed to upgrade the code before even being able to understand what the problem was, and I lost the client. As much as they suck, PHP apps from 10 years ago are still working great, and so ar…

Why do you need to upgrade the code to fix a bug or implement a new feature? I don't understand that. Keep React version and do what client wants.

Things wouldn't even compile.

Don't forget that a React project might be made of many libraries--not just React itself--that might be worse at supporting legacy versions and guaranteeing mooth upgrades.

Re: React v16.3.0: New lifecycles and context API

#122

Post by brlewis »

brianvaughn wrote: post #120
brlewis wrote: post #119

Earlier quoted context omitted.

In self-contained apps couldn't a single prop be passed down that's an object with all things like that in it? Maybe there's a scenario with 3rd-party components where context could make it look more elegant, but I don't have a clear picture. I know there are several ways to construct a component, but I like that your examples make them functions of props, because that's how I picture a component. Having its behavior…

Yes, but then that prop would need to be passed down explicitly through every component. This would require a _lot_ of boilerplate.

OK, it just boils down to me thinking one explicit prop for every component isn't too much boilerplate. I can see some teams liking the idea of shaving off that explicit prop as long as everybody knows about the implicit context(s) that also affect component behavior.

Re: React v16.3.0: New lifecycles and context API

#123

Post by brianvaughn »

brlewis wrote: post #122
brianvaughn wrote: post #120

Earlier quoted context omitted.

Yes, but then that prop would need to be passed down explicitly through every component. This would require a _lot_ of boilerplate.

OK, it just boils down to me thinking one explicit prop for every component isn't too much boilerplate. I can see some teams liking the idea of shaving off that explicit prop as long as everybody knows about the implicit context(s) that also affect component behavior.

> s everybody knows about the implicit context(s) that also affect component behavior.

Just in case there's any misunderstanding- (I don't think there is, but just being safe)- context isn't implicit. You have to opt into it either by using the `` component or a HOC that injects a context prop.

Re: React v16.3.0: New lifecycles and context API

#124

Post by nkkollaw »

brianvaughn wrote: post #115
nkkollaw wrote: post #97

Earlier quoted context omitted.

The problem is when--like in my case--people develop a project for a client and then go on with their lives, until the client notices a bug, or wants to implement a new feature months after. I tried to explain the client that I needed to upgrade the code before even being able to understand what the problem was, and I lost the client. As much as they suck, PHP apps from 10 years ago are still working great, and so ar…

I'm not sure why you would need to upgrade your app in that case. Is the problem that our documentation only reflects the latest release?

Things wouldn't even compile.

Don't forget that a React project might be made of many libraries--not just React itself--that might be worse at supporting legacy versions and guaranteeing mooth upgrades.

Re: React v16.3.0: New lifecycles and context API

#125

Post by nkkollaw »

danabramov wrote: post #101
nkkollaw wrote: post #97

Earlier quoted context omitted.

The problem is when--like in my case--people develop a project for a client and then go on with their lives, until the client notices a bug, or wants to implement a new feature months after. I tried to explain the client that I needed to upgrade the code before even being able to understand what the problem was, and I lost the client. As much as they suck, PHP apps from 10 years ago are still working great, and so ar…

Could you clarify how React is different from jQuery in that sense? Not sure I’m following.

Maybe because it's an older and therefore feature-complete/mature project, or maybe because it's not being actively developed anymore (I really don't know), but jQuery's API has hardly changed in the past few years.

For this reason, jQuery-based projects from 3-4 years ago still work completely fine (including jQuery plugins), and I would imagine will keep working for years to come.

React is continuously evolving, and 1 year is enough to make React code and/or code in plugins used in a React project obsolete. Because of this, React projects break more easily if one doesn't or can't keep upgrading the code (for instance, because it was a client you don't work with anymore).

This is not good or bad, or anyone's fault, it's just how it is.

Like I said in previous comments, I would never go back to writing PHP or jQuery apps, but this is definitely an issue--either intrinsic of using an evolving technology like React, or caused by relying on too many plugins from authors that don't have the resources to keep supporting legacy APIs or upgrade their plugins to using the new ones.

Re: React v16.3.0: New lifecycles and context API

#126

Post by nkkollaw »

ncphillips wrote: post #57
nkkollaw wrote: post #28

I use and love React, but I'm also a little scared of it. I opened this little app I did 1 year ago in React 15, and it's completely incompatible with what I use now. Every time I read of a new release I get this chill down my spine for a second.

That's interesting, my experience has been the exact opposite. I'm really impressed at how good they are at sticking to semver.

It might be plugins.

Re: React v16.3.0: New lifecycles and context API

#127

Post by BigJono »

brianvaughn wrote: post #111
brlewis wrote: post #102

Earlier quoted context omitted.

Thanks, that seems like a good explanation. I still think I'll need examples to be convinced of the usefulness, though. I don't see why a large component tree would have 14 disparate props passed down individually. If the tree is supposed to be a reusable component, why not define a single object to pass down? Edit: Having read the docs I now see that my current perspective on it is the one they want me to have. "Don…

I'm curious why the theme example I mentioned in my earlier comment- (and showed in the docs)- doesn't qualify as "useful" to you. Another example would be using context to share the selected language/locale between all of the localized components in an application.

In my experience, examples are only useful if they have two points of comparison side by side.

For example if I'm looking into a new library that claims to simplify my app's architecture or reduce boilerplate, I need to see what the alternative would look like for a given example, otherwise it's just a baseless claim.

Same as things that purportedly "scale". Since every library under the sun claims that as a benefit, I wouldn't even bother recommending any of them to anyone on here without an example of a large app both with and without the library, pointing out the specific sections of code that change for the better.

Re: React v16.3.0: New lifecycles and context API

#128

Post by hardwaresofton »

brianvaughn wrote: post #61
hardwaresofton wrote: post #60

Earlier quoted context omitted.

I apologize -- I should have written "API internals". I did not mean to state that the component API changed a lot, just seemingly that the internals did, with fiber and the like. I understand the team is hard at work making React better, and there is absolutely no doubt that you are succeeding and react is getting better. However, the amount of large internal changes indicates that as you improve and (most likely) s…

> However, the amount of large internal changes indicates that as you improve and (most likely) shed unneeded complexity, that there must have been complexity to shed. The v16 rewrite (dubbed "fiber") wasn't just about cleaning up internals- it was about supporting a fundamentally different type of behavior- asynchronous rendering [1] > Obviously no one is perfect, and hindsight is 20/20, but for such a "small" (yes,…

This is a huge point that I do often miss when I think about react when used for react development...

You're absolutely not being argumentative -- while I still don't think react is the simplest thing to start with, the explanations that have been given so far seem very very reasonable, feel like an asshole for essentially ranting

Re: React v16.3.0: New lifecycles and context API

#129

Post by hardwaresofton »

danabramov wrote: post #69
hardwaresofton wrote: post #60

Earlier quoted context omitted.

I apologize -- I should have written "API internals". I did not mean to state that the component API changed a lot, just seemingly that the internals did, with fiber and the like. I understand the team is hard at work making React better, and there is absolutely no doubt that you are succeeding and react is getting better. However, the amount of large internal changes indicates that as you improve and (most likely) s…

>just seemingly that the internals did, with fiber and the like. We‘ve lived with the same codebase for four years and frankly, it was slowing us down. Not all original abstractions aged well because when React was written, we didn’t really have a lot of experience with React :-) I don’t think it’s because the original code was bad (I’m not familiar with Mongo so I don't know if that’s what you were implying), but be…

Thanks for explaining so much about the process -- I didn't mean that the code was bad, just that there was an unexpected amount of growth.

But hearing what was being dealt with (those blog posts) definitely clears things up for me -- Also as the other commenter mentioned, react is aiming for so much more than the DOM (react native was a visionary/revolutionary achievement IMO, not even trying to blow smoke, I think at this point that's pretty much a fact) it makes sense why and how react has grown the way it has.

Thanks for taking time to clear up my misunderstanding/where I was wrong

Re: React v16.3.0: New lifecycles and context API

#130

Post by cztomsik »

aioprisan wrote: post #65
adam_sohn wrote: post #63

Earlier quoted context omitted.

Angular 5 is very popular now. Big teams with data intensive administration dashboards are choosing it over React.

I don't buy it. Vue is eating Angular's lunch, with React leading. https://medium.jonasbandi.net/angular-vs-react-popularity-ea...

Vue is great, I love it for my personal projects and it's also fairly common in PHP world but that's it. Angular is very popular in Java world and it works really great if you need a lot of forms. These people usually don't have time talking about it. React is popular everywhere else, especially among bloggers who usually fail to explain why exactly is React better choice.
Post reply on HN