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

51–60 of 133 posts

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

#51

Post by mrdoops »

CuriouslyC wrote: post #22

I have very mixed feelings about the new context api. On one hand, you're taking a foot-gun away, which I approve of having worked on code bases that abused it. On the other hand, it's very clunky, and I think people who abused the old context will just start making components larger, and wrapping them in a single context, rather than doing the right thing with many small components individually wrapped. Personally I…

I think it's more intended to be utilized as an abstraction in something like Apollo. It'll be interesting to see what sort of cleaner patterns emerge out of using Contexts under the hood.

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

#52

Post by spicyj »

sibeliuss wrote: post #47
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

Why is that?

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

#53

Post by hardwaresofton »

sibeliuss wrote: post #46
hardwaresofton wrote: post #44

Earlier quoted context omitted.

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.

I looked up HOCs not long after writing the comment, and I agree -- this is much better than the mixin approach that used to be the way (though if I remember correctly, mixins were considered 'temporary' at the time).

This isn't a benefit of react though -- this is just react incorporating a well known functional paradigm, which I don't mind.

IMO If react was simple, this would have been the way to do it from the start -- no mixins detour. This answer would have fallen out (as it now has), if they simply didn't offer a way to inherit functionality, in that manner. If a component is truly just a function from state to output, the obvious way to combine them IS higher order functions.

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

#54

Post by spicyj »

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.

Higher order components have been a common pattern since early 2015. https://medium.com/@dan_abramov/mixins-are-dead-long-live-hi... (And like others said, they are relatively simple and draw heavily on prior principles in functional programming.)

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

#55

Post by hardwaresofton »

sibeliuss wrote: post #50
hardwaresofton wrote: post #45

Earlier quoted context omitted.

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

Just replied in the other spot -- I understand the similarities now, but I think this points to react still not being as simple as it could be -- if components were really as simple as being functions from state to UI, reacts API would be drastically smaller.

My point is that it's not that simple (for better or for worse, some of the added complexity in the API IS essential IMO), but people still say things like "components are just functions" like it really is that simple.

For example: https://reactjs.org/docs/react-component.html#static-getderi...

This note:

> Note that if a parent component causes your component to re-render, this method will be called even if props have not changed. You may want to compare new and previous values if you only want to handle changes.

Things like that are indications of hidden complexity, in my experience.

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

#56

Post by akrumel »

danabramov wrote: post #48
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 t…

Responding to "exists for a fairly rare use case" statement, I just searched the the web app I am currently writing and it uses componentWillReceiveProps() ~20 times. Most cases are for detecting changes requiring freeing/fetching network based resources where the data involved can get excessive if care is not taken. This would seem to be a common scenario for many domains. On a sidenote, I have thoroughly enjoyed working with react and RN over the last 4 years and have learned much from dan's work. Thanks guys.

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

#57

Post by ncphillips »

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.

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

#58

Post by danabramov »

akrumel wrote: post #56
danabramov wrote: post #48

Earlier quoted context omitted.

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

Responding to "exists for a fairly rare use case" statement, I just searched the the web app I am currently writing and it uses componentWillReceiveProps() ~20 times. Most cases are for detecting changes requiring freeing/fetching network based resources where the data involved can get excessive if care is not taken. This would seem to be a common scenario for many domains. On a sidenote, I have thoroughly enjoyed wo…

>I just searched the the web app I am currently writing and it uses componentWillReceiveProps() ~20 times.

How many components do you have? Absolute number doesn’t tell me a lot. :-)

>Most cases are for detecting changes requiring freeing/fetching network based resources where the data involved can get excessive if care is not taken.

Not sure I fully understand. Could you provide a small example?

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

#59

Post by myth_drannon »

swalsh wrote: post #9

In the unlikely scenario of Facebook's demise, how do you think the maintenance of React would transpire? Do you think some other tech company would snatch up the design leads, and pick up the torch? Would it go into its own independent organization?

I think developers will stop using ReactJS long before FB is gone. Look at angular, backbone, JQuery, Adobe Flex and so many others. It's just a framework....

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

#60

Post by hardwaresofton »

danabramov wrote: post #49
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…

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) shed unneeded complexity, that there must have been complexity to shed. Obviously no one is perfect, and hindsight is 20/20, but for such a "small" (yes, interacting with the dom is actually super duper hard, and edgecases abound) scope, I've seen more large-ish overhauls than I am comfortable with.

Many internal changes makes me feel like react is more Mongo than RethinkDB (the latter being a document store that actually got most things right and was well engineered but no one ever heard of while mongo started with a badly engineered product, good marketing, and pivoted to relative reliability and good engineering).

I want to also note that I'm not in the target audience for a post like this. There are tons of people who lovingly and productively use React -- I'm not one of them. I am just dumbfounded when people bill react as simple but have never heard of something like Mithril that actually is simple (almost "stupidly" so), and another post at the top of HN means there's that many more people I have to convince to pick something at least slightly simpler when they start doing web development for the first time.

Post reply on HN