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

41–50 of 133 posts

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

#41

Post by hardwaresofton »

acemarke wrote: post #37
hardwaresofton wrote: post #34

Earlier quoted context omitted.

The downvotes are unfortunate, since this is a reasonable sentiment, here's an article I read a while ago that presented this point in a more nuanced fashion: https://bitquabit.com/post/the-more-things-change/

COM and a Win32 WndProc function aren't very similar :) (And yes, that's a very good post.)

Ahh I thought they were the same -- admittedly I've never worked deeply with windows program (and do not plan to at any point in time), so I couldn't tell the difference

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

#42

Post by Niksko »

hardwaresofton wrote: post #39

disclaimer: I don't like react. Outside of dom node diffing and a focus on components I don't think it brings much to the table considering the considerable complexity it brings. It seems like react gets re-written and APIs undergoes drastic changes every few months. I'm not complaining about churn (I don't write react), but rather that maybe React isn't the right tool to be hyping up, or pointing newcomers to JS at…

A HOC is nothing more than a factory in traditional OO programming. Just because you see an acronym you don't understand, doesn't mean the entire framework is flawed

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

#43

Post by myth_drannon »

Does anyone finds the new getDerivedStateFromProps adds too much boilerplate code for the developer to write and be aware? So for every previous prop that I need to compare with I need to remember to update it in the state? If before it was as simple as this.props.X!==nextProps.X now I need to set the state with the current prop!

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

#44

Post by hardwaresofton »

acjohnson55 wrote: post #40
hardwaresofton wrote: post #39

disclaimer: I don't like react. Outside of dom node diffing and a focus on components I don't think it brings much to the table considering the considerable complexity it brings. It seems like react gets re-written and APIs undergoes drastic changes every few months. I'm not complaining about churn (I don't write react), but rather that maybe React isn't the right tool to be hyping up, or pointing newcomers to JS at…

For the most part, the changes really shouldn't affect typical users. The biggest change in React from a dev perspective was function components, maybe 2 years ago. If you keep your state outside of React, it's dead simple to use. I think it's a great library and has only really gotten simpler and better. But, to each their own.

I agree that it's getting simpler and better -- tons of dedicated developers are making that happen. I wasn't trying to say that the rewrite shouldn't have happened or something, I just feel like there's a lot of zealotry festering, so many companies are picking React just to attract developers (anecdotal evidence: https://www.youtube.com/watch?v=u80GTmVtdG4&t=2898s).

My problem is that it was being marketed (heavily) as simple and amazing at the beginning when it simply wasn't. From what I remember, the FB team was explicit about it not being for beginners, but the amount of marketing and trumpeting made that basically impossible, and now bootcamps are teaching it to beginners.

I just am super tired of having to talk people out of using it on their first project after learning and using HTML+CSS for the first time. I always sound like the insane person, saying "react is complicated" when all the marketing and blogs and everything else is saying "react is simple".

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

#45

Post by hardwaresofton »

Niksko wrote: post #42
hardwaresofton wrote: post #39

disclaimer: I don't like react. Outside of dom node diffing and a focus on components I don't think it brings much to the table considering the considerable complexity it brings. It seems like react gets re-written and APIs undergoes drastic changes every few months. I'm not complaining about churn (I don't write react), but rather that maybe React isn't the right tool to be hyping up, or pointing newcomers to JS at…

A HOC is nothing more than a factory in traditional OO programming. Just because you see an acronym you don't understand, doesn't mean the entire framework is flawed

I should have looked up HOC before I wrote that bit -- Higher Order Components do not seem like a particuarly bad design decision, but IIRC this pattern was introduced somewhere around the launch of React 16?

Also, I'm not sure the characterization as a factory is correct, seems closer to higher order functions (at the very least name wise), and/or enhancing features by composition.

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

#46

Post by sibeliuss »

hardwaresofton wrote: post #44
acjohnson55 wrote: post #40

Earlier quoted context omitted.

For the most part, the changes really shouldn't affect typical users. The biggest change in React from a dev perspective was function components, maybe 2 years ago. If you keep your state outside of React, it's dead simple to use. I think it's a great library and has only really gotten simpler and better. But, to each their own.

I agree that it's getting simpler and better -- tons of dedicated developers are making that happen. I wasn't trying to say that the rewrite shouldn't have happened or something, I just feel like there's a lot of zealotry festering, so many companies are picking React just to attract developers (anecdotal evidence: https://www.youtube.com/watch?v=u80GTmVtdG4&t=2898s ). My problem is that it was being marketed (heavil…

const Name = (props) => {props.name}

const Age = (props) => {props.age}

const App = () =>

Is about as simple as it gets. This sort of composability can go _very_ far without needing any of the other API methods.

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

#47

Post by sibeliuss »

myth_drannon wrote: post #43

Does anyone finds the new getDerivedStateFromProps adds too much boilerplate code for the developer to write and be aware? So for every previous prop that I need to compare with I need to remember to update it in the state? If before it was as simple as this.props.X!==nextProps.X now I need to set the state with the current prop!

Personally, I find the word "derived" to be a somewhat unfortunate choice

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

#48

Post by danabramov »

myth_drannon wrote: post #43

Does anyone finds the new getDerivedStateFromProps adds too much boilerplate code for the developer to write and be aware? So for every previous prop that I need to compare with I need to remember to update it in the state? If before it was as simple as this.props.X!==nextProps.X now I need to set the state with the current prop!

This lifecycle exists for a fairly rare use case. Why do you use it often? Instead of keeping state “in sync” with the props, can you just read it from the props?

For the rare cases where you do want to retain previous props, yes, we’re asking you to be explicit about it. This will allow better memory usage in future versions of React, and also avoids the need for an extra `prevProps !== null` check that would need to happen in every `getDerivedStateFromProps` method.

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

#49

Post by danabramov »

hardwaresofton wrote: post #39

disclaimer: I don't like react. Outside of dom node diffing and a focus on components I don't think it brings much to the table considering the considerable complexity it brings. It seems like react gets re-written and APIs undergoes drastic changes every few months. I'm not complaining about churn (I don't write react), but rather that maybe React isn't the right tool to be hyping up, or pointing newcomers to JS at…

We maintain more than 50,000 components at Facebook, and I don’t believe your assessment that “APIs undergoes drastic changes every few months” is accurate. The component API has barely changed since the initial release five years ago.

When we need to make changes, it’s the team of 8 people that need to port all those dozens of thousands of components to new APIs. It would be infeasible for us to break APIs every few months, or to do so in a manual way. This is why we embrace automatic codemod scripts.

There have been some breaking changes between major releases (which have a roughly yearly—not monthly—cadence) but we always provided automatic scripts that convert your code as much of your code as possible automatically: https://github.com/reactjs/react-codemod.

We also call attention to the automated migration scripts in all major release blog posts (for example: https://reactjs.org/blog/2017/09/26/react-v16.0.html#upgradi...).

That’s the only way we could maintain dozens of thousands of components while still moving the library forward.

I hope this information is helpful. You can read more about our commitment to stability without stagnation here: https://reactjs.org/docs/design-principles.html#stability

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

#50

Post by sibeliuss »

hardwaresofton wrote: post #45
Niksko wrote: post #42

Earlier quoted context omitted.

A HOC is nothing more than a factory in traditional OO programming. Just because you see an acronym you don't understand, doesn't mean the entire framework is flawed

I should have looked up HOC before I wrote that bit -- Higher Order Components do not seem like a particuarly bad design decision, but IIRC this pattern was introduced somewhere around the launch of React 16? Also, I'm not sure the characterization as a factory is correct, seems closer to higher order functions (at the very least name wise), and/or enhancing features by composition.

Components are just functions -- HOC's are higher order functions. The pattern dropped out like all patterns drop out -- from use. Its nothing specific to React, but to functional programming
Post reply on HN